In the previous posts, I presented how to use the Mikado Method to large organization changes. Drawn from the programming world, this technique keeps a low transformation WIP. In theory, this should reduce risk and the time to see return on investment. Let’s see the pros and cons in more detail.
An experiment culture
A first interesting point is the “Try - Revert” attitude. No one is signing with his blood that the change will have to succeed ! It’s liberating for everyone to have to try its best instead of having to succeed at all costs. In fact, it’s an opportunity to show a “right to fail” mindset. (You can read more about the topic here). It’s a clear message that leaders are proponents of experiments.
💡 Transforming large organization with the Mikado Method shows a “right to fail” mindset.
The flip side of that, is that people might not like to try Scrum 7 times before adopting it definitely. Plus switching process every month will not be very productive. Here is what we can do about these problems.
As I read in Freedom, Inc. “It’s not that people don’t like to change, its that they don’t like to be changed !”. If a transformation teams manages all the change initiative top down, people will hate it. Hopefully, the mikado graph is a unique collaboration tool. Start by presenting the method and sharing a blank graph. Ask everyone to build it together. Then let the teams handle their own part of the graph. Here is an example. Suppose a team needs to be able to integrate every hour. Add this goal to the mikado, and hand the responsibility to get there to this team. As Daniel Pink said, autonomy and mastery are key motivators.
We should also pay special attention to how we name mikado (sub) goals. If the general goal is to adopt LeSS, jumping in and out of LeSS will be very painful ! Instead of “How” goals, we should use specific “What” goals. For example, we could replace “Adopting LeSS” with “All teams integrate in less than 10 minutes”. It is a lot easier (and faster) to try to integrate in 10 minutes for a day. In one day, we should know if it works, and if not, what’s blocking. In this case, experiments will be standard improvement items in the backlogs of teams. Teams could try to integrate every 10 minutes by hand for example !
In fact, it lets people work on smaller changes, one at a time. I can think of two direct advantages of small changes. First, it does not disrupt the rest of the organization, letting it deliver as it used to. Second, it’s a lot less stressful for the people, who then have more energy to focus on the experiment.
Another point is that less things are being changed at the same time. After reverting previous attempts, less parts of the organization are being changed. There’ll be no teams halfway in the change waiting for fixes to their impediments. As usual, reducing WIP brings many advantages :
- It requires less coaches, as they will only concentrate on areas where they can drive the change to its end.
- It removes the synchronization overhead of different teams working on the same problem.
What about speed ?
I can hear you think “But that’s going to take forever !” It is quite the opposite. Here is why :
- The first completed changes will be root problems. Focusing on these will bring general improvement to all the organization. The state of the rest of the organization does not matter. The path you used to discover this root problem does not matter either. Fixing this root problem is likely to bring improvement to all the teams !
- As the graph unravels, we can use it to start independent change initiatives in parallel ! This is a classic way to speed up code refactoring that transposes to organizations. The graph gives you a clear map of which problems are independent. Perform changes that won’t conflict in parallel.
- There are quick wins also. You don’t need to be dogmatic about reverting. Suppose you tried something that brought improvement, but that uncovers a deeper problem. If the people felt an improvement and prefer to continue the new way, let them !
💡 Transforming large organization with the Mikado Method helps to parallelize work.
Granted, if the goal is just to move to “Agile”, then it might be slower than switching all teams to “Agile method X”. This is only faster on paper though. If you want more details about why becoming agile takes time, I encourage you to read these other blog posts. Plus, as I said above we should prefer “What” goals.
One final advantage I see with this technique is that it’s sustainable. As it’s a lot less stressful than a typical large re-org, it is possible to keep it going all the time ! It’s a gateway to continuous improvement. It’s no wonder Toyota (see Toyota Kata) people say that the improvement kata is their main management tool !
It’s funny how two practices like the Mikado Method and the Improvement Kata are the same idea ! I also noticed similarities with thefirst “Be Proactive” practice of Stephen R. Covey’s 7 habits of highly effective people. Could it be the same idea again ?