Tuesday, June 17, 2008

Can We Combine Agile and Waterfall Development Strategies?

While there are likely as many unique Project Management approaches as there are Project Managers, there are two well-know production cycle methodologies that have been the topic of much discussion in PM circles – agile and waterfall methodologies. As I evolve in my own area of expertise, I am constantly reinventing small aspects of what I consider best practice. Most recently, to address the incredibly complex requirements of a large client initative, I challenged myself to come up with a 'super' Project Management process that would not only improve the way in which we deliver, but what we deliver at the end of the engagement. I determined there was a way to combine the best features of waterfall development disciplines with agile principles for superior results.

Simplistically, the waterfall approach infers structure, control, progression and finite project cycles. This approach works when you have access to limited resources and when specific hours are assigned to granular stages of a project phase. Agile is different in that additional leaway is given for teams to iterate through a single deliverable numerous times until a level of satisfaction is achieved. It's difficult to implement this approach when you are working with shared resources, or when time to market and budget cannot be shifted. It's important to understand my descriptions of the two approaches are extremely simplified and highlight key differences – for this entry, it's important that I make the distinction clear. I encourage all readers to conduct their own research into each approach more thoroughly.

Both approaches boast significant and different benefits, and are generally seen as being mutually exclusive of one another. It can be argued, however, that certain elements of both paths can be merged into a single process to achieve greater results. With this in mind, I have proposed a slightly refined process to my internal team, where iterations can be accommodated, but are scheduled within a defined process and period of time. In order to deliver on this approach, the efforts of multiple departmental leads (such as Information Design, Interface Design and Technical Development) must ocur concurrently so that the team can produce deliverables as a single entity. By doing this, each person's feedback is representative of the iterations which normally ocur as a deliverable is transitioned from department to department. The net result is a more controled cycle where iterations can still be accommodated.

I believe that the quality of an end deliverable will be superior when the expertise of each lead can be amalgamated into a single output. This style of collaboration will also result in a greater understanding of practice areas among the larger team – this will create long-term synergies that spur individuals to consider varying points of view, even when they work isolation.

This approach may seem like a very small deviation from standard operating procedure, but asking different subject matter experts to come together and produce one element together represents a big shift in previous thinking. This approach moves traditional agencies away from a manufacturing-based production cycle, and propels them forward into a more advanced collective and collaborative environment. As online initiatives take on more sophistication in usability, interface design and technical functionality, there will be a stronger mandate for this style of production.

1 comment:

  1. Seems like you're uncovering the tip of the iceberg here. Would love to hear more of your experiences with this approach since this post

    ReplyDelete