DeveloperBlogs
Team Mechanics Part 1 – Planning with the Mikado Method
Every team has its own way of working, some more effective than others.
The SRE (Site Reliability Engineering) Team has faced unique circumstances that have brought unique challenges. In response, we’ve developed deliberate, collaborative approaches to plan and deliver work more efficiently. We’re a small but focused group: three Senior Developers, one Lead Developer and one Quality Assurance Engineer.
This is the first post out of two, offering an insight into how team mechanics work within our team. The first of these posts offers a brief look at how we plan as a team, and how these practices help us work smarter and more effectively.
Building our approach
Planning can be a challenge for any team. Too little planning can make it a mystery as to where you’re going, and too much planning can take up a lot of time, often making people feel like there is not enough flexibility to react to new information. Due to this, the process in our SRE Team focuses on incrementally planning and building up our plan as we go, allowing us to have a better idea of what is happening without it being too in depth immediately.
We work in two-week sprints, each of which we scope at the end of the preceding sprint, using lightweight planning methods such as a Mikado tree to plan incrementally. We start with a high-level view and progressively refine it as new information is uncovered. This allows us to plan out the task, while adapting to the information we gather throughout.
Mikado Method
We apply the Mikado Method to every piece of work that enters our SRE Team, enabling us to slice tasks effectively and communicate dependencies clearly.
This is the slicing and planning process the team has used for each of our goals, which often contain a huge number of subtasks with complex dependencies.
Slicing
The Mikado Method incorporates slicing, a technique that allows us to decompose a goal into smaller tasks, and then to break those tasks down further as we attempt to complete them and encounter complexities.
If, for instance, the team was asked to create a new web page to manage books in the company library, we can assume we would at least need to implement the following:
- Front-end page:
- Component displaying the list of books.
- Component displaying an individual book.
- Back-end APIs:
- [GET] returning all books.
- [POST] to add a book.
- [DELETE] to remove a book.
This is the first iteration of slicing this goal into tasks.
If we begin work on [GET] returning all books, we will quickly discover we have no database to fetch the books from and may hardcode them or store them in memory to prototype the API. Since this is likely insufficient for a final solution, we then create additional subtasks to bring the API up to the requirements.
In the second iteration of slicing, we may decompose the task into these subtasks:
- [GET] returning all books.
- Create a book table in the database.
- Populate book with books that are already in the library.
- Add code behind the [GET] API to return books from the database.
Modelling Dependencies
As well as slicing, The Mikado Method also incorporates planning, as it models the dependencies between individual tasks that make up the solution to a problem.
If we model our parent [GET] returning all books task as the head of a tree, we can represent the order of dependency between its subtasks:
This is a Mikado tree, which is a form of Directed Acyclic Graph.
The ‘A → B’ notations in the tree mean ‘A is dependent on B’. Therefore, the next task to complete is located at the bottom.
The tree makes it immediately clear, both to the team and to anyone outside it, that database work must come before the API can be fully implemented.
This is usually done iteratively from the goal down, to produce a complete tree that represents all the work required to solve the problem, and the order that work must be done in.
Summary
The Mikado Method provides a structured way to decompose complex changes and model their dependencies. By iteratively exploring a goal, identifying obstacles, and mapping these findings into a dependency tree, we create a clear execution path that the whole team can follow. This approach reduces rework, prevents hidden blockers, and allows concurrent development by showing which parts of the system can be tackled independently.
Authored by Blaise Duggins & Ethan Hawkins | Senior Software Engineers | SRE Team
Codeweavers
Read more by Codeweavers
