Maze charts — a way to manage expectations
I’ve been on the “estimation of tasks” bandwagon for years now. I’ve probably made all the mistakes out there: from the vicious cycle of inflated evaluation to the optimism-biased assessments. Even after zealously applying all techniques, I still needed to communicate with stakeholders what was going on after we agreed on some form of planning. All tools and practices missed some critical elements in the working relationship that were important to me.
Estimations are hard. Starting a task is easy. Managing expectations during a job is very delicate. This journey always indicates that:
Work is not always linear because of complexity and entropy.
Even working with small increments turns out to be pretty dynamic throughout the day. It came to me with no surprise that others have experienced this and tackled it. Hill charts are one example that tried to explore this, but there were problems I felt as well. It’s still unclear how much sweat went uphill. It’s still unknown what will-force I put when going downhill. I can split epics while losing the notion of how hard it was to achieve the overall results. Retrospectively it’s easy to describe what hurdles I went through to deliver something, but during the “crafting phase” itself it’s challenging to explain all the intricacies.
But the idea of “figuring things out” and “making things happen” struck me as I was constantly switching between those two modes most of the time. The amount of research I did position me in one of those two modes. I felt like I was going through a maze when I married the necessity to express the progress I achieved with how deep the research rabbit hole of my work was. I’ve entered it from one spot, but it was tough to exit it. This metaphor expressed the concept of non-linearity while communicating the idea visually of what I’m going through with a task and how I manage the complexity.
By capturing my journey visually, I can output a “maze” chart. I’m in the “figuring things out” mode if I deal with problem-solving of ambiguous tasks. I’m in the “making things happen” if I’m implementing something with certainty.
“Every journey starts with a single step.” — Lao Tzu
With the maze chart, estimates are no longer a predictive game where I need to size efforts. Instead, I now communicate from where I’m going to enter the maze, the rest is just unfolding, and I’m mindful enough to capture it.
Am I anticipating a lot of research right from the start? Then I’m somewhere between 50% and 100% on the left. Is it crystal clear to me what I need to do? Then I start around 0% and 50% in the “making things happen” area.
I capture my maze journey snapshots after a meaningful milestone (delivered a small increment) or at the end of the day. Sometimes is hard to express in words what I’ve come up while implementing some features, but team members can see the ups and downs and immediately deduct that I might be in some trouble. Then, after I pick an entering spot depending on the task at hand, I begin diving into the task to reach the next maze checkpoint.
There are different ways to “connect the dots”. The discussion focuses not on “when this thing will be ready?” but to “what happens next?”. It also expresses changes in our developer journey. Am I missing a UI spec and need to improvise? Then I go up in the “figuring things out”. Have I understood how to create an impactful proof-of-concept feature? Then I go down in the “making things happen” where I need to typewrite the code behind all. Am I finishing the day without any deployment but many experiments? Then I capture my current situation, which brightens up my mood because even without a single line of code committed, I’ve managed to move towards the exit a little. That’s quite refreshing.
I might be able, in four swift checkpoints, to deliver a meaningful task while realizing that I have no idea how this code will scale? I try to communicate that with the team by exiting the maze chart with a high research factor. After ten years in this industry, I now start to face the fact that most of the time, I feel lost. I see only small steps ahead. Like in a maze where I want to orient myself by keeping track of what roads are unfruitful.
Every journey is individual.
I started slowly adopting the maze chart in my daily work; soon the rest of the team began expressing their journeys. We began capturing big epics in mazes and explored some of them. It made us aware that while we work remotely, we experience the same bumps every. One can start overconfident that a task is easy but soon gets stuck, for example by integrating a foggy API. The focus on the journey, not the destination, is liberating as now we can better communicate with stakeholders our “human checkpoints” in developing the product. And if I’m time deprived of doing a proper async status report, I quickly add a dot in the maze to continue the path forward.
Over one hundred maze checkpoints later.
After three months and numerous maze exits, we start having a bird’s eye view of how the team manages complexity. Some features take longer and are suitable for maze charting. Others are one-off bug fixes that don’t require the overhead of communicating them visually unless they are batched together.
Maze charts answer simple questions like “How are things progressing with this task?” so there’s space for the discussion to be refocused on the human part of the journey — “I see you’ve been through a lot, how are you holding up? Can I help?”.
The maze is not the silver bullet chart — it’s just another tool in your belt.
You might still need Scrum in your team. Lean, agile, kanban, etc., might still be required. Story points estimations might work better for you. But if you find yourself needing a way to communicate with what “mazes” you’re dealing with constantly and that the job at hand is not trivial, you now have a way to visualize it.
This post is one example how we do things at Camplight — every team can decide on it’s own what’s his development flow. We practice self-organization and let the best ideas to organically blossom in order to become company practices or guidelines. The maze charting is being used in only one team but we were eager to publicly showcase the results.
Care to share how your team communicates handling of complexity? Join the comments 👇