Also plans
Most of us struggle with the long-term planning of software products. One of the clear tells is a proliferation of plans. When I work with a new client, I often see multiple plans for the same product and team. There is a myriad of Jira boards, Excel files, and backlogs. There's a Roadmap, a Sprint plan, and a set of OKRs. Each carries expectations, and if these aren't synchronized, the outcome is sheer frustration.
We create these new plans because tabula rasa feels good. "Here is how we will roll out the Android app". It's much easier to show this "Android app" plan in isolation and ignore all the other clutter. It makes life easier for those that create the plan at the expense of those that need to execute it.
I call these "Also plans". Instead of sticking to a single focus, we describe things the teams should also be doing.
"Also plans" are the enemy of focus.
They are the side effect of a top-down hierarchical organization where the top decides what to build and the engineering teams merely execute. It's easy to see where they come from. If a middle manager gets the request to develop an Android version of the app, they will create tickets. These tickets will get an implicit deadline and become yet another plan.
"Also plans" create pressure and stifle innovation:
They ignore team capacity.
Planning for a new feature this way starts with an old-school Work Breakdown Structure. We list the 15 tickets needed to complete the desired functionality. Starting from scope guarantees that we will overload the team. A good plan should start from the team's capacity. That includes looking at the entire workload, not just the new feature.
They break focus.
A focused team works on one problem at the same time. That requires one single plan. We can't focus on A and also do B simultaneously. Yet that's what "Also plans" force us to do. While working on A, there is always the nagging feeling we should also be working on B.
They fight for attention.
Building the Android app should take only six weeks. The team can definitely do this in Q1, right? By looking at only the plan of a specific feature, we ignore all the other plans the team has to juggle. Those that create the plan shift the responsibility for sticking to it onto those that execute it. They base themselves on gut feeling and sheer optimism, leaving others to clean up the mess.—a recipe for frustration.
They take away agency.
Engineers know the product best. By being on the frontlines of bug reports and error logs, they know when the system is bursting at the seams. They have a good understanding of where to improve. Yet, in an organization that is swamped with "Also plans", they have no incentive to innovate. Every good idea would just increase the pressure they already feel. Technical improvements and bug fixes often land on a "technical debt plan". Another "Also plan" that never gets the required focus.
The cure is simple: there should only be one unified plan. When we look at that high-level plan, we can zoom in on each item to get more details. Problems on the roadmap might contain Features, which have User Stories that might contain Tasks.
Such a hierarchical plan makes focus possible. When a team is working on Problem A, there is no expectation for them to work on any other stuff. When to tackle A, B, and C, becomes a question for whoever builds the plan. Rather than pressuring the teams, the onus for controlling the timeline falls on those that make the plan. That's the healthy way of planning.
"Also plans" look great in management dashboards but shift the responsibility to the developers. That makes them easy to spot once you know where to look. If engineers are part of multiple teams with their own line managers, that's a dead giveaway. If your team members look at multiple Kanban boards during the daily meeting, you've got one. That's a clear indication they receive conflicting priorities.
We can build a unified plan bottom-up by applying two simple rules. We only allow one Kanban board per team, and each engineer can be in one team simultaneously. As usual, simple doesn't mean easy. Implementing these rules often upends the internal structure of the engineering department and kills overly "ambitious" high-level plans.
"Also plans" are a symptom of a top-down organization. To cure the symptoms, we need to heal the organization. While painful in the short run, the health benefits are worth it.