Modern software development has given up on planning and has taught a generation of developers that backlog prioritization is all we need. Of course, the result is a bloated, messy bunch of backlogs that give us no answers to the questions that matter.
So, when I sit down with a company to walk through their plan together for the first time, it's not the lack of structure that shocks me. It's not the fact that developers aren't involved in software planning that catches my eye.
What usually stands out is the gap between the intentions of the plan and the team's day-to-day reality.
All teams have some big dream that they "plan" to do. Add that new fancy calendar feature. Fully migrate away from Angular to React.
Often, these intentions are written down on an old roadmap slide deck. Yet, all these dreams get drowned in the sea of prioritization.
They created calendar tickets months ago but aren’t closer to building the feature.
They moved some of the code to React but are now stuck with a Frankenstein front-end architecture.
Business as usual looks an awful lot like getting nothing done.
When I discuss this with a team, there is often a sentiment of "professional embarrassment". Like visiting the dietician when you know you've gained weight. There's a sense they should have done better.
However, a team can do little to stick to its intentions without a structured plan. It's not a lack of willpower. It's a lack of systems.
Intentions are born at the highest level. In our minds, we'll claim to move the entire app to React. We don't think about the list of all the low-level components that need to be migrated.
That's why one of the first things I advise teams to do is to turn their unstructured backlog into a hierarchical plan. It’s a small step towards massive change.
A hierarchical plan is a tree structure where parent items have children, and those children can have children of their own. Most planning tools support tasks with subtasks or Epic with Stories.
This is similar to the traditional Work Breakdown Structure, but the tree's leaf nodes don't need to be work items. It can still be a hierarchy of Stories or outcomes.
The point of this exercise is to look at the plan both top-down and bottom-up.
Our top-level items should reflect our strategic outcomes and intentions. "Migrate to React" is an excellent top-level intention. Each top-level item in the tree should have a set of children. When all of those (grand)children are Done, so is the parent. It gives us a high-level overview of intentions and a crude but easy way of tracking progress.
When looking at the plan bottom-up, leaf nodes should have a parent. Those that don't have a parent don't contribute to our strategic outcomes. While that doesn't always say much about their importance, it does help us make decisions when focusing.
With this crude tool, we can start fascinating focus conversations.
"The Angular-to-React migration is already 75% Done. Maybe we need to plan a last push and get it over with?"
"We said we were going to focus on the new calendar feature, but we've spent most of our time on unrelated tickets last sprint. Are we going to drop the feature or double down and focus?"
“A quarter of our leaf nodes are loose bugs without parents! Let’s take the time to get rid of those first….”
A hierarchical plan allows us to look at a higher level and start interesting conversations. Throwing away that one stakeholder’s Jira ticket is a painful discussion until we can see its place in the hierarchy. Once we all can see it doesn’t contribute to the strategic outcomes, descoping becomes easier.
A final benefit of this kind of structure is that it brings developers and management closer together. Changes on the work floor have a direct impact on the top level of the plan. We can measure the children's progress and therefore show realistic progress on the top-level strategic outcomes.
“Our strategic roadmap says we should be working on multilingual support, but the data team is still working on their model improvements. What do we do?”
It's impossible to have a gap between intentions and day-to-day work when those are hierarchically linked. Bye, unrealistic roadmap slideshows. Hi, real-time feedback.
A hierarchical plan is the first step to building an actionable roadmap. It puts our teams in a position to start taking control of their never-ending to-do list.
It’s also surprisingly easy to get started.