Scaling Scrum - What Works

January 5, 2013 — Posted by Al Shalloway

There was a question on Agile and Lean Software Development Linked in group.  I thought I’d turn my answer into a blog.  Here’s the question:

"Is traditional project management an option to scale up scrum? Scrum recommends the scrum of scrums as the way to deliver complex and/or large projects. From personal experience I see PRINCE2 or PMI as a better option to manage project areas that are not covered in the scrum framework (Risk, Change, Procurement)"

I think there are better approaches than either of the ones mentioned.  When discussing scaling I like to see what has worked and what hasn't.  Let’s me first discuss Scrum of Scrums – a method that has a very poor track record for scaling Scrum, then a couple of comments about PMI (I’m afraid I don’t know PRINCE2) and then look at three approach that have a solid track record – or at least have been one of the methods used by most of the companies who have successfully scaled Agile or Scrum.

In a nutshell, I state my opinion that scaling Scrum will only work with the creation of a high-level holistic context within which teams can work.  Scrum of Scrums takes a bottom up approach and therefore hasn't worked well.  Traditional PM approaches are not consistent enough with Agile.  I have seen three methods that have worked: CEO mandate of Agile, Scaled Agile Framework, and Lean Product Development flow.  

Before looking at these issues, let’s recognize that there are different levels of complexity involved in scaling. First, there is the low complexity situation.  This is when there is a dedicated stakeholder, projects are independent of each other and there are well defined project objectives and priorities. A medium complexity situation is where there are multiple team projects within an organization, multiple stakeholders, exist, there are enterprise release impacts of the projects and teams are given business requirements requiring further discovery.  Finally, you have high complexity organizations where project impact multiple development organizations, new technology is being used, there are external dependencies, and multiple stakeholders with competing priorities are involved.  The more complex a situation you are in, the more difficult the challenge of scaling.  

Now, let’s look at Scrum of Scrums (SoS). The theory behind SoS is based on the fractal nature of organizations.  That is, a multi-team product could be considered a team of teams.  You can take this structure all the way to the top.  However, what is overlooked is that a team comprised of members from different teams works considerably different than the way a normal team of individuals, working on one thing work.  In other words, how a team that works together every day on a project (e.g., a Scrum team) is quite different than a collection of folks from different teams (e.g., a Scrum of Scrums).  This insight is the key to scaling Scrum – so I’ll discuss this a little before going on to what works.

First of all, let’s be clear there are two different uses of Scrum of Scrums.  One is for coordination – that is, keeping different teams informed of what each other is doing.  The SoS works reasonably well as a vehicle for information sharing. However, using Scrum of Scrums to scale requires the SoS team to make decisions together.  This is considerably more difficult when they have different goals, different motivations and different ways of being evaluated.  In low complexity situations this is enough – just keeping independent teams informed.  In medium and high complexity situations, however, this is not enough. This is likely the reason that SoS has a dismal track record in scaling Scrum at larger organizations. 

Very often when I say things like this I get accused of “bashing Scrum” or something similar. This is not what I am doing.  Telling someone they should not use a screw driver’s handle as a hammer is not bashing screw drivers, it’s describing where something works and where it doesn’t.  What usually doesn’t happen, however, is discussing the issue (which I am very happy to do).  In any event, I have been a standing request for case studies where Scrum of Scrums worked to align teams and make actionable decisions where the organization wasn't already a highly functional organization.  To date, I have had no one give me a case study where SoS was used to guide scaling Scrum where Lean wasn’t also used to create the context within which SoS was working. I’m not saying Scrum of Scrums isn’t a useful tool, I’ve neither seen nor heard of cases where it has been a good guiding method for scaling. 

We can learn from the challenges of Scrum of Scrums to guide successful scaled Agility to understand what we must do.  I would suggest the missing piece of SoS is that it requires a successfully aligned group within which to work.  If you don’t have this, SoS won’t help much get it for you.

Before going on to what I have seen work, let me make a comment about PMI.  I suggest that one thing traditional project managements add that many in the Agile community have challenges with is the creation of a big picture.  In other words, taking an holistic, big picture view can often solve many challenges.  If you can bind this big picture view with an Agile implementation, it may prove useful. However, I would suggest there are better ways – which I will now briefly discuss.

In my 14 years of Agile experience and about 10 doing (or in the early years I should say, attempting to do it) at scale, I can say that the issue isn’t so much what to do as it is how do you get folks aligned on it (if you want more on this, see my blog People Are Complex, Software Development Isn’t).  Every success at scaling Agile that I am aware of (and there are many I am not) has used one of three methods:

  • Leadership from the top
  • Scaled Agile Framework
  • Lean-flow

I’ll talk about each of these a little bit to illustrate what I mean about what is necessary to scale Agile.

Leadership From The Top.  One of the most ballyhooed successful scaled Agile implementations is Salesforce.  The success here, however, was more due to CEO mandating that Scrum would be used throughout the organization.  In other words, it was mandated that Scrum was going to be used.  He set up the context within which all teams had to work.  Scrum was then implemented within this context.  It is important to recognize neither Scrum nor SoS created this context.

Scaled Agile Framework.  The Scaled Agile Framework (pronounced “SAFe”) is an interactive knowledge base for implementing agile practices at enterprise scale.  This model of agile adoption has been elaborated primarily in Dean Leffingwell’s books Agile Software Requirements: Lean Requirements for Teams Programs and the Enterprise (2011) and Scaling Software Agility: Best Practices for Large Enterprises, (2007) and his scalingsoftwareagilityblog.com. It has been successfully applied in programs of only 50-100 people, and in enterprises employing thousands of software developers

In a nutshell, SAFeTM creates a high-level, holistic framework within which teams can work.  By creating a high view of how to decide what to work on as well as a framework within which it can be implemented, Agile at scale can be achieved.

Lean-Flow. Lean flow has best been described in Don Reinertsen’s The Principles of Product Development Flow.  At Net Objectives we’ve used these principles as described in our Lean-Agile Roadmap. We have seen others, such as Ken Power of Cisco, use similar principles with great success.

The thing these three approaches have in common is that they create a high-level vision of what is needed to take place along with a consensus on how to get there.  By creating a high-level, holistic context within which Scrum (or Kanban) teams can work together well.

If you are looking to scale Scrum, I’d suggest looking into one of these three methods.

If you are having challenges scaling Agile, please drop me a note.  Net Objectives is one of the top 2-3 organizations that have helped large organizations scale Agile. We'd love to help you and I'm always happy to have a conversation with someone to help them out.

 

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Comments

Alan:
While I am by no means a "Scrum Purist", nevertheless I think you've missed discussing significant details to support your contention that "Scrum of Scrums" does not work for scaling agile.
Perhaps this is a definitional disagreement. What **exactly** do you mean by "Scaling Scrum"? If you mean, as I'd infer from your conclusion re scaling at Salesforce, that "all team members involved in producing product use it", OK, then I'd agree - for this example (although we don't know if they **also** used an SOS approach to do the actual scaling after this dictate by the CEO). However, if that **is** what you meant, I do not think that reflects a common understanding of what it means to "Scale Scrum".
NOTE: You do touch on the ambiguity of this meaning yourself when you state that one **use** of SOS is: "One is for coordination – that is, keeping different teams informed of what each other is doing. The SoS works reasonably well as a vehicle for information sharing."
Indeed. I've seen separate Scrum teams - each focused on individual "feature sets" for one monolithic product build, that use the SOS approach quite well to coordinate loosely-coupled dependencies as well as overall architectural/design approaches among those feature sets.
So - do you then further define "scaling scrum" to mean some very specific things beyond this? For Example: perhaps use of Scrum for a monolithic product build that is **tightly** coupled - i.e., hard to separate out features for discreet 5-9 people scrum teams to work on?
Bottom Line: without knowing exactly how it is you define "scaling scrum" and/or the specifics of the "other" (i.e., apart from coordination) use you attribute to this term, I don't think you've made an effective argument against its ineffectiveness.

By scaling Scrum I mean using Scrum across the organization.  Scrum is relatively straightforward to scale when the teams are independent of each other.  But even there, many organizations find that the real challenge is getting business to align on what is most important.  Scrum of Scrums is a useful tool in many situations.  It just isn't very useful to actually guide the decision points across multiple teams with different incentives. 

What we find is that Scrum is very useful in some situations and not others.  That scaling Scrum has different degrees of challenge depending upon the level of complexity of the organization.  However, what is needed is a conversation about what works and when. Let me know if this helps or if you want more.

My account has around 250 team size, with 23 Scrum Teams.
These Scrum Teams are dependent each other such a way that some part of one team's User Story would need to be developed by multiple Scrum Teams. During release planning, we identify the dependencies and create User Stories/Tasks for other teams.

The issues are:
- Challenges in resolving the dependencies. And Dependencies identified during the Sprint
- Lack of buy in from a few senior management silos. The release management is not aligning to the Scrum process. The Product Management at times shy away from their responsibilities.

A few these would need stronger support from Senior Management and formal trainings. But, as a Corporate the PMO, Release Management teams exists to assist the development teams. Will the Scaled Scrum (that Ken is taking forward) or the SAFe would suit in these kind of corporates?

Ken has been proposing an approach to scaling scrum that has a poor track record. Scaling Scrum requires a more holistic view to achieve. After taking on that view one can get scaled Scrum to work, but Scrum won't get you there. A team-centric view is limited. I have been claiming Scrum-of-Scrums doesn't work & have been asking for counter examples to that claim for years - with none being presented to me. THe few times someone says they do it they are really doing the equivalent of the product coordination team (Scrum of POs) that we talked about years ago in our book Lean-Agile Software Development. Peer-to-peer will not get people to figure out what to be building on in most organizations. Ironically, the case that Jeff Sutherland has been talking about recently demonstrating Scrum at scale had an intervention by myself teaching them Lean. After that they were able to do scaled Scrum well. A Lean perspective definitely helps.

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban