I am frequently asked to give a brief overview of Scrum to people who are unfamiliar with Agile concepts. In the course of giving those lessons, I almost always see a look of shock at the almost cavalier way that we agilists claim that Agile methods will give a better result than traditional methods. I like the look of shock. It shows that they’re paying attention. I then follow it up with the evidence that demonstrates that we got better performance from teams after we switched to agile methods. Although I enjoy it immensely, I realize that the shock & awe technique is not appropriate for all audiences. So for those occasions where a softer approach is needed, I like comparing notes with other agile advocates who have been kind enough to share their thoughts and opinions online.
Thus I found myself scrolling through Michael James’ Introduction to Scrum deck. One slide in particular caught my eye – a visualization of Waterfall performance compared to two extreme Agile implementations – one the traditional view of Agile outperforming Waterfall by strict adherence to a Agile practices. The other demonstrating what happens if Agile is not approached at this level of commitment. I liked the visualization so much that I’ve dissected and extended it and want to walk you folks through my interpretation. The image in question was “inspired” by Ronald E. Jeffries so I’d like to give him a nod as well).
First, we are all familiar with this visualization (Figure 1) depicting the execution of a waterfall project. Waterfall, by definition delivers no complete features until the end of the project. The sloped portion of the blue delivery line reflects the end-of-project validation and cleanup of features that were developed throughout the project. As this final validation cycle progresses, more and more features are certified as being complete.
We are also familiar with the claims that Agile applies well-established principles and practices to achieve improved project execution. Agile frowns on things like big up front design, a practice which virtually guarantees that time will be wasted evaluating features that will never get implemented. By focusing first on the most important near-term work, Agile allows the teams to start developing features sooner. With testing embedded in the iterations, defects are detected closer to their inception, thus reducing time and cost of eliminating them. This elimination of delayed rework gives the Agile project the potential to continue developing new features longer. The continual slope of the green delivery line reflects the fact that Agile delivers features that have completed development and testing throughout the project lifecycle.
Agile methods achieve this increase through a very robust definition of what it means to say that a feature is “done”. Agile encourages the use of techniques that are designed to inject quality at an early stage of development, and to maintain that level of quality throughout the project. Early quality means less time is spent at the end of the project addressing defects. Therefore more features can be delivered in the same amount of time.
Details of these Agile practices (Pair Programming, Test Driven Development, Refactoring, Continuous Integration, Frequent Builds, Retrospectives, etc…) can be found in a variety of other sources. Individually, each of these Agile practices augment the standard practices of Unit Testing, Code Review, Feature Testing and Integration Testing. Together, they combine to form a quality control gauntlet that your cross-functional teams can rely on to put each new feature through its paces. Once all of these criteria have been met, the feature is said to be “done”.
One of the biggest challenges faced by teams that are new to Agile, is the lure of bypassing these recommended activities. When you first introduce the concept of Pair-Programming for example, many people are inclined to think you are spending twice as much for every feature you develop. They don’t realize that the second pair of eyes is actually performing a necessary and valuable service by helping catch defects the moment they are introduced. What seems like an unnecessary burden at the start of the development effort quickly demonstrates its value in reducing the number of defects that make it through to testing. Test Driven Development suffers a similar stigma. If every piece of code requires a failed, automated test be written before any working code can be written to cause the test to succeed, am I in effect writing all the code twice? They fail to realize that having an automated test in place that executes with every compile will prevent you from introducing logic errors that will damage already-completed code. It also gives you the freedom to refactor code with confidence that the rewritten code is functionally equivalent to the original code.
In the name of increased productivity, these teams will cite one particular Agile tenet as justification for their actions: namely that you optimize out any activity which doesn’t provide value. While Agile does allow such determinations to be made, it also requires those determinations to be based on experience (try it first), rather than speculation. The red line (see Figure 2) shows the initial increase in velocity the team will enjoy by skipping the quality practices. A team that skips some or all of the practices is embracing a Weaker definition of “done”. They will initially outpace their more disciplined Agile counterparts, and will be a blur of productivity compared to their Waterfall cousins.
As time passes, the red line quickly levels out. This is due to the fact that more and more defects will be revealed in the already ‘completed’ code. Testing couldn’t uncover the design flaws or the uninitialized variables. The developers will have to go back and rework sections of code to make up for these flaws, but without the benefit of automated tests, will refactor different defects into the code base. They will quickly lose their edge over the more diligent Agile team.
The inspect & adapt cycles at the end of each iteration should provide opportunities for the teams to recognize the growing list of defects in ‘completed’ code. However retrospectives are one of those Agile practices that is frequently skipped by the inexperienced team. If used properly, the retrospectives should provide opportunity for the team to realize they cannot afford to gloss over these Agile activities. Failure to address a weakened interpretation of “done” will ultimately be catastrophic to the project.
In fact, if allowed to go too far, a project team that tolerates this behavior could underperform even a Waterfall project.
Agile done well will produce a positive effect.
Agile done poorly can be worse than not doing Agile at all.
The missed opportunities, nagging design flaws, overlooked defects, and the low quality that results is referred to as “Technical Debt”. The yellow shaded area (Figure 3) represents this lost productivity.
Bear in mind there are different types of technical debt, and not all of it is necessarily bad. There is planned technical debt, in which you intentionally accept a limitation in the design. This is usually a short-term situation that you tolerate with full knowledge that there is already a plan in place to address that debt at a later date. There is a risk that circumstances may prevent you from addressing these shortcomings before shipping the product, in which case your short-term debt becomes long-term. The shaded area in the chart really refers more to the unplanned defects; the unnoticed bugs. This type of Technical Debt will take one of two forms. The first will be the minor defect that contributes to an overall lack of polish. The product as a whole suffers for having these minor annoyances. The second unplanned flaw is the kind that will spring up at the worst possible time, sending the development team into a panic to find a quick solution to something that is perceived as a critical flaw.
Whatever form it takes, Technical Debt is work you really need to perform before you can ship your product. The existence of Technical Debt means that you do not have a potentially shippable increment of work after all. Sooner or later, you will have to address the issues, or ship with compromised quality.
It is impossible to predict the magnitude of these shortcomings. If the issues are big enough, the payment of debt will outstrip your ability to create new features, resulting in a decrease in the number of delivered features. In its most pronounced form, your poorly executed Agile project will fare worse than Waterfall.
Agile methods are an amalgam of many product development practices. They all derive from a desire to recognize and embrace the core Agile principles: Embrace change, work in small cycles, adjust your course frequently. Ultimately, the success of any project will come down to how well the team adapts to the ever-changing list of challenges that they encounter.
Agile methods provide powerful tools to help teams navigate the unknown. They are there to help you. Remember, a tool that remains in the toolbox provides no benefit.
