RallyDev.com
Thu 21 May 2009
Ferris Bueller and Kanban–Anyone? Anyone?
Kanban is great. I value that it seeks immediate fixing of problems, which is referred to as continuous improvement. I love that.
I value that teams are prepared to “Stop the line” and not allow process or defects to continue unscathed. I love that too.
I wonder what Ferris would say about "Fixes that Fail"
But for all that, I haven’t seen clear Kanban practices for long-term trending that would help us identify or capture those “Fixes that Fail” or “Unintended Consequences.”
I am concerned that the emphasis on immediate improvements may fail to capture what long-term negative impacts may be lurking. I worry about a “not seeing the forest for the trees” effect.
So what does my concern about Kanban have to do with Ferris Bueller?
It is admittedly an odd connection. Specifically, it refers to a classic line in the movie “Ferris Bueller’s Day Off.” Ben Stein, Ferris’s history teacher, asks the class, “Smoot-Hawley Tariff Act: raised or lowered tariffs– anyone? anyone?” trying to get at least one student to respond. Classic line from a classic movie, though most people believe that the line was about a fictitious act.
Fast forward a few decades. In a recent New York Times Sunday Business section, Stein wrote an article on economics entitled, “The Smoot-Hawley Act Is More Than a Laugh Line.”
Smoot-Hawley, unbeknownst to Ferris Bueller and most of us, in fact RAISED tariffs in an effort to protect the US economy from an influx of foreign goods during a challenging national economic downturn.
At the time, the “immediate fix” of the Smoot-Hawley Act seemed like a good one. Ultimately, however, the pundits of the time declared that it wasn’t enough to save the country from the economic ravage we now know as the Great Depression.
Today, economists are reconsidering the supposed low or non-correlation of the Smoot-Hawley Act and the Great Depression. Did that immediate fix actually have a lot more to do with the Great Depression than had been understood? Hmmm. Something to reflect on for future possible fixes. The debate is absolutely there. An immediate fix (like Kanban fixes or Smoot-Hawley fixes) may be one of the “Fixes that Fail” or have “Unintended Consequences” that can only be seen through a longer view lens.
The value of this long-term reflection, whether in Kanban or in economic fixes, on such a small fix can have far-reaching impacts on our overall systems.
As Stein points out in his article, economics is not physics. For my part, our analogous comparison is that software development is not manufacturing. We need to walk the walk of systems thinking by being ever vigilant to seeing the entire system, the whole. And that means acknowledging that we will absolutely have delayed feedback loops on our fixes. Longer term reflection and retrospectives can help us make more informed “immediate” fixes as we move through ever challenging world of software development and delivery.
When Smoot-Hawley came up for signature, economists, bankers, and others urged Hoover to veto it. Even at the time, many believed (rightfully) the consumer would be hurt and foreign markets for farmers would be shutdown.
I guess my take on Kanban is not the “quick fix” that yours is, and I don’t see it just relating to manufacturing as you imply.
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.
Wayne,
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
Yes, Chris. That is the point Ben Stein made in his NYT article: it was a fix that even at the time might have warranted more analysis. Oddly, as Stein points out, even with the doubts around the act, when the Depression did hit with its full force, most economists believed that Smoot-Hawley was inconsequential. That notion continued for quite some time….until recently.
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
Great thought that we must always look to see if there are un-intended consequences for things. That’s why Lean’s (the foundation of Kanban) “optimize the whole” is so important. Many things we do in the Agile world are a reaction to our more or less recent past. They are not necessarily long term solutions and therefore likely have unintended consequences. Kanban, applied to less than the full value stream may fall into this – but I suspect not when applied to the whole.
Alan, thanks for your comment. I have been stressing this a lot lately (as I know you do :- ). Go back to the Lean fundamentals and ensure you haven’t lost something or thrown something out inadvertently as you adopt Kanban. “Seeing the whole”, looking at the entire value stream map, and reflecting long term for unintended consequences and fixes that fail are practices I fear are getting lost when people say they are “doing Kanban”.
Kanban raises awareness of those problems. Continuous improvement doesn’t mean fixing problems as they happen — it means being aware of what causes problems, and going after the root cause. It’s like giving your company better reflexes, or keener senses: instead of a sloth-like “Hm, I do believe I started experiencing discomfort some time ago,” it’s “YEOUCH!” Those quick reactions translate into an effort to fix the problem before it starts.
There’s actually a great line from The Toyota Way about this:
That’s what Kanban is really all about. Here’s more on the Kanban discussion that lots of folks have been having lately.
I’m not as well versed in Lean as I’d like to be, but it has always mystified me that what is often a custom endeavor, software, be compared to the highly repeatable, same input, same process, same output world of manufacturing.
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.
Scott,
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