Reducing the risks of large organization changes with the Mikado Method - part 2

In the previous post, I presented both large scale code and organization changes. I highlighted how they face similar difficulties of huge Work In Progress. Let’s see how programmers deal with these problems.

The mikado method algorithm

The mikado method is a programming technique to perform large code refactoring one step at a time. It fixes the problematic situation we raised at the beginning of these posts. It enables developers to integrate their work with their teammates’ continuously. It allows to build features and do the refactoring in parallel. Developers can also pause a mikado refactoring for a while if needed. On top of all this, it makes it easier for the full team to collaborate on the same refactoring.

💡 Developers can pause a Mikado Method refactoring for a while if needed.

Here is how it goes, but you can get a more detailed (and technical) description here.

1. Try to do the change you want
2. If it the tests pass, great, you’re done
3. Otherwise, add a node for the change you wanted to do in your mikado graph
4. Write down the errors you faced
5. Revert your change
6. Recurse from 1 for every error
7. Draw a dependency arrow from the nodes of errors to the node of your initial change

The catch is that developers should revert the work they could not finish to move on !

How to apply it to an organization change

In some way, the Mikado Method is very similar to the improvement kata. The flow of the Improvement kata goes on like that :

1. Determine a target condition
2. Try to work with the target condition in place
3. If it works, you’re done
4. Otherwise, understand the main impediment, and revert to the old way of doing things
5. Work to remove the impediment
6. Start again from step 2

Have a look at these blog posts for a more practical presentation of the improvement kata.

💡 The Mikado Method and the Improvement Kata are more than similar.

Granted, the Mikado method and the improvement kata look similar. They are in fact more than similar. The improvement kata does not prescribe how you should fix your impediments. What’s not explicit is that we can use it recursively to fix impediments ! That makes it almost identical to the Mikado Method, but for organization instead of code. It won’t be a surprise to know that some companies have used the improvement kata for that. For example, HP used it to drive its Laser Jet team transformation. Others have already used the Mikado Method for organization transformation.

Original Post by Sandy Mamoli

Suppose your organization wants to move to full Continuous Integration. It could start by trying to integrate all their devs in 10 minutes on a small group of teams. If it works, fine, other large teams can try it as well. Let’s see what to do if it fails though. Thanks to a retrospective teams understand that they need to master CI themselves first. In this case, they could revert large scale CI, and have one of the teams try to do continuous integration. If it works, fine, another team can try it too. If it does not, they’ll do a post-mortem of some sort to understand the root issue, and work on it. For example, here the main impediment could be a coupled architecture. The fun thing would be to apply the Mikado Method to do this refactoring 😉.

As with the Mikado Method, it is possible to draw an organization change Mikado graph along the way :

The graph is a living artifact. As we try and revert new experiments, we should expand and collapse the graph. This creates a global and shared view of the state of the change. Needless to say that this is great for collaboration.

To be continued (again)

This was part 2 of a series on applying the Mikado Method to organization changes. I’ll end this series up with next post, where I’ll go through the pros and cons of the approach.

Stay up to date with content and upcoming products

I usually write about 15 minutes worth of reading per month. I won't transfer your email. No Spam, unsubscribe whenever you want.

As a gift for subscribing, you'll receive an illustrated mini-ebook "How to start a team coding dojo"!