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. 

Hydra

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

MikadoGame1
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: 

 

MikadoGraph
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?

JockeAndI

 

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.  

MakingTheGraph

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. 

 

GraphCloseUp

 

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.

 

OrganisationMap

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.

Sandy Mamoli – who has written posts on Nomad8.


6 Comments

Sivaram AthmakuriNovember 5, 2012 5:18 pm

Great Post.

estherderbyMarch 23, 2013 1:53 am

I use what I call “Horizon Mapping” for organizational change. From what you’ve said here, it sounds sort of similar to what you are doing. Would be fun to chat about it some time.

Sandy Mamoli March 24 2013 13:48 pm

I'd love to! Hopefully we can do that at Agile 2013 in Nashville.

Philippe TremblayMay 22, 2013 5:18 am

It reminds me a lot of a Cause effect diagram. Instead of asking “Why”, you ask for “How”.

Great suggestion.
It is a new angle with great visibility and simplicity.

Thanks

Paul BoosJune 26, 2014 10:19 pm

The only thing that is NOT like the Mikado method from what I read above is you didn’t try and really implement the big goal or major subgoals (and of course revert). Unfortunately, I doubt humans would respond so well on the reversion and this would lead to unneeded skepticism when getting back to the bigger changes (even if you had already changed the pre-requisities).

It really appears you are using this as a thinking mechanism to find the leaves so you can make changes safely; solving the pre-requisities first. I love this as a thinking method, but I just question using the term “Mikado” in the name since you aren’t following that method per se.

None-the-less, excellent approach…

Sandy Mamoli June 27 2014 11:18 am

Yes, I couldn't take all the principles for exactly the reasons you mention but I was happy to be able to take some.

The Mikado method inspired me and helped me create a mental model for change that seems to resonate with people and helps understanding and conversations.

Thanks for your comment, Paul. I agree with you.

Leave A Comment

Posting your comment...

Subscribe to these comment via email

http://nomad8.com/wp-content/themes/selecta