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 quality and active bugs are re-solved within each iteration. Testing is a daily affair. Bugs found are fixed immediately. There is no need to wait. The red line representing active bugs is kept low. Quality is non-negotiable. It is a habit of the project team. Everyone is responsible for quality. Everyone emphasizes quality.
Compared to the tsunami development approach, quality comes before functionality. With tsunami development, the project team completes a full function or feature before fixing the outstanding bugs and release when the bug count is low. In the ideal lean and agile development approach, quality is always ensured. On top of this sound and firm foundation, requirements are implemented. The project team is ready to ship the product anytime. If the Product Owner says, “This is enough functionality to make available to the customer,” the team is ready to ship a stable build immediately. Perhaps there is a need for a release sprint, but no more. This makes the project team extremely responsive to market changes.
Development is now continuous. It is lean. It is agile. There is no start and there is really no end. The concept of a project takes second place. Here, the waterfall metaphor is appropriate. Features flow continuously along the stages you would expect for each feature – requirements, design, code and acceptance. The project team takes features from the backlog, finishes them completely before taking the next feature. It is a nice and beautiful waterfall – nobody gets killed, unlike a tsunami.
3. Facing the Reality
Getting to the continuous development model is not easy. It is very difficult indeed. Many do not know how or are not fully committed to achieving it. So, they do what they know and they call it their own brand of lean and agile. But without making an actual change, what they have is a fake. They have iterations, but they are not really iterating. They are puzzled why they are unable to reap the benefits of lean and agile development.
The situation is shown in the Figure 3 . They start off development early. They do some kind of testing. Yes, and found bugs. Perhaps they attempt to fix the bugs, but not quite. Bowing to the pressure to deliver features, they frantically develop new features and the green line moves up. When the system they develop is still small, not so bad. Gradually the system grows. They cease to fix the bugs. The bugs remain as shown by the red line. The bugs accumulate.
Figure 3 - The Great Deception or the Great Reality
They have iterations to look at the bug count (perhaps). But since the bug count grows and nobody really bothers to fix them, gradually, they stop tracking the bugs. Eventually, they stop testing altogether because the system is so difficult to test. At the same time, the system (i.e. code) becomes