I’ll have to read the article before I can create a complete response. Do you have a link to an online version of it?

In general, though – I understand the problems associated with surface level process fixation. the same problem has occurred with every good philosophy in software development. scrum, xp and the other agile methodologies fail constantly because people only look at the surface process.

lean is a philosophy and long term vision, not a process. i’ve held the philosophy of continuous improvement for a while now, not “follow a process”. kanban is the process that we are starting with, but i’m not stopping with simple process changes.

> we are about to embark on a new journey in our project management processes
>…
> today, my team will be kicking off the following processes

In “Decoding the DNA of the Toyota Production System” (Harvard Business Review, Sept 1, 1999), the authors discuss the common scenarios under which lean efforts have failed in the west.

The most common failure mode was in seeing lean as a process, and in seeing lean adoption as a process effort.

While your enthusiasm for lean is great, adopting lean in a team is fraught with pitfalls, and adopting it as a process improvement effort (rather than adopting lean for what it is intrinsically) is a well-known way to hurt an organization.

What are you doing to avoid the same unchallenged presumptions in yourself that have wrecked havoc in the past for other businesses?