Waterfall and agile are two unique development models used in interactive and software production. It's likely the debate over which is better will continue indefinitely, but in reality, both approaches boast significant but different benefits. It's generally accepted that agile, specifically, lends itself well to software development and large-scale website projects. Although a novice Project Manager may feel more comfortable working with a waterfall approach because each step is predictable, letting go of the familiar may well be worth it to make the move to an agile model. The collaboration and flexibility that agile brings can result in a better end product for your client, and a more engaged, harmonious internal team.
At a high level, the waterfall approach infers structured and linear project cycles. Detailed project specifications and a statement of work are produced early on, and the waterfall model mandates that this plan is adhered to without deviation. I often refer to this approach as 'passing the baton', since individual resources tend to work on their piece of the end deliverable in isolation, and then they pass it along to the next person in the sequential production cycle. Using this approach, feedback and revisions are slated as the final phases of production, once the entire product has been completed. This means altering elements can be costly and cumbersome, because even a small change at the end of a project may have implications to many parts of a finished product.
Agile is very different in that teams develop smaller, low-fidelity portions of the end product quickly, re-evaluate and revise them (often in collaboration with the client) until a level of satisfaction is achieved. These smaller pieces are then assembled near the end of the project lifecycle, once they are approved individually. As a result of this iterative pattern, agile allows for organic changes and improvements along the way, even to project specifications. Internal disciplines are expected to overlap, so that the contribution of individual resources becomes stronger when tempered with the expertise of other team members. In fact, agile dictates that communication among the team must occur daily, so that everyone is aware of individual progress. Meetings are short, and the emphasis is moved away from documentation, to rapid completion of incremental tasks (this shortened work cycle is called a 'sprint', for obvious reasons). In turn, the client is able to see something tangible earlier on in the project lifecycle, so that feedback can be provided and considered very quickly. Working to complete smaller increments of a product also results in a higher frequency of delivery to the client, ensuring they remain engaged for the duration of the project. Progress is measured by the functional elements the team develops.
Agile methodology also requires different financial reconciliation practices. Because teams will go through more iteration, and potentially even change some of the original project specifications, the Project Manager will have to implement more check-points to assess budget. To exercise budgetary control, the Project Manager must assess and dole out project hours to team members in smaller chunks – hours should be assigned to each team member weekly. Although the agile project workflow process may not seem as structured as with the waterfall approach, the consummate goal of on-time, on-budget still applies.
If you're currently practicing a waterfall approach and would like to make the move to an agile model, it can be done. Here are some steps you can take to smooth out the transition and engender some faith among your internal team:
Comments