5 Big Issues When Scaling Scrum
DZone 's Guide to
5 Big Issues When Scaling Scrum
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.
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.
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.
Like This Article? Read More From DZone
Topics:
Published at DZone with permission of Sean Mchugh , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}