Sunday, April 25, 2010

My Take Away from the Lean Software & Systems Conference 2010

Above All, Stay Open to New Ideas, Humble to the Current Limits of Our Knowledge, and Be Ready to Innovate, Absorbing Ideas from Other Bodies of Knowledge

I expected that when I went to lssc10 I would learn some interesting case studies, how tos, and general advice on how to implement various aspects of lean within the software delivery domain. Instead my primary take away, (and I think something that resonated with the entire conference) was a call to arms to move beyond the traditional lean metaphor and concepts taken from manufacturing, and to start opening our minds to other domains, other bodies of knowledge and other areas of expertise. Clearly leaders within the LSSC feel that we all have many more questions than answers, and that a open-minded, humble attitude is required to continue growing as community of practice and knowledge. A common feeling among everybody I met at the LSSC was that "our" brand of lean really represents an open ended philosophy, one that emphasizes intrinsic motivation, dedicated to building a measured but learning systems. You could almost see the thirst for new, provable knowledge among the attendees at the conference. I saw very little patience for dogma be it agile, lean, or otherwise, and was told by a couple to open my mind up a bit (thx siraju).

Many of the Ideas from Lean Are Toxic to Our Practice

danger 5

I think the keynote presentation on the 1st day says it all. Don Reinerstein started off by saying that lean is just the next peak of the mountain that we can see, and beyond that mountain lies something else. This point (IMHO) is that it was time to stop looking at lean as a source for all of our ideas and ways that we can improve our practice. According to Don, we are leaving a lot of great thinking on the table by being overreliant on the lean metaphor. He then went and listed all the kinds of lean principles that were actually toxic to a learning system.

  • Eliminating Variability- variability is essential to product development, you are always dealing with something new, if you have no variability you actually have no value
  • Eliminating Waste - an over focus on eliminating waste misses the point, idle time is one of the key areas that are of concern
  • 0 Failure-failure is actually a good thing in learning systems, as this is one the most information is generated, so we actually want ways of generating an appropriate ratio of failure to success, if we have too much of either the system is not generating enough information to properly learn
  • 100% Defect Prevention - preventing defects has a cost, we need to weigh that cost with defect fixing
  • Complete Customer value focus - the customer is not always the sole or return value, there are plenty of case studies where businesses have gone under because they provided more and more features to high-end customers, and ignored innovations. (In fact this is the key point of the innovators dilemma)
  • One Piece Flow - one piece flow doesn’t make sense for human systems passing information round, we need to balance transaction with holding costs

The Internet As a Metaphor for Human, Learning, Product Development Systems


What really caused the crowd to get excited, was when Don urged the crowd to consider another metaphor for distributed services/learning-based systems, the Internet. The Internet is a system that is of extremely high quality, deals with variability, and can scale quickly without problem. Don went to then describe how different aspects of the Internet could be used to model the next generation of knowledge work management systems

  • dynamic routing of work in progress based on congestion in the network, routing conditions are updated sometimes many times an hour
  • work in progress constraints are determined just-in-time, based on load, as capacity changes the system probes the network and adjusts; dropping packets and lowering wip as necessary
  • small batch sizes are used to raise speed, efficiency and quality, but some batching is also required
  • there is a balance between deciding the optimal route (upfront quality) and allowing the system to reject and resend failed packets (think test after)
  • throughput is managed by doing rate matching with the sender and receiver
  • resources are bound to problems at the last responsible moment

You could practically feel the electricity in the room as Don describe how a human network could emulate the Internet to predict a failure condition originating from too much work being introduced in the system, in response the system would immediately reduce allowable intake, in order to ensure maximum flow. I don’t think I was the only one in the room who’ s internal gear started shifting on how to actually design and run such a system. One algorithm Don suggested was to raise the acceptance criteria of any new projects within an enterprise portfolio as the enterprise portfolio got more and more full.

After getting everyone excited, Don then proceeded to pour water on the whole metaphor, the problem he stated, was with fungibility, i.e. in a human system resources are very tightly coupled to the kinds of work they are doing. In the Internet any node is equally capable of bearing work. For a human system, adding value to information requires very specific skills, a .net developer is not to be able to do much with an SAP problem.

Don encouraged all attendees at the lssc10 to start looking at other bodies of knowledge for the next generation of ideas that would inspire and take this community to the next level. These included:

  • queuing theory
  • os design
  • economics
  • traffic flow theor
  • maneuver warfare

Stop Drinking the Kool-Aid

Don’s finally urged all attendees to stop drinking the lean cool aid, and continue to look at multiple domains for synergies, patterns and practices that can help to dance the state of our practice.

While there are many other extremely powerful examples of this philosophy that was demonstrated throughout the conference, (I will talk about some of the other great aha moments in later posts) I certainly want to thank Don for perhaps one of the most inspiring professionally related presentations that I have attended. The more I get involved in the lean community, the less I feel that I know, and the more excited I get about increasing my understanding.


  1. This is one awesome post my friend.

  2. Thanks for the great comments. You are providing a jog to our collective memory. I couldn't have remembered it all so well. I am very happy I chose Don as one of key note speakers. He clearly had a significant impact nudging the community in the direction I hope to see it follow.

  3. Hey Jeff

    I think the opening lines say it all:

    "Above All, Stay Open to New Ideas, Humble to the Current Limits of Our Knowledge, and Be Ready to Innovate, Absorbing Ideas from Other Bodies of Knowledge"

    Thank you very much for being so participative in all formal and informal sessions.

    Tweet, Blog and present more!!


  4. Very nice comments and recap. I have to agree, the more I learn in this community the more I realize how little I know.

    You gained a subscriber today.

  5. I didn't get to make the conference, but I am so glad I read your recap. Thanks for sharing!

  6. "an open ended philosophy...that emphasizes intrinsic motivation...thirst for new, provable knowledge...very little patience for dogma be it agile, lean, or otherwise".

    If these things stood out from the conference for everyone, then we were successful at the most-important objective possible. Culture is much more difficult to create than good methods, and much more leveraged. With this mindset we will see all sorts of technical progress, very quickly. May we always resist the easy and common path of being method advocates!

  7. Thanks for the very generous review of my keynote. My remark out fungibility was not meant to "pour water on the whole metaphor." While packets may be fungible on the Internet, the links actually are not. The difference between the productivity of an SAP developer and a .net developer can be viewed as different path lengths for the same task. This "link cost" for a developer depends on both their efficiency and their queue. When experts are overloaded their path length rises, despite their higher productivity. We may choose to route work to a less efficient resource when it has a smaller queue. I was actually only trying to illustrate the need to enrich the Internet metaphor with ideas from other domains. In particular, we have very advanced ideas for dealing with non-fungible, unpredictable, non-homogeneous work in the domain of computer OS design. I don't believe any domain has a monopoly on great ideas.

  8. Thx everyone for reading and commenting, and yes Don your point is well taken, their are a lot of good sources of ideas out there, we need to keep our minds open.