Does Scrum makes sense for 12 members in a Development Team?

Question

Our team is consist of 12 people who work on one product. While Scrum says team size should be 3-9 people. So, should we not use Scrum only because of team size? We probably can't split the team, because we are mostly working on different tasks or stories related to one product. So although those stories and tasks are inter-connected in some way, they are not that all tasks are belonging to one story.

The problem right now is that our Daily Scrum is not 10 minutes meeting but it takes around 30-35 minutes which I don't think is efficient use of everyone's time. And not every detail is related to every member of team. But sometimes it is useful in a way that everyone member has an idea of what is going on in the team and if there is dependency then everyone is there to resolve it, as different stories are sometime inter-connected or probably someone on other irrelevant story can answer some question to resolve dependency.

So, what do you suggest? Should we keep the Daily Scrum as it is? Or should we make smaller teams in some way? I don't know how we can split it. There are mobile developers, back-end developers, QA, Devops guy, and BI guy. So how should we split it? Or we should keep doing it in the same way but with some changes you can suggest?

Answer 1

If your standup is taking 30-35 minutes, even with 12 people, the problem isn't the number of people, but what you're using the standup for. Standup is not for status updates. It is for blocker identification. Let's go over the traditional flow of someone's standup pitch:

• What I did yesterday - I say this so you are aware of changes that were made that might cause you conflict. People with experience in this area can say "People tend to get blocked by ___ so watch out or ask for help if needed."
• What I'm going to do today - I say this so we can identify ahead of time that we're going to have a conflict. And again, experienced people can pre-identify blockers in that area.
• My blockers are - This is the most important area of the standup, and yet I find people use it the least. They almost always say "No blockers" and then proceed to accidentally leak out that they're being blocked.

So if people are taking 3 minutes to go over that on average then either they're super blocked by a ton of stuff and you should sit down with them and hammer it out offline, or you're just doing it wrong. If there's more than one or two followup questions, tell them to take it offline.

Answer 2

It's important to recognize that Scrum does not say that a team must be between 3 and 9 individuals. The Scrum Guide says that Scrum is most effective with a Development Team size of between 3 and 9 people. A Scrum Team (including the Product Owner and Scrum Master) would have an ideal size of 4-11. Development Teams that are smaller than 3 people or larger than 9 people may experience some issues with the rules that Scrum has laid out - for smaller teams, it may add unnecessary overhead in the way the events and artifacts are managed; for larger teams, you may not have sufficient time within the timeboxes and the additional communication channels may slow the team down.

But that doesn't address the issue - you have a team of 12, which is larger than what Scrum suggests.

Ideally, you would split the team. Because Scrum teams are self-organizing, the team would determine how to best split the team.

There are two guides that take Scrum and scale it - Nexus (from Ken Schwaber and Scrum.org) and Scrum@Scale (from Jeff Sutherland and Scrum, Inc.). There are also a number of other scaled agile frameworks, but those may be a bit heavyweight at this point in time. Even Nexus and Scrum@Scale are designed for cases of 3 or more teams, but some of the concepts are still relevant.

At this point in time, you really only need to split the Development Team. The common guidance is that you have one Product Owner for each Product Backlog and there is only one Product Backlog for a particular product. Since you only have one Product, you only need one Product Backlog and therefore one Product Owner. The Scrum Master can, in theory, also facilitate both teams but that would almost certainly make the Scrum Master a full-time role.

How you split the team is up to the team, although the business should probably have input. Scrum does have some rules about the makeup of the team, primarily that each Development Team needs to have all of the skills necessary to create a Product Increment. That is, a team should be able to take a Product Backlog Item and get it to Done without needing to go outside of the team.

After you split the team, the result of each Sprint should be a fully integrated and Done Increment.

But let's say that you can't split the team. There are still some other things that you can do.

First, try to better enforce the timeboxes of events. A Daily Scrum is not a status meeting - people don't need to get into the details of their work. Focus on things of interest to the group (for example, finishing something that was impeding someone else) or on current impediments that will prevent the team from achieving the goal. The same holds true for the other events - focus on their intents and be disciplined about getting to the purpose.

Second, work on dependency management when ordering the Product Backlog and in Sprint Planning. Try to keep everyone active and engaged. Don't have individuals begin work that is blocked because other people are working on other things. This is wasteful (in the Lean sense of the word). At the same time, keep trying to deliver visible value to the stakeholders at the end of every Sprint.

Third, reduce the size of the people involved in the different Scrum Events. For example, limit the attendees of the Daily Scrum to the Development Team only. If there are people in supporting roles, you can invite them as silent observers (and enforce the silent observer rules) and ask them to leave if they interfere with the event. For events like Sprint Planning and Backlog Grooming, invite only the people who are required. Some good examples would be that roles like UX Designer and Business Analyst would be supporting the Product Owner - only the Product Owner would need to attend the events with the team (and can delegate if unavailable for any reason). This may help reduce the number of people and make meetings and events flow more smoothly.

Finally, begin to cross-train. If your organization continues to grow, you will almost certainly have to either change your process as Scrum will be unsuitable for such a large team or split your team. If you go down the path of splitting the team, you're going to want to make sure that teams have the right skills on that future. Also consider this if you hire new people into the organization.

Answer 3

Thomas Owens has a good Answer, and I just wanted to expand upon it.

The goal of the Scrum Master is to inform the Scrum Team of how Scrum works, and then to get out of the way. You (I am assuming you are the Scrum Master) should make sure the Team is well-educated about the whys for the problems (and, if you like, you can propose potential solutions) you foresee, but then ultimately leave not only how, but also if to solve those problems up to the Team.

• Problem: The Daily Scrum is taking too long.
  • Potential solution: Add a smaller time-box.
• Problem: The Daily Scrum is not time-boxed. By not setting a hard time limit on the duration of the Daily Scrum, the business is exposed to the risk of the time inflating to the point of waste.
  • Potential solution:Add a time-box.
• Problem: During the Daily Scrum, not all members are engaged in every discussion.
  • Potential solution: When a Team member is not engaged with the current discussion, s/he will raise her hand. Once X people have raised their hands, the discussion is tabled for further discussion after the meeting amongst only those involved/interested.
• Problem: The Team size is too large.
  • Potential solution: Split the Team.
• Problem: It is difficult to split the Team because there is only one product and many of the stories are interdependent
  • Potential solution: Better prioritization/grooming of the backlog (as Thomas suggests) to reduce dependencies of concurrent stories.
• Problem: It is difficult to split the Team as there is only one QA and only one Devops and only one BI expert. /this inhibits the split Teams from becoming cross-functional.
  • Potential solution: Cross-training, as Thomas suggests.
  • Potential solution: Hire more staff.
  • Potential solution: Have the underrepresented positions belonging to both Teams, sharing their time between the two.

The Team may also come up with more problems, solutions, or problems with solutions than presented here, once discussion begins. Bring it up in the Retrospective meeting and then let the Team come to an agreed-upon solution themselves.

Answer 4

The last Scrum team I was a part of was easily 20 members, and our daily standups rarely exceeded 15 minutes. The scrum was for a quick status. What did I work on / finish yeasterday, what am I working on today, what roadblocks do I have. Anything that the whole team wasn't interested in was tabled for a side discussion after the standup. This worked well. We all found out where we were, what people were working on, and what the problems were. Solutions to problems were not discussed at the standup unless it was on the order of "Joe, can you take care of that". Frequently we uncovered things that needed to be discussed further. These things generated more focused discussions for interested parties after the standup.

Answer 5

Quick answer is the team size is not the main problem here. The problem is what people are doing at the stand up.

You should not split the team just to get the "right" headcount.

The team should focus on the main objectives of stand up which is to ensure the team knows what to do and can do it effectively (no blockers, etc). The means to that are the following questions:

1. What have I done yesterday (actually least important)
2. What I will do today
3. What are problems (the most important part)
   • here it is also important to keep the problem solving out of the meeting if it takes too much time

Scrum Master should be addressing this as definitely this is an impediment for the team and I assume there are might be some other related problems.