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
A lot has been written about scaling agile, mainly using SAFe, LeSS, Nexus (or any other "scaled" framework). But we don't have the same amount of literature in terms of cases and real implementation experience. So here are my two cents! My experience at Modulo was great in this matter. By the time I joined the company leading the engineering group, we had multiple Scrum teams (covering both the web and the mobile versions of the product). Every team had one SM (at the time, the role was performed in some kind of job rotation, fulfilled by one member of the team — switched sprint-by-sprint), and one PO. Since we were short on POs (having only 5), most of the POs worked in 2 (or even 3) Scrum teams. These teams accounted for approximately 60 people (counting testing/QA, front-end, back-end, UX, designers, interns and dev-ops like personnel). Each team was formed by 4 to 8 people. Each functional group used to have one coordinator (mobile, support/dev-ops, integration, architecture, design, QA, and so on). The PO's were part of the Product team (and not from the engineering group). We had 2 main products, but under the hood they were built 70% on the same code base. So, internally we didn't differentiate much among them. The core of the product was (it is still) very coupled, mirroring the rules and concepts for an almost "full-fledge" IT-GRC product (Risk, Compliance, Governance, Integrated Workflow, Policies, Knowledge, Business Continuity, etc.). No microservices. Everything was built using the old monolithic approach that was common back in 2008, 2009 (when the core of the product was built). As usual, the product had (it still has) some technical debts, a complex architecture, a lot of bugs, a very large code base (approx 3M loc), and no automation, which in turn made the bug fixing process difficult and time-consuming (to say the least). Individuals and interactions over processes and tools (Agile Manifesto) People are the key part of any agile implementation. They are key, even in understanding why and when to break the rules and to make exceptions. If you have a very coupled codebase, it's not easy to isolate the modules in terms of function. So, how we dealt with it? We did something "not recommended" for a Scrum team. We assembled 1 large team (12 people) to handle the core of the product. This group, although using Scrum, had a very good "project manager"-type as a dedicated Scrum Master. So, besides facilitating the team, helping in the conversation with the POs, he added a lot in terms of project management. For this large team we had people with previous experience in every single module the team was responsible for. So, the team was in some sense self-sustained. We also had one of the best testers and a very good architect in the team. Another change: we changed the focus of the Dev Support Team for a DevOps approach, mainly focusing on fixing some of the problems we had with our dev infrastructure. Learning points: If you don't have the right people, (you can hire them or) you have to adapt and work with the people you do have, providing coaching and any early guidance necessary to the missing knowledge areas. You also need to understand what are the trade-offs you are working with, so you can help the team to manage them properly. In our case, for example, I was sure the communication would be an issue, but I was confident the SM would be able to handle it well (as he did). At first, each team used to have at least 3 different backlogs (sometimes 4). The PO managed only new stories, the support group managed the customer tickets backlog, the QA coordinator — and myself — demanded the team to fix all high priority bugs. The chief architect requested compliance/adherence to the product technical architecture and demanded the teams to pay the tech debts. So, let's go one step at a time. You might be thinking about it: the PO is not supposed to manage the bug fixing. You are right. Well, at least partly right. If the PO seeks for excellence, paying the debts and letting the team work, you are right. But… What if the POs pushes the team hard only monitoring the velocity? What happens to the product when you are demanded to ship it right away (anyway), not paying any tech debt? Well, the product as a whole suffers. The customer suffers. So, the PO had her share in the issue for sure. Remember that the PO is ultimately responsible for the product. If it has bad quality, well, the PO is accountable as well. How to change this chaos? Continuous attention to technical excellence and good design enhances agility. (Agile Manifesto) One of the first things we did was to have one engineer per team dedicated/allocated to customer tickets. This engineer could be rotated after each sprint, but every team had to have at least one dedicated engineer to fix customer tickets. This simple change was very powerful. It simplified a lot of issues and conflicts, and terminated the constant struggle between the product and support groups on what developers should do. What about the bugs and the stories (still 2 backlogs)? Well, in this case I managed to reach an agreement with the senior management to put in place a very restrict bug-fixing policy. All critical bugs should be prioritised over the stories. Period. So, if the team had 1 critical bug, someone on the team should halt what was being done (any story being developed) to fix the bug. At first, this meant a lot of failing sprints, since there were critical bugs. (It was just like the "stop the line policy" at the Toyota Production System; and as happened there, in the beginning, the line was stopped very, very often). I know it seems weird, and I do recognise all the problems with this approach. But we started to change the culture of the PO (since they were being directly affected) and of the team as well.Some context
Our products
Some of my learnings
Each team must have one (and only one) backlog.
Learning points: Each team must manage one (and only one) prioritised backlog. And make sure you have the right policies in place, so everyone knows the priorities at any single time, in a very explicit way.
The mindset beats the process. Every single time.
The agile mindset is one of the most important aspects of the agile movement. Delivering often is important, communication and collaboration are important as well. Besides, when you are building a complex and large product, slicing and prioritising the user stories is crucial. Understanding what is "value" is key. Learning and improving are two other keystones of the agile movement.
In our case, sometimes we had to slice the story and assign each one to different teams (since some of the stories spanned through more than one team). And we also needed to take into account the complexity of the codebase. Sometimes the PO asked for a 2-sprints story, refusing to slice it more to fit in 1 sprint, since “it would deliver no value unless delivered completely”… So, it was a constant struggle with the POs to properly slice the story so it could be delivered within the sprint and with quality. (And it only changed when we changed the Product Manager, one with the proper mindset.)
Learning points: The agile mindset is critical for having multiple teams coordinating the development of one single product. Much more than it is when you are working "stand-alone" in one team. With the right mindset, your team can learn and grow, can identify and fix its problems and issues, can learn to work as a team. When in doubt, go back to the manifesto and check out its fundamentals.
People have to work together. Real collaboration is a must.
When you have multiple teams building one cohesive product, you have to have coordination meetings in place to get the inter-team coordination flowing.
In our case, we used a "Scrum of Scrum"-like model, so every single day we used to run a meeting with all Scrum Masters, one support representative, some functional coordinators and myself, to walk through dependencies and inter-team issues. This was also a place where people could collaborate on other issues, like potential impacts of changes/refactoring, any problems the team were facing that the other teams might be/would be facing face as well.
The main point here was to have a place and time settled so the teams could talk to each other, building bridges to any future discussion.
Another thing we used to do was having one single sprint review meeting for all teams. At the end of the sprint, all teams reviewed their deliverables, demoing their products increments. At these reviews, all engineering group participate, as well as the product group, the support group and any other group/people that would like to. It was an open meeting, with an open discussion.
Learning points: When scaling, you need to have real collaboration. People must put in place specific meetings to discuss issues, share experiences and communicate whatever they want.
Someone has to be looking the overall product.
When you have one product per team, or just stand-alone products and teams, the PO — most of the time — has the autonomy and the power to decide on her own. But if you have multiple teams with multiple POs working on a single product, someone has to be the "master" PO. This individual needs to look all teams in a more holistic way, understanding the "puzzle" as a whole. The "master" PO should have the "global" product roadmap in mind, guaranteeing that each team backlog doesn't collide with one another and ultimately converging to the desired goal.
And this not only matter regarding features in the backlog. Sometimes you can have different teams implementing similar behaviours in different and discrepant ways. Just to find out you have 4 different ways to upload a file, or your panels and grids works in 3 different ways along the product. In our case, this role was played by the Product Manager and co-played by the Product Director.
Learning point: Have someone overseeing the whole product, so you can have a unique/cohesive product.
Having a single cadence makes things easier.
When you have multiple teams, the first thing you think of is to have all teams working somehow independently, so they can manage themselves loosely. But while it’s easily done when working on isolated products, it’s not that easy to manage when you have multiple teams contributing to a single product.
In our case, it would be a nightmare to let the teams decide on their delivery cadence. So we fixed the sprints lengths (2 weeks) and for some more mature teams, they were allowed to have shorter cycles, but still participating on the common sprint review.
I tried to push the teams for a shorter sprint cycle of 1 week, since the shorter the sprint, the easier it is to manage team interdependencies, but both the teams and the POs were constantly rejecting the idea, wrongly arguing it would make their work harder and with much more meetings (twice as much).
For several reasons we used to use the concept of release. So after 6–8 sprints we released the product to the market. All stories developed by all teams were properly integrated and extensively tested for the product release. At this point, we were able to check for major and minor issues and inconsistencies.
Learning point: Unless you have a very mature group, with no (or little) coupling, it is better to attain to a single cadence for governing all teams. The shorter the cadence, the easier it is to manage the whole process.
New ceremonies?!
In this context of multiple teams and one product, you have to add some ceremonies, revive some you have just forgot, or just scaled the ones you've already in place. I already discussed the daily "Scrum of Scrum"-like meeting. But this is not the only ceremony we used in our process. So, what were the other ceremonies?
:: Release Roadmap and Objectives: Just as you have the sprint backlog and the sprint objective, now we had a release roadmap and release objective covering ALL teams. It was analogous to the release roadmap for a single team, but the main difference was that in a multiple-team-one-product environment, this roadmap (covering all teams) covers a lot of interconnections and interdependencies among and between the teams.
:: Release Planning: At the beginning of each release we set apart some time for a release planning. The idea here was just to level everyone's understanding regarding the release objectives, trying to assess how risky and bold were the release goals. In this meeting, the teams performed some what-if scenarios in preparation for the planning. And also as a planning-only exercise the teams prepared a high-level backlog and a high-level technical planning. This backlog was presented to the other teams for discussion. This was a great and useful ceremony.
:: Release Review: At the end of the release, before the release planning, we performed a release review. This was a not an ordinary review, since we also reviewed the teams/group metrics, the achievement of the goals and objectives and any other high-level issue that needed to be reviewed.
::: Release Retrospective: At the end of the review and before the planning we had a "2-tier" retrospective meeting, first on team level, and then covering the whole group.
The 3 ceremonies above (Release Planning/Review/Retrospective) were conducted on an off-site 2-day meeting.
:: Customer Tickets Follow-Up: A bi-weekly meeting, with all engineers dedicated to customer tickets and their respective support staff. This allowed us to properly and timely manage the response to our customer tickets and customer related issues.
Learning point: When you are scaling Scrum, you also have to scale the ceremonies. If you are using Nexus, LeSS or SAFe, the framework will take care of those for you. If you are not, you need to pay attention to them yourself.
Cross function coordination is needed.
When you have one single product, the UI, the user flow, some common component behaviours and some set of features need to be standardised. So you need to have some kind of cross-functional coordination. In our case, we had some specific coordinators looking for different aspects of the product (QA for functional standards, design for UX and look & feel standards, mobile for our apps, and so on).
On a weekly basis, all coordinators seated together to track and manage their respective areas of concern and to do follow up with their peers.
Learning point: Cross-function coordination increases the chances of success. If you don't have it, you might be putting the overall quality of your product at risk and you might be wasting a lot of energy.
A high level goal setting framework helps everyone.
Since I joined the company, we started to use the OKR framework together with Scrum at the engineering group, initially with the coordinators. After 3 iterations, both the Objectives and the Key Results were already converging and helping the teams a lot. In our case, the most important aspect was the overall alignment. The next step would be to extend the adoption to the teams and to the product group as well. (For details here please check this presentation — in Portuguese only.)
Learning point: If you don’t have a clear and well-known goal, it’s pretty easy to get lost on your way. OKR is simple, lightweight and straight forward, but you can use any goal-setting framework you choose. Foursquare had a very good approach (they used to roadmap management, but you can use it for anything), called #Now, #Next, #Later.
Metrics are a must.
"You cannot manage what you do not measure" (Deming)
So you have to have your key metrics in place. Actually, every team must measure its owns KPIs (the ones agreed on a group level, the ones the teams believe make sense for them, and the ones agreed upon with the PO). In our case, we were short on this subject. We had some basic metrics regarding the support indicators, and the QA coordinator had some metrics regarding bugs. The teams? They had none… So we started to collect, consolidate and analyse a lot of KPIs. And the KPIs were really used to manage the teams (both at the team level and in the engineering group as a whole). If something could not be understood by the existing metrics, new ones were added (permanently or ad-hoc). But they were process (engineering) metrics.
Learning point: If you don’t have metrics in place, you are flying blind. You have to build you metrics and KPIs, identifying the ones that make sense in your particular case. And then you have to use them. Really use them.
Conclusion
Scaling agile from one single team to multiple independent teams is not that difficult, since most of the time you can manage the teams in isolation with no interdependencies with each other.
Scaling agile in a multiple-teams/single-product arrangement may place additional challenges in the organisation. But adding new and simple procedures, paying close attention to agile principles and establishing a common goal-setting framework (like OKR, for example) turns the challenges into a fun thing to work on.
Remember, you can use SAFe, LeSS, Nexus; but be prepared to change, to try new approaches until you find the one that is right for you.