Scaling Agile: When to Build a Scrum of Scrums
“Involvement increases empowerment at scale,” — agile coach Georg Fasching.
Agile software development arose to identify new ways for problem solving and product development in self-organizing, cross-functional teams, emphasizing faster, continuous delivery and improvement. The Scrum methodology or framework is a popular way of fostering communication in this agile ideology by having weekly or sometimes biweekly measurable objectives set, which are reflected upon in daily stand-up or Scrum meetings, where the Scrum Master (imagine the person in rugby with the ball) works to keep the team focused on figuring out what they need to do to complete that week’s tasks as a team.
What began as a way for dot-com and software startups to plan and deliver more effectively with smaller, bootstrapped teams is now spreading to all sorts of product development and to companies of all sizes. The ideal size for a Scrum team is typically between three and nine members. But what happens as your company scales, can Scrum scale with it? Can agile scale? Is a Scrum of Scrums—where a series of Scrum teams are connected together and linked by a series of Scrum Masters that have to communicate across teams and functions—a reasonable possibility?
How can a company grow and still remain agile? Or how can a company that’s already established embrace the dramatic and often disruptive changes that Scrum brings? That was just what happened when we brought four agile coaches and Scrum Masters together for a Blab video podcast about when to scale agile and how debating whether or not a Scrum of Scrums is a reasonable solution.
Scaling agile seems to be the topic of debate for many managers, but for the four change agents speaking in the webinar, management can often be the barrier to change, particularly when they are forcing agile frameworks as solutions on teams before even getting their side of the story. This piece looks to share some of the insight brought by four coaches in four different countries, working with cross-organization agile scaling.
Click here to listen to the conversation in its entirety, or read on below for a summary:
How Complex Do You Want Your Agile Scaling to Be?
The larger the organization, typically the older it is and the more bureaucracy it has, so the proposed solution is often to add more teams and more bureaucracy rather than cutting back as they should have done. “Having documentation 20 pages long and nobody reads them—it doesn’t make any sense,” said agile coach Tomas Kejzlar who has coached at many large-scale organizations that said they wanted to go “agile” without really knowing what that meant.
Agile management coach and author Jason Little said that when people hear the word “scale,” they immediately relate it with a large change in governance and framework. “What is behind the feeling that we need to consciously do something to scale versus downplay needing that,” continued the founder of Lean Change Management, who cosponsored the webinar with Management 3.0.
Addressing teams from the bottom up and then facilitating the conversation between those teams makes all the difference.
Kejzlar witnessed a major Czech bank automatically choose the SAFe framework simply because it is the most popular, a mistake witnessed by all the participants at one point or another. SAFe or Scaled Agile Framework is perhaps the first major Scrum and agile framework created for enterprises and focuses on three levels of scale: team, program and portfolio, with a focus on business strategy.
But sometimes the most popular method doesn’t work for everyone. Indeed, often, when companies are looking to fix a problem, they often look for the most complicated solution, when simplification is often the way. Little says that complications arise when managers and coaches don’t have an understanding where the teams you are trying to scale intersect with the rest of the organization. He says you need to “basically have conversations: How does that intersection happen and what do we need to do?”
Little went on to say that you need to take agile, scrum and frameworks in general out of first discussions, instead more broadly asking:
- Where does your work come from?
- Who gets it when you’re done with it?
- What restrictions do you have?
The focus has to be on figuring out how to simplify things so teams can coordinate their own work, and to look for how to standardize processes to increase stability in teams. It’s all about simplifying things so teams can coordinate their work.
When Should You Build a Scrum of Scrums
Little says that if you just want to bring three different Scrum teams together, then just start by getting them in a room together. Kejzlar concurred that for smaller teams it is easier to bring a smaller number of teams into a room and allow them to build a shared backlog together.
Another participant in the discussion, Joshua Briggs is working now to restructure an organization with ten teams down five Scrum Masters with two teams each. Currently, the organization puts more technical people in charge of the more technical teams, but they are trying to break that up for each Scrum Master to have one content and one tech team, as a way “to try to combine the organization instead of it splitting up into two.” It’s a Scrum of Scrum, but they are revisiting how to pull more value out of the teams.
Fasching is currently helping the British Ministry of Justice scale, struggling with bureaucratically rich legacy systems and processes, including six-week release cycles with 15 pages of reference documentation. In order for them to reach continuous integration, something had to change, including moving to one-week release cycles and significantly shorter updates.
Fasching said his job is about “exposing the dysfunction within the organization so that the team can act quickly.” For him, the moment to scale is when you find that a product is growing at a rate that one team can’t handle all of the features. One way teams are preparing for this on a technical side is by moving to microservices and containers which are easier to break off, but that means a change in team structure too, since, following Conway’s Law, the team will inevitably restructure along with the technology.
Scaling Agile Is about Facilitating Better Communication
In any relationship, when something is wrong, communication often fails. Almost always, it’s the managers that decide there is a problem and the solution for it, but being a change agent is about bringing the people on the teams together and facilitating the conversation.
“It would be very hard to make a Scrum of Scrums or any scaling organization work if there is no communication between the teams,” Kejzlar said.
Little recommends starting any exploration by first checking for physical boundaries that are keeping teams that are often working on the same product from actually talking to each other and to sharing task boards—participants shared war stories about how much one door can stifle communication. But then you have to look for management’s invisible boundaries that allow teams to forget they can still communicate. He sees external change agents playing the important role of reminding folks of their ability to communicate. He said sometimes that involves creating a Scrum of Scrums while others just have Scrum Masters meeting for coffee weekly.
It’s all about getting to the practice that works, not just looking for an additional practice to implement.
As Fasching pointed out, enforcing a framework that no one wants will simply never take hold, so you need to constantly be asking team members what they want. “If the nature of two teams are somehow aligned, they need to be encouraged to talk to each other somehow, which could be as simple as somebody from one team joining the standup from another team, and they just take turns.”
But if different teams are working on the same product, a Scrum of Scrums can often be a logical solution.
For Agile Development, Sometimes LeSS Is More Than SAFe
In the end, the first rule of journalism— KISS: Keep It Simple, Stupid—certainly seems to fit the bill for scaling agile too.
Kejzler says, “Look at where we are and what we are actually trying to achieve there” because the simplest process can often be the answer.
So, are there frameworks that work? The four different agile coaches seemed to all be fans of the Large Scale Scrum framework or LeSS because they said says it has you scale by descaling and by removing managers and decreasing emphasis on specialization. It’s another framework built to bring Scrum to larger teams, but built on the idea that you can get “More with LeSS.” This framework looks to address the problem that, by maintaining the same people and trying to fit these pegs into different shaped holes, you perpetuate the same problems you started with, which implies you have to get rid of or demote a large number of people.
But of course, as Little, who specializes in coaching companies of more than 40,000 members, pointed out, the solution isn’t always easy because it involves considering laying off people or removing stacks. And then you need to determine whose decision it is to take away an entire organizational arm, or to retrain and move them within the company. (Hint: An external consultant usually isn’t given that power.) Little pointed to how this can be a struggle because “There’s somebody here who is in charge of printing out the headers of Kanban boards,” pointing to the battle against large organizations’ emphasis on really particular and often excessive specialization.
Fasching agreed on LeSS because it is 70 percent organizational change and 30 percent scaling, but admits that in some countries, like France, the worker protection makes it very challenging, plus no one wants to be responsible for eliminating jobs. “It would be tempting to just create work for those people but if we are true change agents, we must fight that desire to create work because they’re not creating value and then we’re not creating value.”
He looks at the SAFe framework as “like a paint job,” where the organization continues in the same way but with new titles. He says it can be OK as a starting point but only when it’s then followed by the Large Scale Scrum Framework with a focus on continuous improvement, which, of course, brings difficult conversations with it. But, he says that if you are not changing anything for years, by definition, you’re not agile.
Echoing Fasching, Briggs said, “My experience with SAFe is that it just allows that managerial override of the agile process, and I saw that really get in the way of any kind of productivity.” He actually witnessed product teams maintaining secret backlogs to work around the SAFe framework.
Of course, as Kejzler said, control is why traditional management tends to like SAFe and its traditional structure and presentation. “You don’t see that in the LESS framework because LESS is about descaling the organization, making it simpler. [But] safe is about keeping the hierarchy and somehow making it work.”
Fasching pointed out that that LeSS isn’t the perfect solution for all organizations looking to scale agile because it doesn’t come with important aspects like portfolio project management.
“Any one framework is never the answer,” he said.
In the end, usually, a combination of frameworks or tools plus some personalization is what will work for any given team, especially one at a large scale. Of course, Little warns that sometimes organizations give the framework more importance than the problem at hand, which just, in turn, complicates it all again. He says that once you recognize that maybe a Scrum of Scrums can be a solution, it’s best to just try it out for a month and then revisit to see if it worked. “And that might actually help you figure out that maybe that was a different problem we were trying to solve.”
Just don’t over-simplify to the point that you can demotivate. Briggs reminds us that you can’t over-standardize to a point that teams lose their sense of fun and identity, particularly in areas that are already working. And Fasching says that team health and happiness is something that needs to be a priority and you need to then perhaps measuring that among teams will vary.
The moral of the story (or webinar) is:
- Talk to your teams.
- Have them talk to each other.
- Get a feel for their problems.
- Experiment with solutions.
- Revisit. Revise. Repeat.
