Wednesday: Lean IT and Coffee with Mike Orzen

Today I met with Mike Orzen of Steady Improvement. Mike and his colleague Steve Bell recently wrote the book: Lean IT which is the WINNER OF THE 2011 Shingo Research and Professional Publication Award. After chatting over coffee at one of the ever present Starbucks in the Seattle area, I attended the ASQ/APICS dinner meeting where Mike spoke about Lean IT.  There is so much synergy between Lean and Agile and yet in some areas they are diametrically opposed. I plan to have many more discussions with Mike and even have him as a guest blogger, and guest on the podcast.  So, look to hear more about Lean IT here at Whitewater Projects. From his talk at the ASQ/APICS meeting I had a few take away items that I want to share. In my talks with the Agile Manifesto authors, I found that many of them said the one thing they would change in the manifesto is to add something about quality.  Well Lean is all about quality so it is no surprise that Mike started out by sharing W.E. Demming’s definition of quality

Quality = Pride of workmanship.  Individual responsibility for creating quality work.

I couldn’t help thinking of Christopher Avery Next was the definition of a defect. Now think about this in the context of manufacture and then in the context of software development, the two are quite different.

Defect = anything that is not 100% right the first time

Can software development live with that definition of a defect? Should it? I will discuss this in a future video podcast. This next one was really good.  But you have to learn some Japanese; Most Lean books talk all about MUDA and not about the other forms of waste. So, managers spend a lot of time worrying about and getting involved in removal of Muda. BUT they shouldn’t. Management is not qualified to remove muda, that is the role of the line worker, of the team member.  Management should focus on Mura and Muri where they are qualified and even mandated to be effective.

OK last point:

All too often, people focus on implementing Lean techniques, or Implementing Agile practices. But this will ultimately be unsuccessful.  And piled up in the corner with last months management fad unless the PRINCIPLES of Lean and Agile are adopted first and foremost.

If the principles are adopted then the correct suite of techniques and practices that complement the culture of the organization can be selected and applied. thanks for stopping by.

Let me know your thoughts on these matters in your comments below.

About the Author:

One Comment

  1. Michael Alan Orzen March 18, 2011 at 6:55 am - Reply

    The goal of quality (zero defects, everything done right on the first pass, no corrections, clarifications, rework) as described in our book “Lean IT,” is a theoretical goal. Lean is a philosophy as well as a never-ending process of improvement. Will we ever achieve this level of quality? That’s not the point – the purpose is to strive to eliminate waste so we can flow value to the customer. Poor quality creates unplanned rework which drains us of time, mind share, and productivity.

    Is the goal of zero defects appropriate universally, including Agile software development? That depends on our focus. If we were slow down to the point that we eliminated all chance of “releasing a defect,” we would be forcing a return to the dark days of waterfall project management and we’d still find a deficiency in the release!

    When we are striving for rapid release cycles that target the needs of our end users, rework and improvement (based on feedback from last sprint) are natural elements of the improvement cycle. That being said, we still want to emphasize the goal of quality along with the other principles of Lean IT including voice of the customer, systems thinking and flow.

Leave A Comment