A common question Daniel and I get when we talk about the Mikado Method is — ‘Can it [the Method] be used outside of the programming domain?’. The answer is yes, but there are a few things you need to consider.
The real world vs. code
One major difference we stress is that the real world lacks an ‘undo’, or a ‘restore to a previously working state’ — that slows us down. Once you’re past the undo-hurdle, a real world Mikado-approach is more or less the same as a code change.
I find it useful to test the waters with these questions before I start:
- What am I trying to achieve
- What are my means of getting feedback
- How fast and accurate is that feedback
-
How safe is my [working/experiment] environment
Start with the end in mind
Even the longest journey starts with a small step and this old proverb fits nicely with the Mikado Method. Tiny changes, performed one after another which finally leads you to the goal you had in mind. But before you embark on your journey a goal is needed, and this is where the Mikado-approach differs and might feel a bit awkward at first.
Instead of trying to figure out your first step you start by defining the goal. After that you work backwards and try to see what stops you from reaching that goal. In a code base you’d just try to do the change you want and see if and where it fails. In real life you have to rely on small experiments, and sometimes imagination or analysis in order to see what’s in your way.
Defining the goal
Finding an appropriate goal can can be tricky, because real world goals tend to be elusive and abstract. This can partly be avoided by asking yourself ‘What do I want to achieve’ followed by three or four ‘Why?’.
It’s time for small an example, so imagine the following conversation at work.
– I want to do Kanban!
– Ok, why?
– Our process for creating software is broken and I want to change it!
– Oh, really … why do you feel that way?
– Because, there is too much waste involved?
– What kind of waste?
– It has too much ceremony
– Really, what ceremony is not needed?
– Well, we’re only a 4 person team so I find our two week code freeze ridiculous
– Why do you want to get rid of the code freezes, it gives us time to fix problems?
– Yeah, but what if we could release at any given time and be certain about the quality?
Valuable Goals
We usually start out with a specific solution to a very real problem. Sometimes that solution is the correct one, but more often they need to be re-evaluated. In our example a more concrete goal emerged during the conversation, ‘being able to release at any time’, which is the valuable stuff.
You know that you have reached a ‘real goal’ when the answer is close to ‘valuable to someone’. Unfortunately this is quite hazy and includes a wide range of possible outcomes.
Other valid goals are, ‘I can do task X faster, which makes me happier’ or ‘The cost of making these units is reduced by 25%’. The reason it is better to refer to the goal as an ‘idealized future’ or an ‘ideal outcome’ is because sometimes you just can’t reach that ideal and need to settle for something less. At least for now.
The option of ‘settle for less’ is possible in code Mikados too, and because you add value incrementally time never feels wasted in the improvement work.
Building the graph
fig. 2
When the goal has been decided upon it’s time to pull out a piece of paper and jot down your idealized future and see what’s stopping you from reaching your ideal. In short, this means finding all prerequisite tasks.
A prerequisite is something that stops you from reaching your immediate goal and sometimes prerequisites has prerequisites themselves. All these prerequisites should be drawn on your piece of paper and appropriately connected. This results in a dependency graph. See (fig 2).
The crucial question is Why don’t I just do this? This is also the question you keep asking yourself over and over and then write down the answers in the form of a task or an immediate solution in your Mikado graph. Sometimes the solution isn’t obvious and in those cases you need to try something and hope it solves the problem or reveals more information. If it works you move on, if it doesn’t you probably have more input and can add a prerequisite to the graph.
Start at the leaves
Sooner or later the time comes where the tasks can actually be completed or you can’t come up with more prerequisites. At this point there is a at least one leaf in your graph. This becomes the natural starting point on your journey towards the idealized future.
After the first leaf has been taken care of, another node becomes a leaf and you can continue the work there. By systematically attacking the leaves you work yourself backwards to your goal and prune your dependency graph one leaf at a time.
In the real world, the nodes in the graph tend to have somewhat complex solutions as they often include interactions between people. They might need to give you permission, be informed or included in the solution.
Human interaction is a lot harder than structural change in a code base which can often be automated. But more importantly, code changes can be reverted if something doesn’t go according to plan. Remember?
Few things in real life can be reverted easily and those who can take a lot more effort than a simple Ctrl-Z.
A powerful TODO list
The goal-driven aspect that the Mikado Method offers makes it ideal to use as a powerful TODO-list. This combined with the semi-naive strategy that can be used to explore the graph means that there is rarely any unnecessary stuff on the ‘list’.
I also find the idea of putting important things I need to do in a graph compelling because they are easier to reason about. I immediately see what’s next and why that is next, I can also add things as a prerequisite when something is missing. As a positive side effect, the size of the graph tells me how complex the change is which also is useful when I need to inform others or manage their expectations.
The next time you need to plan something that doesn’t quite fit in your head, give the Mikado Method a spin and see if it works for you. If you try it, please tell me how it went.
