Level out the load (Heijunka)
The best-known Lean technique is the elimitation of "Muda" or waste, but you can only do that if you also eliminate two other M's:
- Muri or Overburdening people or equipment. Overburdening people results in safety and quality problems. It can lead to burnout, which makes you lose good people and lots of knowledge and experience.
- Mura or Uneveness. If the workload or the type of work fluctuates wildly from one moment to the other, people (and machines) never "get into the rythm" and waste time switching between tasks. The production stalls and restarts all the time, workcells don't get the required raw materials. Lean Production uses "Takt Time", a fixed rhythm which governs how fast each workcell works; Theory of Constraints uses the constraint as the "drum" to dictate the rhythm of the production line.
Applications in (Agile) Software Development
- Sustainable Pace is clearly an example of Muri. XP recognizes that it's no use pushing people beyond what they can reasonably perform. When I'm tired and doing overtime I write crap software, loads and loads of it. Been there; done that
- Dividing a release into relatively small stories is an example of Mura. If each story can be implemented in (at most) a few days, this sets up a nice rhythm: we get a little jolt of satisfaction each time we finish a story and start another one. We feel that we're making progress. Small stories are also easier to estimate, more flexible for planning, make stakeholders really think about what we need, give a more fine-grained tracking, are easier to understand. That's why I recommend to only allow for a small variation in story point estimates: 1-5 is what I usually use. I've had some bad experiences using larger numbers.
- Dividing a project into small releases has the same beneficial effects as small stories within the release. A team with a regular rhythm of story-writing, planning, implementation, putting stuff into production creates value sooner and has lots of real, useful feedback. Important work can't be postponed. Make sure that you start lining up the next release when this release is nearing its end, using "rolling wave" planning.