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
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
- 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.