Joining me for podcast #191 is my friend and fellow LEI faculty member Mike Orzen (@MikeOrzen), co-author of the Shingo Award-winning book Lean IT: Enabling and Sustaining Your Lean Transformation. I recently crossed paths with Mike in Columbus, Ohio, because we're both mentoring students in the Ohio State University MBOE program. We have a lot in common, it seems!
Mike is also collaborating with the ThedaCare Center for Healthcare Value for a new workshop: “Leveraging Information, People & Systems in Healthcare,” to be held in Phoenix on January 28 and 29.
In this episode, we talk about topics including an overview of “Lean IT,” how Lean is different compared to manufacturing and other service settings, how healthcare organizations can benefit from Lean IT, and the potential for kaizen and continuous improvement in IT.
For a link to this episode, refer people to www.leanblog.org/191.
Mike and I wrote an article in 2011 on using Lean to meet the IHI “Triple Aim” goals in healthcare (PDF link).
Here is an LEI video of Mike talking about the use of Lean IT to improve patient care:
For earlier episodes of my podcast, visit the main Podcast page, which includes information on how to subscribe via RSS or via Apple Podcasts.
Podcasts Sponsored by KaiNexus
If you have feedback on the podcast, or any questions for me or my guests, you can email me at leanpodcast@gmail.com or you can call and leave a voicemail by calling the “Lean Line” at (817) 993-0630. Please give your location and your first name. Any comments (email or voicemail) might be used in follow ups to the podcast.
What do you think? Please scroll down (or click) to post a comment. Or please share the post with your thoughts on LinkedIn – and follow me or connect with me there.
Did you like this post? Make sure you don't miss a post or podcast — Subscribe to get notified about posts via email daily or weekly.
Check out my latest book, The Mistakes That Make Us: Cultivating a Culture of Learning and Innovation:
Hi Mark,
After reading Mary and Tom Poppendeicks outstanding books on Lean Software development I was really looking forward to hearing Mike’s views on Lean IT.
I found that I agree with a lot of what he said in the second half of the talk about systems thinking and leading with process not technology but I was very disappointed with the first half of the talk. I feel that it describes traditional IT 20 years ago without taking account of the Agile revolution that has been sweeping over IT for the last 10 years.
Let me be specific:
Mike says that the purpose of IT is to deliver information. That’s an old fashioned view. Modern IT people believe that the purpose of IT is to satisfy the customer through early and continuous delivery of valuable software. See http://www.agilemanifesto.org/principles.html
Mike says the concept of flow does not translate well to IT. This is not the case. The concept of flow is widely and deeply discussed in the Agile IT community.
The concept of standardized work does apply to IT but not in the way people think. IT workers are like lean consultants. They research and develop detailed systems that automate standard work. But the process of creating these systems is highly variable and creative problem solving that suffers badly when people attempt to standardize it.
Mike says Lean does not have traction in the IT community. This is not correct. The outstanding work of Mary and Tom Poppendeick means that lean is getting a lot of traction in the Agile IT community. There are, for example, several lean agile IT conferences such as http://www.netobjectives.com/events/lean-agile-conference-2012-10-seattle, http://leanagiledc.com/ and http://agilebench.com/blog/lean-agile-systems-thinking-conference .
Mike says the concept of waste does not translate well to IT. This is not so. Waste and approaches to minimize it are widely discussed and used in the Agile IT community. Agile IT people recognize that documenting all the system requirements and design up front for a system (working in big batches) creates a lot of work in progress (inventory waste) that does not deliver value. They recognize that handing over work from one group to another (transportation waste) is a major source of delay and rework. They recognize that waterfall IT practices (big batches) cause death marches that burn people out (motion waste). They recognize that work waiting in queues (waiting waste) reduces ROI and causes rework. They recognize that big design up front (large batches) leads to production of a large number of system features that are not used (over processing and over production waste). And they recognize that defects cause a lot of delay and rework.
Mike says that IT people are not systems thinkers because they are deep down in the detail. This is may be true of IT people in very technical roles but it is not true of IT Business Analysts and UX designers. These IT people frequently think about how IT systems can solve organization problems. In fact your best and in many cases only systems thinkers are in your IT Business Analysis team.
Mike says that Agile teams neglect IT operations and does not consider the lifecycle from concept to solution. This is not so. Agile IT is strongly opposed to tossing work over the wall from one group to another. Agile IT recommends building cross functional teams that own software applications through their whole lifecycle from concept to support. And many IT operation teams use Agile and Kanban very effectively. DevOp’s which Mike praises is in fact an Agile practice.
It is misleading to think of IT as being like a factory with product design teams that toss a product over to manufacturing. If we use the factory analogy then Software development teams design the product, build the assembly line, install it, test it and support it before giving it to IT operations.
When managers and consultants think of IT as being a factory producing commodities they centralize, standardize and offshore the work to reduce costs. The result is always disastrous as local optimization leads to huge increases in the time and cost to customers of the end to end business process. This is because IT work is highly variable and creative problem solving that contains a lot of moving parts that must come together.
If you’re interested in applying Lean to IT I recommend you read .
Thank you very much for the feedback. The fact that your perceptions of Lean IT do not match with mine is a good thing and highlights some important differences in understanding. Instead of disappointment, I would hope you consider this an opportunity to consider other alternatives and what I believe is a complementary viewpoint. This is how learning takes place!
I appreciate your comments and see this as a great opportunity to clear up some all-too-common misperceptions of Lean and IT in the community. I have spoken with the Poppendeicks on this topic. In my opinion, Agile is NOT the entire story on Lean IT (only a component), so please keep an open mind when I share the following:
Your comment, “Mike says that the purpose of IT is to deliver information. That’s an old fashioned view. Modern IT people believe that the purpose of IT is to satisfy the customer through early and continuous delivery of valuable software.”
I suggest a broader definition is needed here: The purpose of IT is to deliver value to enable the creation of customer value. If I did not make this clear, let me do so now. If this is old fashioned, then so is every real and tangible principle of true Lean thinking and enterprise excellence. The Agile manifesto is written from the singular perspective of software development. Please do not equate Lean IT to Agile – it is so mush more than that. Lean IT covers the entire lifecycle of information and technology – including need-to-delivery as well as concept-to-launch as well as maintain-to-enhance as well as maintain-to-retire. Lean IT is about enabling every action in the value stream required to deliver a product or service through the delivery if information and technical functionality.
Early and continuous delivery of functional software is wonderful, but without a value-stream focus on the entire organization, it creates improvement that the customer cannot and does not experience! When Build is optimized but Run (and the business’s flow of work) is not synchronized, all you have accomplished is the creation of bottlenecks that cause more uneven flow of work downstream. This is often the fallout in from Agile-centric implementations. Perhaps the most overlooked piece in Agile is muri – the overburden (in downstream areas) that can be caused by local improvements exclusively on the Dev side, and muri, the variance it causes to downstream departments.
I thank you for your comments. I will try to respond to your other comments as time permits. Let me leave you with this one request, please stand back away from software development and Agile and ask, “Where is value realized?” I suggest it is not at any intermediate step of the vale stream. Rather, it is at the point of delivery to the customer. Working, supported, maintained functionality extends far beyond the Dev group or the Agile Manifesto. It is a great piece of work, but we need to zoom out a bit to a level where the customer can realize stable, reliable, trusted information that enables work along the entire value stream.
Best Regards,
Mike