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 more and more complex (represented by the blue line). Cyclomatic complexity goes beyond 20 or 40 or even a 100. Source files become big – several are 100kB. Much time is spent merging the files before checking in, which is accepted as normal behavior. There is no time for refactoring. But they have all the time to suffer the consequence of bad habits.
The reality remains that the emphasis is functionality before quality. There is no real improvement. They will eventually give up one day and blame it all on iterative development – saying that it does not apply to them. The situation is not very different from tsunami-development. Still, the fact remains that they do have iterations –
About the author
The opinions and positions expressed within these guest posts are those of the author alone and do not represent those of the TechWell Community Sites. Guest authors represent that they have the right to distribute this content and that such content is not violating the legal rights of others. If you would like to contribute content to a TechWell Community Site, email editors@techwell.com.
