One of the hottest questions these days, whether online or in the boardroom, is “How does the organization become more ‘agile’?” As the discussion evolves, it leads to, “How do we scale agility from one team to multiple, or should we?”

Scrum being the most common agile way that teams work leads to the question of, “How do we scale Scrum beyond a single team?” However, the question should instead be more concerned with what product(s) is being delivered and what is the most effective way of doing so.

When should you scale Scrum to multiple teams? This question isn’t as difficult as it may sound. Scrum is based on the delivery of a product. The optimal development team size is between 3 and 9 people plus the product owner and Scrum Master. This means that if you can deliver your product with a team of 9 people or less, then there is no need to scale. If you determine that you need more people, then the decision to scale must be made, but scaling decisions should not be taken lightly.

As soon as you go from a single Scrum team to more than one, you now have added cross-team dependencies and communication. This can be solved, but it is something that has to be considered and addressed.

For every additional Scrum team, the coordination of product delivery becomes more complex. Together they need to deliver an integrated product that meets the vision of the product owner and the needs of various stakeholders and users. If you scale Scrum correctly, there should not be a major impact on the organization other than better coordination across teams and people.

If you look at scaling Scrum as multiple Scrum teams working together on a product basis, replicating how a single Scrum team works, then the organization will become more efficient. They will have greater visibility into the work being done through higher levels of transparency, providing a greater value to users of the product and therefore to the organization overall.

Define ‘product’
It is imperative that the organization agrees on the definition of products and what the boundaries are for a single product. Is a set of capabilities a product, or parts of a bigger product? Without this understanding, it becomes impossible to maintain focus as a team, or set of teams, and to provide product ownership. So, look at how you are defining the product, how many products you have and what may tie them together or separate them from each other.

When you go beyond a single Scrum team to deliver a product, coordination needs to scale as well. This is why there is a single product backlog for the product and it is transparent across all teams. Planning at the product level also must be done across Scrum teams so that everyone is on the same page with what is being planned to deliver and how they can best organize their work.

At the same time, you need to have a vision for the product, have an idea of what you want to deliver over a small (3- 5) set of future Sprints and work together in this planning. It doesn’t mean that your vision won’t change and that you won’t inspect and adapt in each Sprint, planning what you will deliver. It means you have a common understanding and vision moving forward. As you scale, this becomes more and more important.

Don’t, however, let the vision and Product Backlog become stale. Too often, the “roadmap” becomes set in stone and it isn’t evolved Sprint by Sprint. This leads to a mini-waterfall approach and runs the risk of delivering the wrong thing or less value over time. If you revisit the product backlog on an ongoing basis, you are much more likely to continue fine-tuning it for each Sprint and deliver higher value products in the end.

Challenges of scale (HINT: There is no silver bullet)
Too often I hear people at conferences or in meetings talk about how they want to “buy agile” or “go agile,” but they lack the understanding of what that really means. When digging into the conversation, it tends to go down a path that they can just buy some tools and apply some processes and now they are magically agile, but that just isn’t the case. There is no “silver bullet.”

Even if you have a team of two people working together, you start to encounter dependencies on each other. Now as you scale up to multiple people, the dependencies increase as well. Imagine now scaling to multiple Scrum teams working together to deliver a product, the dependencies will not only cross individuals, but also Scrum teams. A

s product backlog items are being decomposed, dependencies will emerge. It is highly recommended that you categorize dependencies and visualize them to make it easier to grasp and communicate them. Categories for dependencies may include items such as:

  • Build Sequence – An item cannot be completed until its parent is complete (can include technology, domain, software…)
  • People / Skills – Only certain people/teams can complete an item
  • External – The parent item is being delivered from outside the Scrum teams

Once dependencies have been visualized and sequenced, conversations should focus on opportunities to minimize and remove them. Some solutions include:

  • Moving work between teams so that there are less cross-team dependencies.
  • Moving people between teams so that there are less cross-team dependencies. You may significantly reduce delivery risk if certain skills are rebalanced across teams for a Sprint or 2 in order to minimize dependencies.
  • Reshaping the work. By splitting items in different ways, it may be possible to eliminate dependencies.
  • Using different risk-based strategies. Some groups might try to entirely remove an ‘in-Sprint’ cross-team dependency. Other groups may opt to front-load all the risk as early as possible and take many cross-team inSprint dependencies in earlier Sprints in order to learn and respond.

Once the Scrum teams understand the product backlog and item dependencies, plan for a Sprint and begin developing, they are then well on their way to product delivery. In Scrum, you can deliver as often as the product owner wants during the Sprint, but you must deliver a potentially releasable product at least once per Sprint. As you scale to multiple Scrum teams working together to deliver the product, you need to start thinking as a whole. No longer are you thinking of individual “team products,” but instead, “How do we deliver an integrated product together?”

As the Scrum teams come together for the Sprint Review, they are coming together to review a single product and should be demonstrating that product in its entirety, not pieces based on the individual teams. This helps get true feedback from stakeholders on the real usage of the product, but also determine if any integrations, cross-team dependencies, etc. were missed.

It isn’t always about getting bigger, however. As a team, you need to look at what is needed to deliver the product and that may not be getting bigger. It could be a reduction in size, or potentially scaling up at a point and then being smart about scaling back down over time.

As we know, and I already wrote about above, the bigger the team, the greater the dependencies and more difficult they are to deal with. So, as you are looking at the product backlog and working with stakeholders and the product owner, start to determine what the right size of the Nexus should be. Evaluate options for how quickly to scale up — faster isn’t always better — and if you have opportunities once scaled up, scale back down over time.

Conclusion
At the end of the day, Scrum is a simple framework that is difficult to master. Scaling Scrum or just scaling up to bigger teams adds complexity to how people and teams work. Being a framework, Scrum provides an excellent way to helps teams scale without having to change their entire worlds. Scaling Scrum is just Scrum. You don’t change how you work as a Scrum team nor do you change the work being delivered. By adding the Nexus framework on top of Scrum, it provides teams with a way to deal with cross-team dependencies and ensure that they are all working together toward a common product goal and product increment