Mastering Team Planning

A Guide to Effective Collaboration and Sync-Up

A good plan helps us focus our team's resources and manage our stakeholders' expectations. To be an effective team, we need an effective plan.

But plans really become a necessity when working with multiple teams. In fact: the more teams we have, the more important planning becomes! There is a real risk of individual teams building what's right for them while the organization gets nothing done.

Teams need to align, and they need a plan to do that.

So, how does that work?

We've learned to avoid inter-team dependencies. We don't want a front-end team waiting for the back-end team's changes. I feel that, as an industry, we've learned that lesson. These days we aim for self-organizing teams that own (a part of) the product. These teams don't depend on each other and can build without being blocked. That's how we scale our organization: through independent teams.

We want teams to own their plan and integrate it into the company-wide roadmap. Owning the plan does not mean each team can decide freely what to build. It means changes to the plan need to be negotiated with the team that will deliver them.

Each team gets its own swimlane on the roadmap

When designing the roadmap, we’ll ensure the teams simultaneously address a strategic outcome rather than just burning through a to-do list. I’ve seen organizations be very successful with setting themes per quarter: “During Q1 all teams will work on performance improvements”

While these teams work towards a common outcome, they don’t have to negotiate and plan together. There is no heavy-weight centralized planning but a constellation of self-steering teams. That’s the ideal.

95% of team planning is good team design.

With such an independent ideal, it's easy to forget that we don't live in an ideal world. Despite our best efforts, teams sometimes do need to collaborate and sync up.

So, let’s talk about the other 5%…

Let's say we have a native mobile app that's maintained by two teams: one for iOS and one for Android. We want to design a new intricate component. We have some idea of what it will look like, but we fear we might run into the limits of one or both platforms. While the designers will come up with the big picture, developers will tweak the details until it feels good on both platforms.

We could choose to go down the path of upfront design, but there's an almost 100% guarantee of rework: we're sure to bump into unforeseen platform limits while implementing the component.

We could do the Android version first, but that only solves half the puzzle: if the component clashes with Apple's design, we're back to square one.

We need both teams to collaborate on the details.

When we need to synchronize, we need to sync up Focus Blocks on the roadmap.

We plan two identical timeboxes for both teams in the same period.

That 🔒 icon means both Focus Blocks are linked: they can move around, but they have to happen simultaneously.

Starting February 13, both teams have three weeks of uninterrupted focus time to solve the problem. They could merge standups for those weeks. They could pair program across teams. The agendas are free to do whatever is needed to solve the problem. It’s one big two-team three-week hackathon.

Notice how the Recovery Blocks are also linked. While not 100% necessary, it's a good practice. Issues found in the Android version will often impact its iOS sibling. Syncing Recovery Blocks allows teams to collaborate on bug-fixing right after delivery.

Synchronized teams make our plan more rigid. We can still rearrange the roadmap, but we'll need to find five weeks to fit the matching Focus and Recovery blocks.

Just like with promises, we don't want to overdo it. Too many synchronizations lead to overly rigid, brittle plans. Hence, the 5%.

When teams are well-designed, we don’t need to synchronize that often. In fact, two teams that need to synchronize more than occasionally is usually a sign some redesign is in order.

So, when do we want to sync up? Whenever two or more teams need to solve the same problem! That way, they can pool resources and share knowledge.

Finally decided to bump that Java version? Sync up all Java teams.

One last push to get rid of AngularJS? Sync up the impacted front-end teams.

Three apps moving to a new payment provider? Why not do it together?

Planning for multiple teams requires Focus Blocks and some form of self-organization. You don’t want a manager to act as a complicated orchestra's conductor. You want a jazz band where every member knows how to improvise.

So, design your teams to be as independent as possible and use the roadmap as a way to integrate plans. When multiple teams must solve the same problem, sync up Focus Blocks and treat it like a promise.