Agile Project Management: Avoiding The Waterfall - by Richard Revis
This is a guest blog post by Richard Revis from The Plan Is...
"Agile project management can be hard to implement successfully because even once you have good practices in place the way projects are run can revert to the old methodology quickly. I would like to share three reasons that I have come across for the reappearance of waterfall project management in an organisation and look at some ways to address this.
The first reason is the sponsor's view of how a project should operate. A client, internal or external, probably has a mental model in his head of how things will happen when commissioning a project.
Secondly the business environment can add to the pressure to do single iterations. Most projects occur in an environment with severe constraints. A typical project starts now and ends when the money, or attention, or time runs out. I have worked on several projects where this end date was defined by the last day we could deliver something to avoid being sued.
This kind of time constraint will lead your project sponsor even more towards thinking about their project in a waterfall style as the important requirement (don't get sued) is very clear. The consequence of such a precise requirement is the belief that it must be possible to work out how to achieve that result and then do it right the first time.
Finally, interaction with the rest of the programme can contribute. Generally your project sponsor will be thinking about more than one strand of work at a time. The part which is handed over to you will be going on in parallel with the work that is being done in marketing or operations or by another team. This naturally will reinforce the tendency to plan in a waterfall style, where each strand is completed and then brought together for iteration.
So how can a project team address this kind of imbalance between the process they wish to operate and the natural inclination of their sponsor or client?
The fact that there will be an underlying waterfall project plan, at least in the mind of your project sponsor, doesn't mean that you have to throw away your agile practices.
You probably can't get rid of the waterfall thinking entirely. The constraints and thinking I have mentioned will generally already be set by the time you get involved. However by moving the plan they have in mind up to a high enough level it is still possible for you to implement agile practices underneath.
For the element of the larger project you are working within you can try to pulling your stakeholder in early, delivering small iterations, and changing the specification to closer match the real requirements as you go along.
You will still be aiming to deliver what they want, within the time scales they ask for, just organising it in a slightly different way than they probably expected.
However in order to get this flexibility it is necessary to ensure that project milestones in your sponsors plan are high level and flexible. For example good milestones I have seen are achieve 80% rating on customer feedback, deliver £5,000/day revenue and launch a good product.
Milestones like this offer enough flexibility that another process can iterate underneath working out what the actual definition of 'a good product' is and how to best build it.
In summary, if you identify the hidden waterfall project that is going on and work out how to influence it appropriately it won't necessarily harm your project. In fact knowing about these implicit constraints and deadlines can help you deliver a better result."
About the Author:
Richard Revis has run technology development projects involving everything from iPhones up to front line fighter jets. He is currently Project Director at The Plan Is where he is developing web applications that make it easier to plan fixed duration projects. He writes regularly on project management and start ups at theplanis.com/blog.
"Agile project management can be hard to implement successfully because even once you have good practices in place the way projects are run can revert to the old methodology quickly. I would like to share three reasons that I have come across for the reappearance of waterfall project management in an organisation and look at some ways to address this.
The first reason is the sponsor's view of how a project should operate. A client, internal or external, probably has a mental model in his head of how things will happen when commissioning a project.
- The project is briefed to the project team.
- The project team does the work.
- The sponsor checks the work has been done correctly.
- Requirements
- Design and implementation
- Verification
Secondly the business environment can add to the pressure to do single iterations. Most projects occur in an environment with severe constraints. A typical project starts now and ends when the money, or attention, or time runs out. I have worked on several projects where this end date was defined by the last day we could deliver something to avoid being sued.
This kind of time constraint will lead your project sponsor even more towards thinking about their project in a waterfall style as the important requirement (don't get sued) is very clear. The consequence of such a precise requirement is the belief that it must be possible to work out how to achieve that result and then do it right the first time.
Finally, interaction with the rest of the programme can contribute. Generally your project sponsor will be thinking about more than one strand of work at a time. The part which is handed over to you will be going on in parallel with the work that is being done in marketing or operations or by another team. This naturally will reinforce the tendency to plan in a waterfall style, where each strand is completed and then brought together for iteration.
So how can a project team address this kind of imbalance between the process they wish to operate and the natural inclination of their sponsor or client?
The fact that there will be an underlying waterfall project plan, at least in the mind of your project sponsor, doesn't mean that you have to throw away your agile practices.
You probably can't get rid of the waterfall thinking entirely. The constraints and thinking I have mentioned will generally already be set by the time you get involved. However by moving the plan they have in mind up to a high enough level it is still possible for you to implement agile practices underneath.
For the element of the larger project you are working within you can try to pulling your stakeholder in early, delivering small iterations, and changing the specification to closer match the real requirements as you go along.
You will still be aiming to deliver what they want, within the time scales they ask for, just organising it in a slightly different way than they probably expected.
However in order to get this flexibility it is necessary to ensure that project milestones in your sponsors plan are high level and flexible. For example good milestones I have seen are achieve 80% rating on customer feedback, deliver £5,000/day revenue and launch a good product.
Milestones like this offer enough flexibility that another process can iterate underneath working out what the actual definition of 'a good product' is and how to best build it.
In summary, if you identify the hidden waterfall project that is going on and work out how to influence it appropriately it won't necessarily harm your project. In fact knowing about these implicit constraints and deadlines can help you deliver a better result."
About the Author:
Richard Revis has run technology development projects involving everything from iPhones up to front line fighter jets. He is currently Project Director at The Plan Is where he is developing web applications that make it easier to plan fixed duration projects. He writes regularly on project management and start ups at theplanis.com/blog.
26 November 2009 16:59
The transition from waterfall to agile software development requires careful planning, collaboration and change management. 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.