A few days ago, before the start of a meeting, a couple of developers where discussing ‘Agile’ project management versus the more traditional ‘Waterfall’ project planning.
A ‘Waterfall’ approach, you may recall, is the type of project that flows sequentially from stage to stage, much like a waterfall. It came from, and was heavily influenced by, the Manufacturing industry. The names of the stages vary, but roughly include: Proof-of-concept -> Initiation -> Requirements -> Design -> Implementation -> Testing -> Go Live (& Turn over to Operations). Although it does allow for change requests, it is definitely quite structured in progressing from stage to stage.
The ‘Agile’ approach on the other hand, came into being for software development, which often is non-linear, reactive, and has as an objective to deploy useful items very quickly. In an Agile project, the “product owner” decides which are the highest priority items to be included in the next iteration. The entire big picture, or thorough system requirements, may not be fully known . What is known, is that these high-priority features must be developed now. So the team delivers these items, hopefully with great quality control, and the next iteration is prepared after that.
‘Waterfall man’ was extolling the virtues of arriving at consensus on project scope from the beginning; agreeing timeline and costs; carefully tracking progress, then introducing change requests whose merit had been approved by all. ‘Agile man’, on the other hand, was calling him a dreamer, saying that such a staid and rigid approach was completely last century. That 21st Century projects need to deliver much more quickly than stodgy Waterfall projects could ever manage to.
I’ll have to say that both of these guys were making really valid points. If I am able, as a project manager, to lead stakeholders to consensus on features, priorities, total cost, total timeline, etc, doesn’t that yield a better price/performance project than deploying it ‘piecemeal’? If I have a good, decisive Executive Sponsor, who is able to map the project’s scope to company strategy, won’t that lead me to a successful and relevant implementation?
On the other hand, if my project deploys features before my competition does, and I get more customers as a result of small but important changes, doesn’t that trump the time required for sequential project planning?
Surely there is room for both methods then. If I can lead stakeholders to agree on crisp, prioritized scope items I should use the orderly “Waterfall”; I should deploy a project with the most requirements for the least effort. But if all we know is that there are critical features that must be deployed in the next 3 weeks −or something terrible will happen− then I should organize an Agile “Scrum”. It might be another case of that old saying: the right tool for the right job…