Posts The waste in the way we improve

The waste in the way we improve


The way we are taught to improve is rife with waste, and that waste builds up and prevents us from becoming truly spectacular. So, we need to do something extremely different.

A White Dove Held Against a woman's Chest Photo by Stijn Dijkstra from Pexels

What is Waste

In the book Lean Software Development: An Agile Toolkit by Mary and Tom Poppendieck the seven wastes of software development were defined as:

  1. Partially Done Work
  2. Extra Features
  3. Relearning
  4. Task Switching
  5. Waiting/Delays
  6. Hand-Offs
  7. Defects

Improvement Delays

The biggest waste that I see, is taught in courses and defended by practitioners is the periodic retrospective. Do not get me wrong, a periodic retrospective is a hell of a lot better then no retrospective. The problem here is that it introduces delay. Teams are encouraged to wait until the retrospective to improve, even when they see improvements that can be addressed immediately.

Now I hear those people who say, “That is not how it is intended!” But I do have to disagree with them. The fact that you reserve a time to discuss how the team can improve means that improvement is a separate task that now has a time when it must be done. It also means that improvement done outside of that time if not recognized, and therefore is seen as in the way. Human nature dictates this as being true. My last argument about this is, if a team was improving as things came up, the periodic retrospective would not be needed. It would be a seamless part of their work.

The effect of Improvement Delays

The biggest improvements to teams are often very small things. Working on how they communicate during a meeting, pair programming, or when just hanging out. Working on automating snippets of code that the team types often. Or maybe the test execution time takes several minutes to spin up.

These are all tiny things that can have huge effects on a team. When you wait for a retrospective at the end of 2 weeks you are going to miss the most important and subtle things that can allow a team to soar. Instead, you gain the things that sparked memories that can be remembered until the retrospective.

This of course ignores the Recency Bias. Recency Bias is the fact that the human brain will weigh things that happened most recently as being more important and impactful even if they are not. A periodic retrospective loses important information from the beginning of the interval.

The fact is that a periodic retrospective is just incapable of truly helping a team find the real issues that are impacting them.

This is not to say that all improvement is impossible. However, improvement will plateau and stagnate. It really has no other choice.

Partially Done Improvements

One of the biggest side-effects of the improvement delay is that this delay also causes the team to take on other wastes. One of those other wastes is that we only review the action items of a retrospective at the retrospective if at all. This leaves work open an unfinished for the entire iteration with very little feedback to what it has improved if anything. Then, by the end of the iteration the team finds a new large concern to chase, and the last thing is forgotten.

Task Switching Improvements

This is a subtle waste that appears because the retrospective is periodic. The nature of when the retrospective is held means that improvement tasks are separate tasks. These tasks, because they are long running tasks (see partially done improvements) it means that people cannot focus and get them done. Instead, they have to switch into and out of these tasks, thereby loosing context and built schema for the problem they were working on.

How Can Improvement Delay Be Avoided?

Really, the answer is to integrate improvement into every aspect of our work. Look for those things that cause us pain and remove them. Start with the easier things. Then move to the more subtle.

In lieu of that, reduce delay. Reduce it mercilessly. Shorten the interval, as short as you can and still get work done. I worked in a group that did a retrospective every thirty minutes. Here is a write up of how we managed it. The loss from Recency Bias was minimal, due to the short interval. Also, subtle things were remembered, and obvious things were handled. Very little wait, and very little waste.

This post is licensed under CC BY 4.0 by the author.