Organisational Change with Mikado

Sandy Mamoli is a force of nature (in a good way) who hails from New Zealand.  She is a personal Kanban black-belt and is the creator of the very cool Kanban-for-1 board I use to keep my work load sane (or at least visualize when I’m being insane).  Sandy blogs at Nomad 8.  Here she is:

Organisational Change with Mikado

If you’re doing it right an Agile and Lean adoption requires organisational change. Organisational change is often difficult because of the many layers and dependencies and the sheer number of people involved.

At my current client organisational change involves upper and middle management, development teams, vendors, professional practice groups (e.g. testing, BAs etc), operations, security, the Project Management Office (PMO), Quality Assurance (QA), legal… and many more.

The Hydra

A goal like shortening the release process to improve the speed at which software features can be delivered to the end user for example involves the co-operation of several siloed departments, the buy-in of the vendor, several changes to the approval process and changes in funding and “resourcing” (yeah, I hate that word).

This is quite overwhelming as it is difficult to get an overview of what needs to be done and in which order things need to be done.

At my work this caused a lot of frustration as every time we wanted to change something we couldn’t do so without changing a lot of other, dependent things. It felt like the proverbial Hydra – every time we cut off one head two more would grow out of it.

The Mikado method

A situation with dependencies everywhere, where every time someone fixes a problem two new ones appear is quite common in large legacy software applications. In fact, it is so common that books have been written about it and methods have been developed to deal with the re-factoring of such systems.

One of the most successfully applied methods is Daniel Brolund and Ola Ellnestam’s Mikado method:

The Mikado Game

The Mikado method is named after the Mikado game where in order to get to the “Emperor”-stick players have to carefully remove all the sticks on top before they can pick up the emperor stick itself.

Large-scale refactoring with the Mikado dependency graph

Large-scale refactoring with the Mikado method is done roughly like this:

Mikado dependency map

The process:

1. Start out with your business goal
2. Try to implement it! – If it goes well, you’re done
3. If not, you have hit a dependency (most cases)
4. Add the dependency to the graph as a sub-goal
5. Make the sub-goal your next target
6. Try to implement the sub-goal – If it goes well, you’re done and you can now attack your first goal
7. If not add another sub-goal
8. … repeat until you reach a sub-goal with no dependencies ..
9. Now you can revisit the last sub-goal and continue

A software refactoring method to refactor organisations?

Meeting the Agical guys in Stockholm and reading Ola Ellnestam’s blog post about the Mikado method outside of software development made me wonder whether the Mikado method could be a valuable tool for systems that aren’t necessarily “made of code”.

After all, aren’t organisations systems too?

Jocke Ohlrogge, one of Agical’s founders and me in front of the Agical office’s Mikado graph Both software and organisational systems sometimes need re-factoring. Both are usually large and complex and both need to achieve big goals that require lots of dependent subgoals to be accomplished while needing to be kept running while the work is being performed

So what would happen if I treated organisational change as a large-scale system refactoring I wondered.

An experiment

I got together with one of my client’s managers who wanted to introduce Agile and Lean to her part of the organisation and we decided to try it out.

Three hours at a close-by cafe and we came out with an organisational dependency map.

This was our process:

1. We defined a high-level business goal: “Quick turnaround of change through having a really low cycle time”
2. We asked ourselves “Can we just reduce the cycle time?” The answer was “No”
3. So we asked “What’s stopping us?”
4. The answers were “A long hardening period before a release”, “Too many projects/changes in progress”, “A long discovery/analysis period”.
5. We identified them as dependencies and added them as sub-goals to our dependency graph.
6. We then looked at each of the sub-goals and asked ourselves if we could achieve them by working on them directly. For example we asked “Can we just shorten the hardening period?”
7. Again the answer was “No”.
8. “What’s stopping us?” we asked
9. The answers were “Acceptance testing is part of the hardening period”, “Our regression testing takes too long”, “We spend a long time rehearsing releases”

We repeated the process for each of the sub-goals. Sometimes we could identify end-points with no more dependencies which we could start working on. Other times we realised we needed to involve other people to identify additional sub-goals.

A dependency graph for organisational change

Ultimately we ended up with a dependency graph for organisational change that we could use as a high-level roadmap for our adoption.

It is now in a central place in the office so that everyone knows the plan and where we’re at.

We found that the Mikado graph added another dimension to our company-wide improvement backlog: It turned a flat hierarchy into a two dimensional map. The map literally serves as a map showing where we are now and where we want to go.

It put each backlog item and sub-goal into a larger context and made it easy to see which sub-goal a specific task supported. It helped us understand why we were working on certain sub-goals and what achieving them would enable us to do.

I also helped us choose what to do next and to prioritise our backlog to make sure we’d work on items in the right order and that we’d work in vertical slices that would provide value as early as possible.

The process itself of creating the dependency graph was very useful to disentangle what felt like an overwhelming task with lots of sub- and sub-sub tasks. We felt that the structured process helped us to apply an analytical mindset.

The format of a two-dimensional dependency graph proved to be very useful to share our plans and to communicate ideas to other people within the organisation. We have “walked many people through” our graph since and have shared the ownership with everyone who is involved in the change process. It is now a living, visual map of our Agile and Lean adoption that we constantly derive our plans from.

This blog post originally appeared as Organisational Change with Mikado in August 2012.  Thanks, Sandy, for contributing it to #WomeninAgile.