Mikado Method: Primer

Basics

We use the Mikado Method to systematically break down large tasks into small chunks of work while build up a graph of dependent steps to keep ourselves organized and limit cognitive load. We spend time bouncing between two phases: exploration and commitment.

Exploration

The exploration phase starts with a leaf node on the graph, which may be the root goal. We then

  1. experiment: implement a node using a naive change, which may break something;

  2. visualize: jot down the solutions to all discovered issues as new dependent nodes;

  3. undo: reset your working tree to a completely clean state; and

  4. repeat: select another node, probably a leaf, and experiment from there

Sometimes, an experiment will just work - no issues! In that case, we bounce to the next phase: commitment.

The undo step is rather difficult to get used to at first, just stick with it at first to get used to the small changes and feel great with a clean slate for your next experiment.

Commitment

The commitment phase begins when an experiment produces no issues. We then

  1. analyze: make sure the changes in the working tree make sense to commit;

  2. commit: commit those changes; and

  3. check: check off the associated node(s)

Sometimes, we analyze the code and find out that it doesn’t really make sense. In this case, try another experiment with a related node. Once it makes sense, commit that code! If at any point you must explore, undo all changes to the working tree and bounce back to the first phase: exploration.

Sometimes, the check step will result in only the goal remaining unchecked. If there is more work to be done, it’s back to the exploration phase! Otherwise, enjoy the completion of your work!

Begin

The Mikado Method starts with a goal. Easely provides one for your graph, which can never be removed. You may add dependencies to it and complete it, but it’s always there:

Change the goal in the graph to meet your needs. Usually, this is the user story or ticket you are working on. It’s best to keep it simple and representative of your work to the point where you know what you are working on at a glance.

For example,

As a user, I want to register an account

Or perhaps simply,

Registration

Explore

Experiment

Run an experiment by implementing the node as naively as possible. Perhaps we choose to save the user’s form entry, but alas, we have not the URI endpoint or the repository!

Most of the time, there are errors! We learned something about our code! These errors are commonly seen as frustrations, but the Mikado Method uses this feedback to fuel the next change. Next up, visualize.

Visualize

Write down the solutions to these errors in the graph: implement the endpoint on a URI and create the storage repository.

Undo

Take heart and enjoy the safety of a clean slate where the code works, protected by its tests. This is where we set ourselves up for the next experiment!

Commit

Binding to an endpoint is often as simple as an annotation on a method. However, that change is nonsensical. It must have something to do.

Wisdom for the Mikado Method

Commitment to naive simplicity in implementation.

Common Troubles

To Undo or Not to Undo

We are human beings and we are vulnerable to the sunk cost fallacy: the more we invest, the harder it is to pull the plug. This hits home for software development as well. The larger the diff of our working tree, the harder it is to undo - it just feels wrong! This is a trap.

The longer we go without undoing our work, the larger our diff becomes, the more context we must juggle in our brains, thus the pace of work continues to slow down.