Improvement Mondays

A step towards continuous improvement

5 min readAug 16, 2021

In software development, it is easy to get feature blindness, where we focus almost all of our energy on delivering features to the detriment of productivity, quality, and job satisfaction. In order to sustainably deliver high-quality software, it is imperative that we remember and prioritize improvements to our culture, skills, and tools.

If a team spends almost all of their energy on delivering features, we say they are highly aligned. A team that is highly effective is productive with relatively few resources, this enables growth in the organization. A report from MIT Sloan Management titled “The alignment trap” found that it is not possible to move from highly aligned to highly effective directly. Instead, in order to improve effectiveness, we need to reduce our alignment and focus some of our capacity on becoming more effective.

Models for reserving 20%

To increase our effectiveness we have to focus on non-functional requirements (see the previous post). According to the DevOps Handbook, the balancing point is 20%. Meaning that if we spend less than 20% of our time on NFRs we are sacrificing long-term sustainability and building debt in our processes, knowledge, and codebases.

Reserving 20% of our time for improvement work is not trivial, and there are multiple ways to do it. Let’s briefly discuss the pros and cons of different models.

Add 20% to all tickets

Probably the most intuitive way to create this capacity space is to add 20% to all our estimates. This means it is a convenient way to communicate the need to customers and product owners, who are not interested in the details. In practice, though this approach suffers whenever our estimates don’t hold. When estimates go over these 20% tends to be the first thing we cut out. Even worse, estimates tend to be less stable the more we need refactoring. That means the teams who need the time most, are least likely to get it. The final caveat with this method is that the 20% are fragmented into small pieces, so we pay for the context switch many times, and it is difficult to do major improvements or experiments.

Reserve every 5th person

Another approach is to reserve 20% of the people for tooling and improvements, which addresses context switching and fragmentation. However, it presents its own issues. Namely, the team can start to feel fragmented. The tooling person often doesn’t share in the sprint goal of the rest of the team. It is also difficult to summon the same level of motivation for someone else’s issue, as the people who have the issue.

Reserve every 5th sprint

To get this whole team commitment, without fragmenting their time we could do a “refactoring-sprint” every once in a while. While this sounds like a great opportunity to get everything done, in practice it is an exhausting experience. It is near impossible to keep up motivation and morale when spending two-three weeks intensively fixing broken things.

Reserve every 5th day

Finally, we can choose to spend every 5th day on improvements. This approach tends to give the best results in practice. It makes it hard to be overrun by estimates, it does not cause context switches, and it is a whole team approach. It is also continuous in bite sizes that are easy to handle.

Why Mondays

It is not irrelevant which day we choose. If we reserve one of the mid-week days we cause a “mental break,” where we disturb the delivery momentum built up during the week. If we spend one to three days building features and fixing bugs, our brains are filled with models of the software. Fridays might work, but often these are shorter and are more subject to meetings.

Choosing Monday has the advantage of not having any mental break, as we typically don’t think about work during the weekend. It also has the added benefit of making team members look forward to coming back to work, to experiment, learn, and improve.

How to run an improvement Monday

On the day we have a few different micro-events we go through to ensure we are as efficient as possible. Note that during the first one-three times these times are probably inflated because we are learning.

Team health [7 minutes]
We start the day with a health check from the Spotify model. This is to assess whether there is improvement and detect any unusual drops in any area.
Pitch ’n’ recruit [7 minutes]
Then it is time to pitch what we want to work on. Any team member can suggest anything they would like to work on, and also specifies whether they need assistance. While the options are pitched, people can choose which they want to collaborate with. As general advice, there should always be at least two people per task.
Specify goal [10 minutes]
When the groups are formed they spend the first 10 minutes coming up with an action for the day. This helps to keep focus and make sure we are productive. We recommend writing these on post-its and putting them on a board for everyone to see.
Focus time
Groups work together trying to solve the goal. To boost teamwork and knowledge sharing we recommend doing pair or mob programming here.
Review [15 minutes]
The day concludes with a short review; did we solve the action we specified? Why/why not?
Mini-retro (LLL) [15 minutes]

During the mini-retro we talk about:

What did we Love about today?
What did we Learn today?
What did today Lack? (Ie. should be changed next time)

As collaboration is a crucial part of this process it is important that all team members are present the whole day. Therefore we prefer 6 hours with 100%, over 8 hours with 80% of the team.