1. Tsunami Development
Moving to agile development (or doing anything new) is not easy. Beyond learning some of the technical stuff, the new terms like SCRUM, stories and so on, it is about changing mindsets. How do you change mindsets? How do you understand mindsets, and to do so quickly? I do this by drawing diagrams, and have project teams identify where they are and where they want to be. Of course, these diagrams should be easily understandable, and so that the project team’s response can be quick. You either win them over in 2 minutes, or you lose them completely. The diagrams should also be easily reproduced such as on a white board, so you are always ready.
Following the tradition of an agile discussion, I begin with a discussion on traditional waterfall development, which is the very first diagram I draw (see Figure 1 ). The horizontal axis shows a time line with the project start and project end. The vertical axis is some kind of a measure. So, this is a graph, a profile. These axes will be the same for the other graphs I am about to show. In this first graph, I show the case of traditional waterfall development. Actually, I think the waterfall metaphor is incorrect. The more appropriate metaphor is tsunami-development. Ina tsunami, there is agigantic wavethat sucks up all the water and slams against the shore. If the wave does not kill you, the debris will. This is the case in tsunami development. All postponed bugs and issues (debris) slam against the helpless project team.
Figure 1 - Tsunami Development
Anyway, in this first diagram, the green line shows the progress of implemented requirements. In tsunami-development, implementation does not begin on day one. Instead, there is a lot of upfront requirements work – requirements are collected, analyzed, debated, detailed, documented, designed, tracked, and whatever you can dream of that requirements and design people do.
There is this special day when implementation/coding starts. Either there is some agreement on the requirements and design or it is determined enough time has been wasted and if they do not start implementation/coding, they will never start.
The stakeholders celebrate. The requirements and some design people pant a sigh of relief. The developers started working. So, you see the green line moving up. Everybody is rushing to get requirements implemented. At the same time, bugs are inevitably introduced into the system. Of course at this time, there is no real testing being done. The bugs shown in red are there, but nobody acknowledges it. Everyone has faith that their implementation works. Morale is good.
Then the day comes when all required functionality is implemented and the system is handed over to testing. Low and behold, there is a huge bug list, some more severe than others. The development team now rushes to fix the bugs. They perhaps find more bugs and at this time, stakeholders may want to add more functionality – They are the pay masters, so they have the right to do so. Meanwhile, the developers are frantically fixing and the testers frantically verifying. Until one fine day when the bug count lowers to some acceptable level and the team releases the system.
To summarize the situation, tsunami-development emphasizes functionality over quality. With such mentality, the focus is getting to full function (i.e. functionality) before getting to good quality. So, it is functionality first, quality second. The proponents can argue their hearts out that heavy up-front requirement and design work are meant to achieve quality, but that is really far from the truth. Tsunami-development emphasizes functionality over quality.
This is different with agile iterative development, which emphasizes quality over functionality.
2. Continuous Iterative Development
The diagram in Figure 2 depicts an ideal lean and agile iterative development approach. Instead of postponing development until a complete requirements and design sign-off, the project team begins with what they know and what they are sure of. Those requirements that can be developed immediately can start immediately. Those that are still unclear and debate-able can wait, but they should not stop the stable requirements. So, the green line representing requirements implementation starts moving upward from day one.
Figure 2 - Continuous Lean and Agile Development
Starting early is not the only difference. There is a strong emphasis on