Continuous improvement is one of the main principles behind agile, and arguably how we truly become agile. No agile framework in itself delivers everything we need in our specific situation. Instead, continuous improvement allows us to constantly inspect and adapt, get better and better, one step at a time.

However, this isn’t necessarily easy. Often, misconceptions or old ways of thinking come in the way.

Let’s look at a few things preventing continuous improvement from thriving!

1. The number of features or story points delivered is not the real measure of success

Continuous improvement is not about delivering an ever-increasing number of story points as quickly as possible. There is no inherent value in completing a lot of work. The ultimate waste is delivering the wrong thing incredibly effectively.

Instead, our goal needs to be to find more efficient ways to deliver the desired outcomes for our product. This means finding ways to take us quicker from idea to live software. But also validating that what we are delivering is really the right thing.

2. It’s not the Scrum Master who delivers continuous improvement

For changes to be sustainable over time, they need to be driven by the team’s desire to be as good as they can be. Not someone else’s.

A Scrum Master should certainly play an important role. She is likely to be facilitating retrospectives, where the team can identify problems and solutions. She will often also needs to explain the agile principles and the values behind them. Many times, she will do so by providing stories about what other teams have tried in similar situations.

3. “Best practices” impede continuous improvement

The idea of “best practice”, where there is an optimal way to do something, is inherently incompatible with the idea of continuous improvement, where we always try to find better ways of doing things. If teams are forced to do things the same way as other teams, they are prevented from experimenting and finding the ways of working that yield the best result for them.

This is not to say that teams shouldn’t learn from each other and the wider community. Borrowing ideas from others, if done for the right reason and with the right mind-set, can be a great way to find good ways of working.

4. Improvement is unlikely whilst the team is working flat out

Many changes that prove beneficial in the medium to long term are likely to lead to a slow-down in the short term. Consider for example the effort of writing automated tests. Such tests will help keeping confidence high when releasing in the future. They do however come at a cost, i.e. the extra time it takes to write them.

If a team is under constant pressure to deliver at the highest possible speed, they will have no time to improve. Worse, they may even be tempted to take shortcuts from the practices they have already put in place. That will in turn lead to indreased technical debt and a gradual slow-down over time.

5. You can’t just assume a change will give the expected result

Just because we think the solution we have come up with will solve our problem doesn’t mean that it will. Making changes and quickly moving on to the next thing can easily end up creating process for process sake. We must take the time to follow up and see whether the change made a positive difference or not.

Be clear beforehand what you want the change will achieve and verify afterwards whether it did. Ideally, you want to identify something measurable. This could for example be “reduce the number of bugs slipping through into production by 50%”. Quantifiable metrics like this helps making yourself less likely to fall victim for confirmation bias.

Finally, if you don’t see the improvement you were hoping for, try something else!

6. You must look beyond the team

The time a feature spends being actively worked on by the development team, is in most cases a very small part of the total time it takes to deliver it. Focusing only on this part of the chain only will considerably limit the amount of improvements that can be achieved.

The kind of changes that stretch beyond the remit of the team are impossible for the team to achieve themselves. They will need support from management. If agile is living only within a small bubble, covering only the team, continuous improvement is unlikely to result in that big improvement we were hoping for.