I came back from LSSC’12 in Boston with a lot of perishable information that I need to write down in a blog post. I am not sure about one long post actually – lets do it in small batches.
In no particular order…
Michael Kennedy: Set-Based Decision Making – Taming System Complexity to Ensure Project Success
This was a great talk by the account of everyone who was there. I saw and liked Michael Kennedy’s 45-minute Lean Kanban Benelux 2011 talk on set-based decision making, so I expected this 90-minute session to be even better. The material is a must see for anyone who wants to ever use the word set-based. Set-based decision-making is way more than set-based design or pursuing multiple options guaranteeing that at least one will be successful.
Kennedy traced the history of set-based decision-making to the invention of the airplane by the Wright brothers. Many inventors before them failed. How did they fail? They spent thousands of hours designing and building their aircraft and about five seconds testing them and the test usually resulted in a crash. The Wright brothers’s work followed a different pattern: experiment and test, repeat until feasible, only then design, then build. They conducted hundreds of experiments and when they knew flight was feasible they were able to quickly design the aircraft that would take the historic flight.
Many successful companies followed a similar approach, particularly Toyota. Toyota product development system is completely different than the Toyota Production System! As David Anderson pointed out, this is real options theory in action. By testing and experimenting, they learn what is feasible and what is not and create options. The eventual design is pulled from this set of options. This is how Toyota was able to create Lexus, which went from non-existence to dominance in two years, and later repeat the same feat with Prius. If they started designing Prius up-front – we know what would have happened by looking at their competitors.
Set-based decision-making has important implications for the software world. Simon Bennett instantly saw relevance to Enterprise Architecture.
I also have a theory that some free products that we’ve seen recently that nobody seems to have any idea how they will eventually earn revenue – Google Earth? – they’re not products themselves, but may be just public mashups of feasible options to be pulled in the future to quickly design an entirely different product when that becomes necessary – that’s how they generate economic value for the company.
Troy Magennis: Effective Modeling and Simulating Kanban Projects Using Monte Carlo Techniques
Troy gave a demonstration of his software: how you can specify an existing process, load some data, run many simulations and get the probability curve showing possible outcomes of the project. By looking at the curve and, say, the 95th percentile, we could make good project estimates. This is very compelling, but wait – there’s more.
Here is a very important insight from this session. While a project can be “run” thousands of times in Monte Carlo simulations, it is run only once in the real world. It ends up not as a probability curve, but just one spot somewhere on that curve. By simulating the project repeatedly, playing with various inputs, and feeding information into the simulator as soon as it becomes available during the project, we can identify risks early on and have a chance to address them and rewrite the project’s history. So, the simulator becomes much more important than an estimation tool.
It is fascinating that someday Monte Carlo simulations may be run as part of Continuous Integration – Monte Carlo Jenkins plug-in anyone?
This session was a great manifestation of the scientific, inquisitive, experimental mindset of the Lean-Kanban community. It also sends a not-so-subtle message to all Scrumbut and “we-do-agile-here” teams out there, getting an uncertain value from planning poker: while you are at it, your competitors may be doing Monte Carlo!
I’m approaching the end of my timebox, so thanks for reading so far and wait for Batch 2!
Thanks Alexei – its rewarding to see that in a 40 minute session I was able to convey the important points. Very nice summary. Nice meeting you.
Pingback: LSSC’12 Post, Batch 2 | Learning Agile and Lean
Pingback: A Digression from My LSSC’12 Report | Learning Agile and Lean
Pingback: LSSC’12 Report, Batch 3 | Learning Agile and Lean
Pingback: LSSC’12 Report: The Lean Camp | Learning Agile and Lean
Pingback: LSSC’12 Report Wrap-up | Learning Agile and Lean
Pingback: The Best of 2012 | Learning Agile and Lean