Growing your agile project into a multi-team setup can lead to facing multiple challenges and pitfalls. The first one is most likely choosing the scaled framework, that you’d best like to use as a base. There are quite a few, and here’s just some examples:
• Starting with
Nexus, a relatively new framework founded in 2015 by Ken Schwaber.
• Continuing with
LeSS, a very popular and lightweight framework.
• Moving on with
Scrum@Scale, developed by one of the co-founders of Scrum, Jeff Sutherland.
• Finishing with
SAFe, a bit heavier, enterprise-level framework for expanding Agile across a corporate environment.
Although, this list does not cover the whole range of available frameworks out there, it should provide quite an extensive view at the
best approaches and practices. I highly recommend doing some reading on the above, before proceeding further; a bunch of smart people put a lot of work into these frameworks using their knowledge, experience and expertise, so you can save yourself some trouble in the future by at least having some of their ideas in mind.
By now I’ve hadn’t the chance to run a project using a pure implementation of the above frameworks above, rather a collection of their best ideas, my own experience and empiricism while working with multiple teams. Hence, all the remarks I make are come from project experience to help you omit some of the mistakes I have made. And whether you choose to follow any framework or give it a try on your own, I’m certain they’ll come in handy at some point.
For the beginning, one important thing to know is that eventually growing the number of teams working on a single product backlog will not provide linear increase in productivity. While working with 2-3 teams might give that impression, it is not so when heading into double digits. In my past experience, while working on a major project for a customer in the telecommunications sector, we have experienced a 30% productivity increase (expressed in delivered business value) when ramping up from 6 to 9 teams, so theoretically a 50% increase in teams’ capacity. This was caused by several factors, such as those related to the product: growing complexity of codebase and product itself, however mostly by the introduced overhead. More teams mean more synchronization, more communication and better roadmap planning is a must! Do not be surprised when your project velocity will not skyrocket once you’ve doubled or tripled your team count.
As I mentioned, scaling comes with the need to better plan ahead. Since you will be working with multiple teams, you will need to: split and manage the backlog across those teams, identify and address dependencies – all of that while caring for the highest business value to be delivered and the correct priorities. And while planning does not mean losing agility, it does impose some constraints. You have to decide how restrictive you want to be: one idea is defining team specializations, such as functional areas, component areas or business case groups. By doing that you narrow down the focus area of the backlog for each team, which means they can be dedicated to working and planning that particular area in more detail, have better knowledge about that area and can refine new items in that area faster and with higher accuracy. That way you have more control over what’s to come, but… there’s always a “but”. By restricting the scope of the product backlog across teams, by building that sort of team silos you often trade-off for flexibility. The teams will not be as capable, to quickly jump in and react to product demands in a different silo, because they are proficient in their own and not so experienced in others. Of course, having a large and complex product will impact the ramp-up time on any new topic for any team; there’s a limit to how much knowledge about the product any team member can keep in their head at once. Nevertheless, this is one thing to consider – should you value flexibility above all, then perhaps it’s better to ignore team specializations and working on the highest priorities with all teams (a bit more overhead and slower ramp-up time, but you deliver what is most important at a given point in time); otherwise if precise planning is what matters the most, then feel free to build feature teams as recommended by the LeSS framework for example (less flexibility when reacting to change top of the backlog, but faster delivery and less overhead when teams proceed according to plan).
The next thing to consider when scaling are roles. Having a single Product Owner should usually work when starting to scale up to 3 or 4 teams (again, everything depends on team construction, product complexity, etc.). When thinking about more teams it’s a good idea to start thinking about some sort of a PO hierarchy to support that number of teams. LeSS recommends defining Area POs starting from 8 teams (LeSS Huge), however in my experience introducing more POs at a slightly earlier stage can already be beneficial to the project. What is important to keep 1 single PO entirely responsible for the product and its vision. The remaining POs should work with him/her, being responsible for their areas (for example: functional areas of the system). It is also vital for all of the POs to communicate frequently in order to synchronize and maintain the same understanding of the product at all times. All conflicts between Product Owners should be resolved by the “head PO” as a last instance. When it comes to the Scrum Master, it seems the case is a bit simpler. The Scrum Master as a servant leader needs not only time to facilitate work for the Scrum teams, but to constantly seek improvements and promote the Agile culture in the organization. Having said that, I found it optimal when working with 2 teams at a time. For functioning teams (not necessarily mature ones) that should allow the Scrum Master to work efficiently. There’s only one remark: when ramping up new teams, take it 1 step at a time! It’s not a race! Building a new team requires much effort and time from a Scrum Master so don’t attempt to do that with 2 teams at once – something will go wrong eventually. What I can recommend is to get the first team settled in and then proceed with the next one. Another thing which seems like a good idea when scaling Scrum teams is having some sort of a connector in each Development team. In a recent project, we called them “technical bridgeheads” and their role (in addition to their role in the development team) was to provide additional communication between the teams with regard to technological product vision and architecture. The Nexus framework has a concept of a Nexus team, where the members may be a part of the regular Scrum teams – well this is a similar concept.
When ramping up with more teams, there are certain things that will need rethinking – this depends on your starting point: if you are adding one team at a time (it’s a good idea to take it slow), then most likely you will observe the impact and the need for improvements while working with the teams. If, however, you are thinking of going from 3 to 6 teams for example, there are a bunch of things to consider beforehand:
How to ramp up without drastically losing velocity? I know the 2 most common approaches: shadowing and mixing. Shadowing is having 1 new team shadow or follow an existing, experienced team in their duties for some time. This take some time off the existing team for knowledge transfer and supporting the new team, but does not disrupt the (very well) functioning team. This approach may take longer. Mixing is splitting up existing teams and pairing them with new ones. This approach is more revolutionary, however may result in faster ramp up. The teams may lose more velocity at the beginning as compared to the first approach.
How to handle the Scrum events? The mentioned frameworks provide quite a lot of information on how to handle the events with multiple teams. Some most critical aspects for me are ensuring: an overall joint review, a follow-up joint retro and pre-planning/planning sync. First of all, make sure to have a common review for all teams working on the single product. I cannot stress enough how important it is for cross-team synchronization of the product status, for common understanding of the vision and… for building cross-team relations and integration of team members. If your teams are distributed, consider bringing them all together once every review. Make a happening of it, for example by having a review fair and don’t forget to celebrate! Next, ensure that you share your retrospective findings across the teams. After having your team retros, have an additional session with team representatives (technical bridgeheads for example) to discuss the outcomes. You may be surprised that many topics will repeat across multiple teams and this will make it possible to plan work on an impediment at a higher, project level, rather than starting from a team level. Last but not least, think about synchronizing the planning events in a way to: spread the information across all teams, identify cross-team dependencies and (in case your backlog is not split into dedicated team functional areas) have a prep of team backlog candidates for the planning (sort of like Sprint Planning 1 in LeSS). Up to some point it’s mostly possible to have the events for each team in a sequential order, thus allowing some team representatives to join other teams’ planning events and share their experience with their own team – that’s always very helpful in planning the work to be done and mitigating risk related to code-level conflicts / dependencies.
Considering all of the above, one could ask a question: “Is it worth it?”. Is it worth the effort, the pitfalls, the overhead to scale to multiple teams? Well, the answer is YES! Once your product starts benefiting from Scrum and if you would like to grow, expand without losing too much of those benefits, this is probably the only way to go. What is important is that Scrum allows you to learn from your mistakes; whatever decisions you would make while bringing in more teams, you can always Inspect & Adapt every step of the way. Never forget that good communication is crucial for this to work – you will never be able to replace human interaction with processes. Try setting up communities of practice for example, for building constant cross-team relationships. Try enabling other effective ways of communication for the teams, as the glue that holds them all together; then you’ll be successful.