Agile Zone is brought to you in partnership with:

Sean McHugh is a Scrum Master at Axosoft who works with customers who are new to the scrum methodology. He also helps customer's who are experienced with scrum, but are beginning to implement a software solution for their scrum teams. He shares some of his thoughts and experiences at Sean is a DZone MVB and is not an employee of DZone and has posted 14 posts at DZone. You can read more from them at their website. View Full User Profile

5 Big Issues When Scaling Scrum

  • submit to reddit
I think it's a safe bet to say that if you're reading this blog then there is a good chance that you're at least interested in Scrum. The problem is that for many organizations, even the basic concepts in Scrum begin to break down as we scale it up to the entire organization. Imagine a daily stand-up when the development team consists of hundreds of developers and even more testers. These problems are not small and very often can mean the difference between a successful project or a horrific failure. So what are some of the bigger issues at hand? Glad you asked.

1) Testing is done outside of the Scrum Team:
I'm not talking about unit testing (although those should be part of your definition of done). I mean functional testing, done by a testing professional. If you "finish" up a backlog item, run your unit tests, mark it as complete in the sprint and then ship it off to the separate testing group, then you can't really consider it complete until it comes back. The solution here is to embed at least one tester with each scrum team so they can get immediate feedback within the sprint on the completion of a backlog item.

2) Team size is too large:

Amazon has a rule that any team that can eat more than two pizzas for lunch is too large. Now I'm not going to argue the logic behind that argument but that would allow for me and one other similar sized person and 'm not sure that's what they're getting at. The general rule of thumb that I've come across is that a Scrum Team (including testers) should be about 7 people give or take 2. Meaning that 10 people is starting to get a bit large and 4 people (while better than none) might benefit from at least one more. How does that help me with my team of 100 devs? Well obviously we're not going to fire 93 people and expect the results we're looking for. But we will break the team up into smaller teams of preferably 7 give or take a few developers.

3) The daily standup (and other meetings) are conducted en masse: 
Each individual team will conduct it's own sprint planning, it's own daily stand-ups and it's own retrospectives. From there it falls to the Scrum Master to roll all of this up to the meta-team level to combine into the total project as a whole. For instance the small teams all do their daily standups and and get back to work, the various Scrum Masters (or team leads) all get together for a quick standup to briefly talk about their teams progress, issues and goals for the day. The individual team performs their retrospective and identifies some areas for improvement or things to try in the next sprint and the Scrum Master performs a total retrospective with the other Scrum Masters to discuss the total sprint. And so on and so on.
4) Nobody can get ahold of the product owner: 
What happens when the Scrum team is working on a story and discovers that they don't know what a form should look like? That story stops until the Product Owner responds. Scale this up to 100 or so developers and you've got yourself a problem. The solution can be a little tricky, ultimately you'll want a single product to make big/heavy decisions about the product but spread him too thin and his ability to respond will suffer causing the team to wait for answers (which is never good). In large organizations you may find it easier to have a single Product Owner and several smaller Product Owners to assist the Scrum with their inevitable questions.

5) The Scrum Master has no idea what's going on:
Having a single Scrum Master for an entire organization is a bit like asking a single waiter to handle every table in a busy restaurant. The Scrum Master's job is ultimately to serve the needs of the Scrum Team, spread that out among multiple Scrum teams and that service will suffer along with the teams performance. Ideally there should be one (and only one) Scrum Master for every team. They don't need any special certifications or advanced skills, just a basic grounding in Scrum, good old fashioned common sense and a good grasp of what the Scrum Master does all day.

These are just some general guidelines and issues that I've seen with large groups adopting Scrum. There's certainly other issues that you'll run into and different solutions that you'll try. Let me know about your experience in the comments, I always love being exposed to new problems and new solutions.
Published at DZone with permission of Sean Mchugh, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Jilles Van Gurp replied on Thu, 2013/01/31 - 2:46am

One of the most surreal meetings I've ever been in was a sprint planning for a 150 people, multi national product team broken down into a dozen plus teams. That means 12 scrum masters, 12 product owners, about four super product owners, a program manager, misc scrum consultants, senior management, 120 developers and a shitload of post its.

In one room. For two days. 

Corporate madness. This was one of the least agile work situations I've ever been in. Scrum bureaucracy had taken over and there was no room for any form of intelligent decision making whatsoever. Worse than waterfall.

Scrum works best in teams so small that you could get away without any process at all. That's what the two pizza rule is about. If you are two to three people, you don't need much process. Any semi structured approach towards reflecting a bit on what is needed and combining that with general engineering skills will go a long way. 

So scrum doesn't scale down and it doesn't scale up. If you are stuck in the middle, breaking the team up might be more effective. If you are a lot of people, chances are you don't actually need most of them. That 150 people company above did a lot of work but accomplished very little.

Jeff Devis replied on Fri, 2013/02/01 - 2:48am

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.