Michael Kennedy’s books on new product development with Lean are also two great sources for paying attention to lessons about development not manufacturing.

My point in this article is about long-term reflection on fixes that may fail. This can be applied in any systems context. Product development is one.

Thanks for your comment. Jean

In a similar discussion I was advised to read (yet to have read)the book, “The Toyota Product Development System: Integrating People, Process And Technology” by James M. Morgan and Jeffrey K. Liker (Hardcover – Mar 25, 2006)

TPDS is about engineering and design, the product development lifecycle, not the manufacturing lifecycle. From a 50,000 foot view, this would seem like the place to start, not TPS.

Thank you for your comment. My viewpoints come from how I have heard others talk about Kanban adoptions. Look at Alan Shalloway’s comment to see where he comes from on this as well. All of your points are well taken and solid. I just don’t tend to hear others express this same robustness around Kanban. Now I will challenge you slightly. I don’t see you emphasize long-term reflection for “Seeing the whole.” What practices would you say that you do that support this “long term” reflection as one of the tools for continuous improvement? I would suggest that this is all the more important when you are scaling Kanban practices across an organization. Could you tell us more about your reflection processes in this scale? Thanks, Jean

There’s actually a great line from The Toyota Way about this:

TPS experts get very impatient and even irritated when they hear people rave and focus on kanban as if it is the Toyota Production System. Kanban is a fascinating concept and it is fun to watch… When is the kanban triggered? How are the quantities calculated? What do you do if a kanban gets lost? But that is not the point… The challenge is to develop a learning organization that will find ways to reduce the number of and thereby reduce and finally eliminate the inventory buffer… So kanban is something you strive to get rid of, not to be proud of.

That’s what Kanban is really all about. Here’s more on the Kanban discussion that lots of folks have been having lately.

That is my point WRT Kanban. I believe that long term views over potential “fixes that failed” or “unintended consequences” are vital to the success of a Lean adoption. Day-to-day inspections may only lead to strings of fixes that fail. That means a string of re-learning and that is waste. Longer term trending that takes into account delayed feedback is key.

Thanks for you comment. Jean

I believe Kanban can tie in nicely with any service-oriented culture. I think by focusing on reducing the lag between the request and the delivery you positively impact the feedback loop and increase customer confidence in what you’re doing. I also like the prioritization back to goals/epics and scenarios down to stories.

I also think that Kanban scales nicely for bigger organizations. Even though you can still have teams and XP programming practices, you can also introduce specialized queues like QA and watch the individual queues for bottlenecks or the risk of drawing certain queues down too low causing under-utilization.

I actually went through an experience where we were getting buried by our backlog several months ago, and had to freeze the growth of the queue. You could still add higher priorities, but only on canceling the bottom-feeders. I think it really gave our whole IT organization a real boost.