Leading Team

…you are developing your product with multiple Development Teams.

✥ ✥ ✥

A new business opportunity arises and you need significantly more development capacity, more than you can develop incrementally

The Product Owner expects that in the near future the current opportunities — described at the top of the Product Backlog — will require significant effort from the Development Teams and significant effort is also required to explore the new opportunity. If current Development Teams work on the new opportunity then there is an opportunity cost for this new work from missing current, understood opportunities.

Adding people to increase productivity in a complex domain requires carefully attention, as James Coplien points out: “development is not the same as building pyramids” [0]. In a complex endeavor success comes from effective communication across people working on the “parts” (whether physical or logical). That communication effectiveness plummets with scale. The temptation to focus on lines of code, to add extra roles, artifacts and processes feels natural, but doing so will slow development down instead of speeding it up.

A team with expertise about the business domain performs better than a team without that knowledge, all other things being equal. Adding such a team is preferred. If there is no such team available then the only thing you can do is learn about the business domain fast.

Adding a team that is unable to build a releasable increment at the end of a Sprint will not increase your overall development capacity - it will probably decrease. For example, if a single team already cannot complete testing within the Sprint then introducing multiple teams will give you an increase in untested product. The costs of testing later accumulate exponentially and therefore, it is necessary to improve your Scrum before you use it at scale.

You could choose one person to work on the new opportunity, but that would disturb the current team and that person can probably not produce any working product on its own. You can also decide to hire a new team and have the team work on its own, away from the teams. The new team can make progress really fast with minimal alignment. But then the team will lose focus on the whole product, will optimize their own work locally, will delay integration with other parts of the product, and the Product Owner will have opaque measures of progress. Scrum solves this by having all teams keep the focus on the whole product and deliver one integrated Product Backlog every Sprint.

Therefore:

Add an existing high-performing Development Team to work on the business opportunity to learn fast about its development risks and business potential.

The new team becomes a Leading Team that develops features of the opportunity into the Product Backlog that can be validated so that the Product Owner can make informed decisions. The faster way to learn is to break the new opportunity up into a few big pieces and a few small pieces that can be implemented quickly.

If the work for the current opportunities decreases, the top of the Product Backlog will be have more and more PBIs from the new opportunity. Over time more teams start working on the new opportunity and the leading team coaches the new teams up to speed. The leading team shares their learning experience, domain and product knowledge into the larger organization that will carry it into the future. The Leading Team together with the other added teams could form into a new Value Area.

✥ ✥ ✥

Each team is an Autonomous Team while still working together off a single Product Backlog keeping the focus on the whole product and producing a single Product Backlog every Sprint. All the teams are guided by the Vision.

[0] James Coplien. IEEE blog on pyramids and development (todo).

Picture from: Vive L’Empereur (Charge of the 4th Hussars at the battle of Friedland, 14 June 1807).