How much effort should we spend improving?
Agile is all about iterative development, continuously adding value and continuously improving our product and our process. In all too many companies Agile is adopted without really investing in continuously getting better. The business may get the benefits of incrementally adding value, of greater predictability, but does quality rise? Does the team throughput increase? We would like to imaging that a team can continue forever delivering the same amount every sprint.
If teams just work on development work and don't put effort into improvements in their process then the teams will get progressively slower. Consider a team working in sprints, in the first sprint lets say they are able to deliver 100 units of work (story points). In the next sprint as well as doing new work, they have to retest the existing work, rebuild the existing code and so they will be a little slower. We will refer to this as entropy. If entropy were just 3%, i.e. in each subsequent sprint the team deliver 3% less than the previous it has a significant impact on velocity and the total amount of work done over a year, see below, in one year the velocity (work per sprint) has halved, and the total amount of story points delivered has dropped significantly, by over 25%
In SCRUM arguably the most important of the ceremonies is the regular, once a sprint retrospective. The retrospective is all about getting better. The intention is to look at the process of the team and progress after the last sprint, then to identify one or two experiments that should improve the process. These improvements could be in how agile is applied, or changes to the build process, training, investment, whatever the team thinks will is most likely to reduce or improve their biggest current bottleneck. So if this meeting identifies a change, what percentage of the teams capacity should be reserved to make improvements?
As a starting point, lets consider that a team estimate that they can completely overcome entropy of 3% if 20% of the team's effort is put into improvement work, rather than adding new features. In the first sprint that team would only deliver 80 story points. What is the impact over a year? Below we can see that the velocity stays constant at 80 units per sprint (overtaking the team doing no improvement work in about 8 sprints or four months), and over they year the improving team delivers more total work, the payback coming after around 17 sprints.
Perhaps the team was over optimistic and they can only achieve 2% gains for 20% of their effort. As we can see below, the team that is improving still outpace the no improvement team after twelve sprints, and deliver a fraction more over the year.
How about the more exciting case where the team manage to beat entropy, and deliver say a 4% improvement each sprint for 20% effort on improvement? At the end of a year the improving team is delivering twice the work every sprint and has delivered more total work after only 12 sprints.
Now there is no hard rule that says that with 20% effort on improvement a team can beat entropy. Do the numbers hold up if it took the team 30% of their effort to match entropy? Delivering only 70% of the work in the first sprint? Payback still happens within one year!
The numbers here are illustrative. However psychology tells us that the human brain is poor at estimating the impact of compounding changes. Our experience backs up this data, teams that consistently spend whatever is required to maintain velocity significantly outperform the teams that are just focused on short term goals and delivering immediate value.
Download
Download BenefitOfIterativeImprovement.xls to review the data behind the graphs and to experiment with more scenarios. Only these cells should be edited to try different scenarios.
