Perhaps surprising to some, there are no “best practices” in agile. If there was, there would be no way we could get any better. What a horrible, defeatist thought that would be!
Since things can always get better, there will always be a way to deliver more, quicker, without compromising on quality. We keep finding ways to make it easier and cheaper to make changes as we find out more about the problem our product is solving.
That’s why we strive for continuous improvement, always looking out for things to change and improve. When it comes to our way of working, we never settle for “good enough”.
Many small changes beat one big change
We have learned to maximise the value of the products we build by delivering them in an iterative and incremental fashion. The same method applies to how we can optimise our way of working too. Small frequent changes are easier to implement and make stick than big revolutionary changes.
While each change is small, they all add up. As the Swedish proverb goes:
Many small streams make a big river
If each 2-week sprint we manage to find a way to deliver just 2% more value the next sprint, we’ll be delivering 60% extra value each sprint after a year. By the end of year 2, we will be delivering 160% more value than when we started!
Continuous improvement comes from the team
In continuous improvement, the team suggest and implement the changes. They have the necessary knowledge about what they are doing to be able to judge what improvements are likely to work or not.
If the managers are uncomfortable giving away this control, it is worth bearing in mind that ownership of the process helps the team feel commitment and a motivated team delivers better products.
Aim for perfection, then take one step at a time
As there is no end state, we need to set our goals very high. No individual change is likely to achieve the goal but successful changes will get us closer to it. This way, the changes will build on each other and get us closer to perfection, one step at a time.
For example, let’s say we identify that one thing preventing us from delivering frequently is the amount of time we need to spend manually testing releases, as there are no automated tests. We are unlikely to be able to go from 0% test coverage to 100% in a sprint. If we tried, we wouldn’t have time to do anything else than write tests and even then, we probably wouldn’t finish reach the coverage we were aiming for.
Instead, a good first step might be to star adding tests for all the new code we add from now on. Next, we might identify some key areas that are central to the product, or particularly time consuming to test manually, and add tests for these.
The biggest risk is not trying to improve
If we want to improve things, making changes is unavoidable. As Albert Einstein said:
“The definition of insanity is doing the same thing over and over again, but expecting different results”
However, each change we make comes with some amount of risk. Things may improve or they may not. They could even get worse!
If we made a big change, which took several months to implement, it would be very disappointing (and costly!) if it turns out it wasn’t a change for the better. We will have put a lot of time and effort into establishing our new processes. Because we thought this change was the one that would make all our lives better, we also put on hold other changes that in reality may have made a bigger impact.
When we instead make small changes, all the time, the risk of each change is much smaller. We will be able to see much quicker what works and what doesn’t and adjust course as needed.
That’s why continuous improvement is basically trial and error. We will do our best to come up with the changes we believe will make a positive impact. Some things will work but others won’t. By sticking to the changes that were beneficial and abandoning those that didn’t, we will get better.
The kaizen cycle
Another way to refer to continuous improvement is kaizen. This is Japanese and basically means improvement (kai = change, zen = good).
A kaizen cycle consists of four steps:
- Plan. Come up with a hypothesis. “If we change x, we will get improvement y”
- Do. Conduct an experiment to prove or disprove the hypothesis.
- Change. Evaluate the results. Did the change make the impact we were hoping?
- Act. Based on the result, refine the experiment and repeat the cycle
Each change we decide to implement is in essence an experiment. We try something for a sprint and if it was useful, or if we’re not sure yet, we keep doing it for another sprint. If it didn’t work, we stop doing it and try something else. Therefore, we should avoid making changes that would be hard or costly to revert. For example, if we think an electronic task board will be better than our old physical one, buying a huge touch screen to give it a go is probably a bad idea.
Changes can be made at any time
In Scrum, we make continuous improvement each sprint through the sprint retrospective. Each sprint, the team discusses what worked well and what could be improved and agree on changes to make in the next sprint.
However, that doesn’t mean that it is only during the retrospective that changes can be made. They can happen at any time!
If something bad happens during the sprint – let’s say we deployed buggy code to the production system and caused a lot of disruption for our users – stop up after the immediate issue has been resolved and look at how to prevent it from happening again. No need to wait for a sprint retrospective!
Also, as the sprint retrospective tends to look at the last sprint, it may be a good idea to have a retrospective that looks at a longer time frame every once in a while. This could be at the end of a big release or phase in our project or whenever you feel the time is right.
Evaluate the changes
Follow up in the next retrospective so see what effect the changes from the previous retrospective have had. Have they made things better?
While it is possible to simply ask “How do you feel that change worked?”, you will get a more objective result if you are able to measure the impact. For instance, if the issue you’re trying to solve is how long you need to wait before the test environment becomes available, measure the time and compare it to the previous sprint.
The important thing here is to look at the relative change. We’re not so much interested in whether we reached the perfect state. We probably didn’t! Rather than asking “Did we avoid introducing any new bugs this sprint?”, ask “Did we introduce fewer bugs this sprint?”. That’s all we need for the change to be successful and worth keeping. We can then build on it in the future to improve things further.
In some cases, it may be necessary to continue another sprint before being able to make a conclusion: “It seems as if it worked quite well but this sprint was a bit special because x happened, so let’s see how it goes next sprint”. That’s fine too!
A couple of final thoughts
Frustratingly, not everything that prevents work from being delivered as efficiently as possible will be within the control of the team. In fact, many of the biggest problems are likely to fall within this category. This can quite easily result in a sense of retrospectives being pointless. We keep raising the same points over and over again and nothing improves. It is therefore important to not limit the continuous improvement to the team. It is the responsibility of the Scrum Master to engage with the management to solve these problems.
Another thing to bear in mind is that if we try to make too many changes at once, it will be hard to know what is successful and what is not. Also, if everything keeps changing, it will be hard to keep track of how things are supposed to be working this week. Therefore, limit the number of changes that happen at once. For example, you may want to agree to only proceed with the top 3 suggestions in your retrospective.
3 steps closer to perfection is a pretty good outcome!