Lets try to summarize real quick what we came up with in a short lean coffee session about this today in LSSC12.
Lean Startup for Change is applying the concepts of Lean Startup to Change programs. It comes real handy when you have a complex environment where you don’t know exactly what will work for the organization context (market) and you want to test it rigorously until you come up with an approach that can stick/grow effectively in a way that creates a sustainable change program.
The flow can look something like this:
- You identify a problem/dissatisfaction at the capabilities level of the organization. This can be – we are not able to meet demand, we need to scale without increasing overheads, we need to improve quality, etc.
- You create a change model (maybe using a kind of canvas – riffing on Business model canvas or Lean canvas or closer to A3 who knows – we need to find out what works best…).
- You identify risky assumptions/hypothesis in this model and design experiments to test. The risks can be value risks – whether we actually know for sure that the change we are introducing will bring value ASSUMING it happens. Or growth risks – We know it will work but we don’t know IF it will happen/stick/grow. This is similar to the value/growth hypothesis and metrics in Lean Startup.
- Some times Value hypothesis will be hard to test if there isn’t enough information/history about the system, and therefore a growth engine that brings the system to a level where it generates enough information (e.g. by having enough teams use kanban to manage their work) might be the first priority, as a MEANS to establish the Value experiment.
- With the hypothesis you start with, design the Minimum Viable Change that will test your assumption about how things will work. If you are aiming at growth, your MVC needs to focus on how you will grow the system and measure things like virality of teams infecting each other (virality), how many teams infected actually get interested about this (conversion?), start using it (activation), and keep using (retention) and infecting others. You run this MVC and see what are the results by measuring them (How? separate and VERY though question – but it comes down to looking at behaviour in some way. need to do it in a reasonable and humane way though – e.g. how many teams contacted the local coach about a practice they saw elsewhere without being forced to start). You then start to tune the engine. Play with things that might affect growth e.g. the way you train, the way you coach, the way you present things, who’s in charge, etc. When you see you have a working growth engine you can stop experimenting and pursue the winning approach you found. If you see your experiments are not really getting anywhere you consider pivoting to another kind of growth engine altogether, or even to another kind of change engine.
- When your growth engine worked well and you have a good population of people using the system you can start looking at the value hypothesis. You have enough of a sandbox to test your assumptions on what will bring value. You design MVCs that are aimed at bringing in value like improved quality, faster cycles, improved customer satisfaction, etc. You execute an MVC and then measure its effect. There is a challenge here because some of these will take time to see the results of (e.g. Refactoring?). Work real hard to defining the MINIMUM viable change. All these MVCs are not a test whether the “change approach” is possible, just whether it is a good fit for the organization’s context (so basically not solution-space uncertainty but problem-space uncertainty – the natural habitat of MVPs…)
- After tuning the MVC until you see you are meeting your value hypothesis and have a strong change engine you can pursue it by deploying it elsewhere, and move on to testing new hypothesis that can improve performance further.
- I’m feeling quite comfortable thinking about this in an A3 for each MVC kind of form. Maybe need to take some things from the Lean Canvas into this A3, but most of the stuff is already IMO.
- Bottom line you tested uncertainty at the problem space – whether we are indeed solving the right problem for the organization, as well as the growth space – are we running the change in the most effective way.
One comment from the discussion was that several of us Lean/Kanban practitioners feel that we don’t really have to validate the assumption that Kanban will provide value to the organization. We are quite sure that it can serve as the diagnostic that will stimulate improvement. What we are not sure about is how to best take on Kanban in an organization. And that is why the growth engine/hypothesis is so important and why it might seem that we are focusing on mechanical implementation rather than a value driven one. We see Kanban as one way to enable the Value-seeking MVC via its fast method of installing a system which will visualize what is going on and invite potentially value-improving experiments.
Just initial thoughts from a very long day at LSSC12. We are keeping the discussion alive with hashtag #LC4Chg on twitter as well as on kanbandev. Join us and let us know what you think about this.