6 Strategies to Set Time Aside to Improve
I tried many ways to set time aside to improve how we work and pay down technical debt. Here are 6 ways that I have used or witnessed, with my experience on each one.
The idea of setting time aside to improve, and reduce technical debt is not new. At the beginning of projects we often sort budget for documentation, tests, refactoring. But after a first sprint or two this budget gets used on new features and we end up with technical debt piling up. We all know this is bad, but how can we set time aside to improve? Like, continuously improve? This blog will look at ways I have used to set budget (time) aside to improve.
Note: the 🎙 Tech Debt Burndown podcast is a great resource if you want to learn more on tech debt and how to address it.
Let us just use the following hypothesis:
- You want to set aside 25% of your team capacity on improving
- You have an Agile Scrum team with a 2-week sprint cadence
Here are the 6 ways I will describe below, in one diagram:
1. 25% improving, on top of everything else
When asking an IT leader or manager if they support reducing technical debt and improving how work gets done, the answer will often be yes, with the caveat that this can be done without impacting the delivery of new features.
The risk with this strategy is that you will never find time to improve. Under certain conditions, the team can go an extra mile to improve how they do work. But this cannot last long. Worse, if this becomes an expectation, productivity will be impacted as morale will suffer. Not a good idea.
2. 100% improving
I originally titled this strategy "panic mode".
After a long period NOT spending time on improving, you may arrive to a point where you have no choice but spending all the team's capacity on doing so. This can take the form of addressing a major security breach, swarming during a production outage or even halting the business because the SAN for which you did not upgrade the firmware decided to shutdown.
You can be lucky and recover. Some have gone out of business. If you do recover, use it as a wake up call and select another strategy.
3. The improvement team
You don't find time to improve: the team is overloaded. What about getting a team, approximately 25% of the size of the current team, dedicated to improving? This may work, if the goal is to use that team for a period of time. This way, you may be able to reduce technical debt enough to recover some capacity and get back to the habit of continuously improving.
I will argue that this should only be temporary. Improvement needs to be part of every team's charter. It is more effective and also more rewarding for people. Now, getting help from enabling teams, as described in the Teams Topologies book, is a good idea when you need to acquire skills and coaching to do so.
4. Rolling improvement role
In this strategy, we choose 25% of the people amongst the team who will dedicate the sprint on only improving work and reducing technical debt. That's one person for a team of 4, 2 people for a team of 8 - you get it! You will want to choose different people for each sprint, so that everyone can bring its own perspective.
5. 25% capacity each day
Everyone in the team spends 25% of the day improving. That is 2 hours for an 8-hour workday. You can do that as you start your day, before opening Slack, MS Teams or email. Or at the end of the day, to finish on a good note. If you want to make this work, make sure to spend two consecutive hours, to minimize context switching.
6. Improve one sprint every 4 sprints
This strategy is my own personal favorite. First, it is easy to understand: you dedicate one full sprint out of 4 - that is 25% - improving. It's planned and cannot be postponed. People in the team will look forward to it: as we gather feedback during sprint reviews, it will be used as inputs for the content of this improvement sprint. The advantages of being a complete sprint are numerous: this is uninterrupted improving work, with no context switching. Also, a full sprint is a significant amount of work to be able to come up with improvements which are visible. The team will be able to celebrate and look forward for the next round!
One technique I used was to describe the content of the improvement sprint in the form of an imaginary press release, as we were kicking it off. I have included one of them below. Note that I'm writing to our users, not to the team. This helped everyone understand why we were doing this and align behind a mission, which we could celebrate later once we achieve it.
Conclusion
There are certainly many more ways to set time aside time to improve. Pick the one which works for you, but never stop improving how you work.