It is amazing how many companies talk about their iterative approach in project management, while in practice projects are managed with waterfall process. Read more and learn why software development projects should not be managed with waterfall process.
Does this sound familiar?
“No, we don’t anymore run our projects with waterfall process. Actually we apply iterative methods, such as RUP (Rational Unified Process) and Evo (Evolutionary Process). In this current project we have been analyzing our requirements for the last few weeks, and as soon as our requirements are frozen, we’ll start our first iteration. Our system test phase is scheduled in six months, so we gotta hurry up..”.
What is wrong with that typical scenario? I have heard it many times, and I can quickly tell you what is wrong with it, but let’s think about it a little more.
Waterfall process was the first step towards structured projects
The problem with the scenario above is that the person talks about applying iterative processes in project management, but in practice the project is managed in waterfall fashion. You can clearly notice the phases, such as requirements analysis, development and system tests. The person clearly knows something about iterative processes, but still keeps on leading his project with waterfall style.
Waterfall process is a sequential process. In its most simple example, waterfall process includes a number of separated phases connected from beginning to the end. Those separated phases are
- Requirements gathering and analysis
- Software architecture and design creation
- Implementation (programming)
- Integrating and testing, and finally delivery
Basically the product should be ready after step four has been completed. Anyhow, it usually does not really work like that. Waterfall process was invented during the ad-hoc style hacking of 1960’s. It was the first step towards structured software development. I bet introducing waterfall process actually caused more harm than good, because running big projects with waterfall process increases risks and lowers productivity.
The interesting dilemma is that waterfall process is probably used because it is easy to manage, while it is unsuitable for complex projects. You probably did not know that the founder of waterfall process (Winston Royce) has said that waterfall process was only applicable for the most straightforward projects. Software development projects do not belong to that category.
Have you noticed that in waterfall projects difficulties tend to gather to the end of the project? It is the nature of waterfall process to push risky elements toward the end of a project, while iterative methods aim in resolving the hardest and riskiest elements early. Probably one the most annoying thing with waterfall process is the large steps with overwhelming degrees of complexity.
Iterative projects should not be executed waterfall style
Although it is clear that iterative processes provide better results in software development, many managers and organizations still require project to develop software in waterfall style. May be the reason is that these managers studied their diplomas during 1970’s, and they have missed the iterative train long time ago. It is totally understandable.
While waterfall projects contain higher risks, iterative projects contain lower risks. This is due to many reasons, but one reason is that risk-driven iterative projects discover and mitigate risks very early. In iterative projects tasks are continuously prioritized, and because of that the riskiest problems are addressed first.
Iterative processes can be managed with waterfall style, but that does not really make sense. Therefore projects managers leading iterative projects should make sure they really understand how iterative processes work. Leading an iterative project is usually a bit more difficult than leading a waterfall project, even though waterfall projects tend to have serious problems. If you are not familiar with iterative processes, check these books in order to learn more.
- Mary Poppendiek – Lean Software Development
- Mary Poppendiek – Implementing Lean Software Development: From Concept to Cash
- Alistair Cockburn – Agile Software Development
By the way, whenever someone in your project talks about signing off a requirements specification, or freezing the requirements in order to avoid changes, you know it is time to suggest the person the books listed above.
Leave Your Response