I recently wrote about finding the Minimum Viable Change and have been thinking about it some more, especially while working on my presentation for upcoming Scrum Gathering Atlanta and Lean Systems and Software Conference in Boston.
While trying to think what I’m going to say about Minimum Viable Change (MVC) I began to think about how to map the MVC to Minimum Viable Product, finding Product Market Fit and the Customer Development Process.
In my mind so far, as well as in how I understand the work of Jeff Anderson and his team on this subject, the MVC is aimed at learning what approach works best in your context and doing experiments to adapt the approach. This is similar to using MVP to find Product Market Fit with your core Product capabilities as the base you pivot around. For MVC the core capability you pivot around seems to be the Hypothesis that the direction/vision you have for the organization is indeed a good fit for what the organization needs.
As I understand it, Customer Development in the Product context is about finding a customer segment for which your MVP is a good fit. In the Change context Customer Development can be about finding the customer segment for which your MVC is a good fit, but this is more similar to classic Lean Startup. When we are talking MVC we are talking about searching for the right kinds of change WITHIN a change initiative you are already running. So what is the Customer Development process? Is it searching for groups within the organization for which the MVC is good enough so they can use it to change and you can learn about the change approach together with them? Is it something that tries to verify that indeed the organization WILL benefit from this change program, rather than taking it for granted?
There is lots of value in seeking the right change approach using tactical MVCs. I think there might be at least as much value if not more in seeking fast learning on whether the change is the right one using strategic MVCs.
Come to think of it, in one of my current clients we’re using two strategic MVCs:
- Hunch1: Small Batches are a good idea to deal with planning waste and effectiveness as well as bang for the buck product value for investment. We are testing that hunch using an experiment involving work on Product Backlogs / MMFs / Stories in 2 product streams.
- Hunch2: Cross-Functional work is a good idea to deal with synchronization overheads and waste involving half-developed features sitting on the shelf. We are testing that hunch using an experiment involving what we call “Discovery Kanban”. This is minimum because it is not a real Feature Team. But it provides enough learning to validate the value of Cross-Functional work. It doesn’t validate any hunches about Self-Organized teams though…
Any feedback welcome, and if you want to discuss in person, find me in Atlanta or Boston during the conferences, or check out a Kanban/Scrumban training we are opening in Atlanta just after the Scrum Gathering.
