DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. 5 Big Issues When Scaling Scrum

5 Big Issues When Scaling Scrum

Sean Mchugh user avatar by
Sean Mchugh
·
Jan. 31, 13 · Interview
Like (0)
Save
Tweet
Share
28.36K Views

Join the DZone community and get the full member experience.

Join For Free
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.
scrum Sprint (software development) Scaling (geometry)

Published at DZone with permission of Sean Mchugh, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • Debugging Threads and Asynchronous Code
  • Cloud-Based Transportation Management System
  • Handling Virtual Threads
  • Explaining: MVP vs. PoC vs. Prototype

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: