How does the use of sprints (takt) eliminate waste?

By reducing Mura & Muri.

Mura – Variability

Imagine a lean auto plant with a 60 second takt. Expectations for everyone are clear. You will be done in 60 seconds. If you cannot consistently do your job in less than that, there is a problem. In 60 seconds, the next car will be ready for you.

Imagine if my job takes 60 seconds, but the next car arrives at random. Sometimes it arrives in 20 seconds. Sometimes 300 seconds. I will need to worry about this. My attention will be split between doing the job and tracking incoming cars. I may even build special tools or modify the line to include staging areas. Doing this will help me manage the work, but this is an infrastructure I’m putting in place to help me manage the variability. It isn’t adding any client value. Unfortunately, I need to do this because I cannot be assured that I have enough time to do my job. If the next car is coming quickly, I may need to cut corners and just move on to be ready for it.

It’s similar for creative teams. If we simply take work as it comes with no process to control it, we will invest a lot of energy into knowing and tracking the various due dates, conflicts, and needs. We may build waiting queues and layers of vetting to “speed things up” once we’re ready to start the work (if you think this will work, look at the system optimization that is lost in a production cell). A lot of mind power will be invested into just keeping everything in motion so that nothing appears to be failing. When deadlines conflict, we sacrifice testing, unit tests, or code reviews (or worse) to keep up.

If we create a predictable pattern to enable delivery, people can start investing their mental energy into client problems rather than tracking the variations in our planning processes. There will be more about this tracking (managing work variation) in other articles.

However, this takes a great deal of discipline. Not only must you respect your takt, but you must balance the work so that you are able to consistently deliver to your quality standards (testing, unit testing, etc.). There will be more about this balancing (managing skill variation) in another article.

Muri – Stress

It is that propensity to take on too much work, which creates so much stress for white collar workers. In manufacturing, the line controls flow. You can’t physically have two cars in your work station. For software engineers, you can have the entire backlog in a “doing” state and nothing will stop you. Juggling between what’s “on deck”, “getting started”, “wrapping up”, and “being supported” can spread your attention thin. The context switching alone can wear you down, let alone the greatly reduced ability to get things done due to the sheer volume of things you’re trying to do.

Sprints offer a way to overcome this.

At the sprint’s beginning, we plan. We plan as much as we can reasonably complete and focus on the most valuable things we can do in our limited time.

This protects us from having the entire backlog in process. It focuses us onto a body of work we can achieve. This can greatly reduce the stress on team members while ironically increasing throughput by eliminating much of the context switching.

In software development, the formal spring planning limits the “in process” work so it can’t overwhelm the team. If that seems overly simple, it is. That’s also why it’s powerful. Sprint plans help protect white collar workers from themselves. It makes sure their commitments are reasonable targets for completion, and this gives them both focus and satisfaction every sprint.

Challenge

Does your sprint process control variability in a way that enables focus?

Does the team limit he work in each sprint to that which can be completed?