Traditional software development is affectionately called waterfall development. I believe this metaphor is inaccurate. A more accurate metaphor would be a tsunami. I guess most of you have seen a physical waterfall some point in your life. When you see one, what do you do? Most likely you will take a selfie, and marvel at God’s creation – what a lovely sight. But what would your response be when you see a tsunami? There is no time for selfies or twitting. You run! Tsuanamis travel at about 1000 km per hour in the open ocean. You run.
Traditional development is more like a tsunami. The devastation from a tsunami derives from its two gigantic waves. The first wave uproots buildings and trees, and the second wave crushes the population with the debris. If the first wave does not kill you, the debris will. So, you run.
Figure 1 Traditional Tsunami Development
And so it is with traditional tsunami development. Decision makers horde up loads of requirements, and once a decision is taken after the requirements phase, this gigantic wave of requirements is unleashed on the development team. During the development phase, teams rushed to realize the requirements and at the same time unwittingly introduce bugs in the software. Because the onus is to add functionality, bugs are not fixed leading to a build-up. The test phase release this second wave of debris on the development team. If the first wave (large build up of requirements) does not crush the development team, the second one (large build up of bugs) will. If the second wave does not crush the team, never mind, the next tsunami (the next project) will.
The whole idea behind tsunami development is that “we will have the functionality in the system first before fixing the quality”. So, it is functionality before quality. Quality is a second class citizen. The software system is released when quality is acceptable.
Ideal Lean Agile Development
The ideal lean agile development takes a different approach. It is quality before functionality. Instead of waiting for all requirements to be agreed, which causes the build up of requirements, modern lean agile development say, “Let’s start working on those we know we must do.” This reduces the build up of requirements.
Figure 2 Lean Agile Development
Lean agile development does more. It says, “Before adding new requirements into the software system, lets fix the bugs first.” Thus, no requirements are added until bugs are fixed. In this way, there is no build up of requirements nor bugs. So, there is a continuous flow or work, finishing work before taking on the next. This is very much like the beautiful waterfall that you like to take pictures of. Water flows continuous and beautifully.Excuse Programming
Due to legacy reasons and otherwise, novice who begin adopting lean and agile normally does not have the mechanisms in place to control the flow of requirements and bugs. I call this Excuse Programming (XP’) as a pun to Extreme Programming. Novices give all kinds of reasons and ‘buts’. I understand, I empathize, but this not lean nor agile. What they have is the behavior of agile, with iterations and all, but the spirit of disciplined agility is absent.
Figure 3 Excuse Programming
Yes, they have iterations, but the iterations have bugs. Before allocating effort to fix these bugs, they continue accepting new requirements. As a result, bugs build up. Under the pressure of getting requirements into the software system, they patch the code, increasing its complexity without constant refactoring.
They have the same “Functionality before quality” mindset just like tsunami development. But I deem this is a necessary journey. At the very least, they have iterations, and they start testing early. Even though they do not fix the bugs in time, they know how many bugs exist in the system. Give them some encouragement. They are new to agile, give them a pat on the back at least. But it should not stop here.
Disciplined Agile Development
Moving towards lean agile development takes both discipline and perseverance. The team and probably leadership needs to recognize that it is hard work. Becoming agile is not a simple as waving a flag. It is hard work. It takes consensus that the team will be allocated effort to fix the bugs before accepting new requirements. It is “Quality before Functionality!”
Figure 4 Persevering Disciplined Agile Development
Quality is not just fixing bugs, it also includes having good code, managing the complexity of the software system, applying sound design principles and patterns rather than merely hacking away.
In the beginning it means leadership allocating time to the team to fix these problems. As the teams dedicate and build the habit of fixing problems early, they grow. With perseverance and growth, this will become second nature, and the team will inch towards ideal lean agile development – that smooth continuous flowing waterfall stream.
Never mind that that development will be slower at first. You are building up strength and capability. That is alright. Moreover, being slower initially not only give development team the think and learn, it also compels the requirements folks (e.g. Product Owners – PO) to choose the most valuable set of requirements to implement. My abbreviation for PO is not just “Product Owner”, but also “Prioritize and Order”. This is an important thing that a product owner does – he/she maximizes the outcome within the constraints of team productivity, by systematically and actively prioritizing and ordering work. The development team is also actively improving its workings, through automation, through better collaboration, and so on.
Success in adopting agile requires the whole team to collaborate, base their actions on sound principles, and continuously seek a better way to work together. This demands discipline; this demands perseverance. It takes the whole organization to provide this environment for such behavior to flourish.