Overburdened Teams are Less Likely to Root Out Waste

Do japanese words muda, muri, mura, etc. add any value or context to this article? Are they used to prove or illustrate any point? Are not they the waist? Do they create a variationfrom the "standard" article language?

On the same note: Is value solely defined by the customer perspective? Would customer always agree to pay for activity that wold not benefit him in the short term? What is about the value in the case of conflict of interests between short term needs of customer A, sustainability of your organization and future needs of the future customer B?

Is it always easy to see immediatly if variation could bring a value? How new innovative standards could take of from the ground if we ban variations from the existing standards?

Does overburden has no rationale at all? Could (should?) overburden be always avoided?

On similar lines we tried to use the Toyota lean concepts in working with a distributed team. The project was a huge sucess.
More details here -->
Agile Offshoring : It’s hard work but it works! on how we worked to make the project a success.

vikashazrati.wordpress.com

Alexander,

Since lean thinking originated in Japan, I use the original Japanese terms in addition to their English translations – like most other Western authors do. This avoids ambiguity that can arise when words are translated.

As explained in the article, I consider software development activities as valuable if they create relevant knowledge or add value from a customer perspective.

Once a lean process has been established, unnecessary variation is systematically eliminated by applying continuous improvement. Watch out for two things: First, create pull or flow and then stabilize the new system before you try to standardize. Second, empower and encourage the doers (developers, testers etc.) to improve their work.

I consider overburden a curse. It is plain wrong. You may gain short term wins but you sacrifice a better and brighter future.

Roman

Thought it's worth pointing to Jim Womack's e-letter that describes how mura creates muri that undercuts efforts to remove muda.

Hi Jason,

Thanks for the link – I had completely forgotten about this e-letter :-) I would still argue that in software development, the first thing you should do is to remove overburden by establishing a pull process. This will cause problems and variation to surface. Once the new process has been stabilized, tackle variation by practicing continuous improvement and standardizing the work.

You may also find Jim Womack’s e-letter on cadence helpful: www.leanuk.org/articles/jim_eletter_200801.pdf. It talks about creating a levelled workflow (heijunka) across the organization. I have found that even though upstream processes such as strategy and portfolio management often need to be improved too, software development is usually the right place to start. Only once we know how much work the development teams can pull and consume, the upstream processes can be adequately adjusted so that value flows smoothly through the entire system.

Best regards,
Roman

I agree. Muri first. then Mura, then Muda. that is the wisdom handed down from the original thinkers of the toyota way.

A little explanation may help here. Overburden is only one symptom of Muri. Possibly the most obvious. But the word really means "irrational". Until rationality is introduced, i.e. an empirical approach, based on fact and logic, expressed through standards, then there is no foundation for future improvement. So eliminating muri is the essential first step.

This link might help here: www.chcanys.org/clientuploads/downloads/Clinica...

Thanks

Richard Henderson

In Lean thinking, pull is established in the entire value stream. It is therefore dangerous to look at pull only from the development team perspective (pulling items from the backlog). If the customer is not actively pulling functionality and cannot keep up with the pace of the team, the team is essentialy just creating muda. I have experienced this first hand where my team was adding functionality at a much higher rate than the customer was able to absorb, resulting in pure muda where test, feedback and even the relationship between the customer and the development team suffered.

Hi,

quite funny the word twisting - what Womack in his letter said, simply was his observation that often it very much seems that uneveness is the root cause of waste. In the end it's in the eye of the beholder, as which is true for many other cyclic dependencies. That's why, in my optinion, the continuous improvement is so crucial to reduce the ultimate target: waste.
And this also makes it crucial that the entire value stream is considered.

I found the book by Larman and Bode (Scaling Lean and Agile Development: Thinking and Organizational Tools for Large-Scale Scrum) particularly interesting in the Systems Thinking section. This is where, sometimes vicious, cycles are discussed. In the end it gives further evidence of why and how agile processes really work (allow teams to work in steady cadences (lower Mura), have the teams being empowered (allow for lower Muri) and do retrospectives (lower Mura).

If you want to get to know more about Mura, check here: kanbantool.com/kanban-guide/what-is-mura