As a manager, you may have mastered the scrum…but now you have a bigger project, and one team won’t be enough. When you’re trying to decide on the best technologies for your situation, here’s the first thing you need to do: Stop thinking about the technology.
Instead, ask yourself, what is your definition of scaling up? More importantly, what problem are you trying to solve? Rather than focusing on the specifics of software or tools, keep your focus on the results.
Scrum of Scrums (SoS), Large-scale Scrum (LeSS), and Scaled Agile Framework (SAFe) are three of the better-known approaches. Let’s see which methodology is best for you.
Scrum of Scrums is a technique that can help you scale Scrum up to large groups of up to a dozen people. Rather than increasing the size of each team, a Scrum of Scrums consists of a team member from each scrum who regularly attends the Scrum of Scrums to coordinate work. Through these “ambassadors," Scrum of Scrums can help plan for dependencies, solve communication problems that distributed teams face, clarify commitments to other team members, and identify and address other pain points.
The beauty of using Scrum of Scrums is that you don’t need any tools beyond the ones your Scrum team is already using. Ambassadors report their completions and next steps, as well as any barriers in their scheduled Scrum of Scrums meetings. Scrum of Scrums should not be handled like a status meeting reporting to a manager but instead a meeting of technical ambassadors reporting to each other…which is to say, solutions might require more negotiation.
A Scrum of Scrums might not be needed every day; two to three meetings per week is usually sufficient. Scrum of Scrum of Scrums (yes, I meant to write that) might be only once a week. It is best to start with frequent meetings and then later reduce the amount.
No time for a Scrum of Scrums? You can still synthesize cooperation between teams: Each team can monitor and prioritize which teams they need to synchronize with at any given point in time, then go and listen to the daily Scrums of those teams. This, of course, requires that teams agree on the schedules of the daily scrums so that this is possible. Still another option is to have a “town-hall”; an open meeting where all interested can share information.
LeSS, which is a framework for product development, is really two different Scrum frameworks, each focused on the whole and not the part. Global and “end-to-end” focus are perhaps the dominant problems to solve in scaling. These two approaches – which are basically single-team Scrum scaled up – are LeSS (up to eight teams of eight people each) and LeSS Huge (up to a few thousand people on one product, with more scaling elements introduced).
LeSS uses many of the same tools as a single team Scrum with some important differences: Although each team still holds its own daily Scrum, representatives may hold or attend town hall meetings or Scrum of Scrums to increase coordination.
In addition, there is only one sprint (that is, development push) and one product backlog (because it’s for a product, not a team). This means there is one definition of done for the product. This one definition clarifies what your stakeholders are trying to accomplish. Note that this definition is the same across all teams.
And with that, there is one overall product owner, rather than one per team. How can the product owner attend every meeting and keep up with every aspect of development? She can’t. But she can create product strategy and prioritization.
The Scaled Agile Framework®, or SAFe®, provides a recipe for adopting Agile at enterprise scale in a more structured way than Scrums of Scrums. SAFe has three levels: team, program, and portfolio. Individual teams work on Scrums with all of the tools needed to deliver product. A team in the SAFe approach is a self-contained group of eight to ten people that can deliver on its own, from requirements gathering and management to deployment and testing of software. Several such teams create a “release train”—a virtual organization that build and test iteratively— with new program level roles.
Higher up still is the the portfolio level, there is more attention to governance and finance; epics, strategy, and value streams are developed at this level.
Because delivery is tiered, this approach may appeal to larger organizations. However, even though this approach to scaling is established in the field, it’s not without its critics: Some argue that it focuses on iterating features and not iterating the whole product – which goes against the whole Agile approach.
How to begin
So how do you use these approaches, and which one do you pick? Your key focus should be “just enough process.” Otherwise, you undermine the whole point of being Agile.
Take a look at your organization and the project you're trying to deliver. Step back from tools and techniques and think instead about the core principles of scaling up: increasing collaboration within and among teams.
And remember, as you scale up, make sure the tools you use meet not only the Agile team’s needs but also the project leaders and top management’s needs for reporting, transparency, and accountability.
Looking for better reporting and transparency across your teams? Check out this OnDemand recording with Leadership Expert, Gordon Tredgold, "Creating a GPS for Your Projects. From Project Request to Success."