Wasteology - definition of waste

In Lean software development, there is a discussion regarding the definition of "Muda"(waste). In Lean manufacturing (or TPS), "waste reduction" or "eliminating waste" is the first key to be lean and "seven wastes" of production is a famous practice
to train managers eyes at Gemba. But in software or in the product development world, it is very difficult to distinguish waste from creativity or effective slack.

David Anderson (if I remember correctly) once discussed that waste is the tail-side of value and they are the two sides of one coin. So in software development, we should go back to the principle level and focus on "value flow" rather than "waste reduction".

Alan Shalloway keynoted at Agile Japan 2010 and proposed to use "delay" to be removed. Now "delay removal" is a better wording of the practice than "waste removal".

Don Reinertson also discussed this at Lean Sofware and Systems Conference 2010.

Here's another story.

Last week we visited Danish Embasy yesterday, to listen to Prof. Nishinari's "wasteology". He is also famous for "jammology" and once appeared in the bakusho-mondai's TV show.

He says defining "waste" is not easy. This is the diagram he showed us in the session.

First, a "purpose" and a "period of time" should be set first in order to define waste. Without proper settings of them, many arguments about whether one thing is a waste or not, comes from lack of shared ideas of purpose and period. The purpose becomes the axis of value, and the period becomes the point of evaluation. And the profit is defined as the difference between the output value and the input cost. Then his definition goes;

When you want to achieve a certain purpose in a certain period of time,
“waste” is the factor(s) which makes the actual profit lower than the expected one.

Now I'm thinking... how can we use this definition in our world to be practical ?

TPSでは、「ムダどり」が導入のポイントとなります。ムダを見る目、を作ることがカイゼンマインドの１つになっています。ところが、ソフトウェア開発の世界ではムダを定義することがとても難しい。顧客の目で見た価値付加、ということを突き進めて行っても、ソフトウェア開発での「イノベーション」との接点を意味のある実践として語るのは難しいことです。

David Anderson はムダの裏側の価値を前面に押し出して、価値フローを作る、ということに注目すべきだ、という議論をしていましたし、Alan Shalloway はムダでなく「遅れ」ということでより具体的にすべきだ、という議論をしました。

もう１つのヒントを探そうとしています。デンマーク大使館で、「渋滞学」や「無駄学」で有名な西成教授のミニ講義を受けました。そう、あの爆笑問題の「日本の学問」に出た先生です。その中で、先生は、以下のようにムダを定義しました。

最適な、もしくは予想上のインプットとアウトプットの差益より、実際の益を低くしてしまう要因

ということで、目的（益の尺度）と、期間（比較する時点）をはっきり定義しないといけない、ということでした。

さて、これをアジャイルの文脈でどう生かすか。。。というのを考えています。

（※ 4/30日追記：これは、北村さんが描いてくれたマインドマップです。（クリックで拡大））