The waterfall model was invented in 1970.
The founding document of the waterfall model, created by Winston W. Royce, included two figures: one of the model itself and a second illustrating the major problems inherent in the model, or the reasons not to use the waterfall model.
Winston’s waterfall method tried to address” Cone of Uncertainty” problem by fixing functionality upfront and got it all wrong – and then he mentioned that in the same article, second page: “The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a 100-percent overrun in schedule and/or costs”.
Now something completely different?
(next paragraph from Wikipedia)
Henry Gantt was born in 1878. In 1887, he joined Frederick W. Taylor in applying scientific management principles to their work at Midvale Steel and Bethlehem Steel company. In his later career as a management consultant, following the invention of the Gantt chart, he also designed the ‘task and bonus’ system of wage payment and additional measurement methods for work efficiency and productivity.
Gantt designed his charts so that foremen or other supervisors could quickly know whether production was on schedule, ahead of schedule, or behind schedule. He describes two types of balances:
- the “man’s record”, which shows what each worker should do and did do
- the “daily balance of work”, which shows the amount of work to be done and the amount that is done.
Gantt charts became extremely popular within waterfall community, as they truly believed that you can solve software engineering problems using 19th Century methodology designed for blue colors workers.
So, how we got screwed?
Gantt charts and waterfall eventually created “some” problems:
- SW development seen as blue color work, that lead to
- “Caste development hierarchy”: requirements, system architect, sw. architects, coders, testers, which eventually lead to
- Moving testers and coders to off shore (since nothing can go wrong), which lead to
- More management overhead and more paper work, which lead to
- Less willingness to change any requirement, which lead to
- SW development crisis
In my next blog post, I will shortly explain India’s “triangle” business model, and why this model typically leads to big trouble. I will then cover how I approach the same issue (about 6 years ago), working hard with our outsourcing partner – which has lead to the long lasting collaboration and great commercial success of our product.
As mentioned in the previous post, most of the agile transformations these days are “top-down”. According to Standish Group “Chaos Reports” we still have more project failures than successful projects. One of (many reasons) for this you can find in my previous blog post (how we got screwed in the first place
), but there are many reasons for the failures, and to be frank plenty of books written about that.. As Tolstoy wrote once “Happy families are all alike; every unhappy family is unhappy in its own way.”
So, here we have unhappy stakeholders, and the first thing they have in mind by going agile is to get all their problems fixed. As your task is to get it done, be careful at the beginning, since before you know it, you can be dragged into endless meetings, mea culpa sessions and get nice list of issues that people expect you to clean up for them. That is reason why people prefer to have consultant for that job, first they are well paid to deal with all that mess, secondly they are seen as “deux ex machina”, someone that can with no fear say and execute on his plans (what most of the people inside company would do anyway but afraid to openly say), and finally if the guy is really good and have support from the high management – he can eventually make it. So, don’t get me wrong, good consultants with charisma can make it happen.
In order to succeed in any transformation, it is essential to have strong support from stakeholders. Therefore, after educating them on what agile actually is (you can find plenty of good books around), you should first split the transformation in 5 different segments:
- Management practices – Improve communication, efficiency and transparency (visibility, inspection and adaptation)
- Engineering practices – Improve quality of our products (early testing, continuous integration etc.)
- Tools – Implement the right tools that enable us to be effective in both engineering and management practices
- Process – “formalize” agile process across the organization.
- Project specific issues – (parking lot for things that need to be addressed per each project)
The usual transformation trap is that people start talking and mixing all things at once. Operational folks are very often process freaks and when they talk about process they somehow talk tools and when we start talking tools we start talking IBM/HP …. Stop it, stop it, this is endless !!!!
You need to go back and split the problem, and remind all folks that on each segment there will be separate meeting and that for different issues, you might need to consult different people.