Teams are the key to scaling your organization. Adding more individuals increases the number of communication lines, and it takes surprisingly little to reach the limit.
Dividing employees into multiple teams is a science on its own. Many companies struggle to find the right balance between big-ball-of-talents and overly segregated silos. Self-organizing cross-functional teams are the gold standard.
But how do you manage that? If every team has its own goals and ways of working, how do we set up a process for planning?
The straightforward answer is to standardize the process. It's something I've seen way too often. All teams should do Scrum, have synchronized sprints, and use the same Jira workflow. That way, managing becomes easy-peasy. I've seen engineering managers try to equalize the value of story points across teams!
Of course, this never works. All teams are distinct constellations of unique individuals. That's their strength. Trying to average that out just gets you... average. Bland, unproductive, milquetoast teams. That can't be the goal.
Instead of standardizing the way teams work, we should set out some top-down constraints. As long as those conditions are met, teams should be free to organize how they see fit.
These are my three favorite constraints for robust multi-team planning.
Initiatives need a single root ticket.
These days we want to capture feedback as soon as possible. Often, it makes sense to build something in a sprint and push it to production. But some things just need more time. Some things need to be built over multiple iterations.
These "initiatives" should be bundled in a parent ticket whose children contain all the scope. When all the children are done, so is the initiative. Most management tools support concepts like Epics or Features for this use case. When the parent has ten children, and six are done, we can say the initiative is 60% done. This allows for crude but easy progress reporting.
Unfortunately, I often see these initiatives spread out over multiple User Stories. This approach makes it impossible to quickly gather how far along an initiative is. When planning roadmaps, we don't look at User Stories. We only look at these higher-level initiatives. We need to be able to assess the progress of such an initiative quickly. Making your plan hierarchical will boost your planning power.
Constraint 1: Every roadmap item should be an Epic/Feature with child tickets to allow easy progress reporting.
One team, one board
The Kanban board has become a staple of software development. What used to be a whiteboard with index cards and Post-it notes has moved to the digital realm.
Every team has one. Or two. Or five.
Having multiple boards per team is a common mistake. Team members working on multiple boards make planning impossible.
The Kanban board is a team's tool for focus, but that only works if there is a single board per team.
From a manager's point of view, a Kanban board answers: "what is the team currently working on?". That question needs one clear answer.
Constraint 2: Enforce a one-board-per-team policy.
Maximum two concurrent initiatives per team
Initiatives are not projects. There often is no clear scope. A better way to look at them is bandwidth. I'm a big fan of doing one thing at a time. Sometimes, there might be a good reason to do a second thing in parallel.
There is never a good reason to do three.
As discussed above, we plan initiatives on the roadmap level. That makes them our main tool for giving our teams focus. If we ask them to work on multiple initiatives simultaneously, we tell them to multitask. That's terrible for productivity. It also muddies our plan: you can't easily measure progress for multitasking teams.
A hard constraint of a single initiative at a time protects the teams from multitasking. And yes, in exceptional cases, they can tackle a second one in parallel.
Constraint 3: Maximum two initiatives at a time per team. (But try to aim for one)
We now have a roadmap where each team works on a single initiative at a time. That allows us to timebox and plan initiatives. The answer to "when will X be done?" becomes straightforward: "at the end of its timebox". The crude progress reporting is enough to see if we're on schedule.
With a single board per team, we can now measure focus. If the team isn't working on the initiative they should be working on, we can see it and intervene.
These three constraints don't really restrict a team's flexibility, but they significantly increase our ability to plan.