Is your SCRUM team too big?

How big is too big? Some people say you can never have it too big, but in this case, it is.

I'm talking about team size. The team that I am currently working on supporting a large eCommerce portal, has 18 members. We also practice SCRUM. This is a big no-no in SCRUM teams as it becomes difficult to manage. These were the signs that our SCRUM teams were not lean and agile:

1. Standup meetings

Our standups were taking 30 minutes or longer. Team members were not engaged as it takes a while to get to their turn to update. People were bringing in laptops to do "work." People stopped coming because they had more important things to do. Daily updates were sent via email to be "more efficient." The team was SCREAMING that the team was too large, but it takes a skilled scrum master to listen.

2. Sprint planning

Planning was taking two days, sometimes longer. Many tasks were added to the sprint after start of sprint. Many of these could've been identified if we had performed better planning upfront in discussing stories and breaking them down to bite size pieces. Many members did not have the information they required to start working on the tasks before sprint start.

3. Team Dynamics

Our testers did not fully understand the stories in the current sprint or even which developer were working on them. The developers, business analysts and testers were not working in concert to deliver a feature.

4. Sprint Status: Burndown

With every sprint, we have problems burning down to zero. Of course many of these problems lie with the quality of the requirements, but it goes back to team dynamics where the business analyst, developer and tester were not working in concert to deliver a feature. By having the three roles in close communication during the feature development, information is more quickly shared and know-how is transferred.

As what Jesse Fewell has thought during my SCRUM product owner training, SCRUM is a diagnostic tool. SCRUM will not solve our problems, but rather explicitly display it. It just takes the team to listen and bite the bitter pill to improve.

We did listen and bit the bitter pill and took the decision to split the team. In the spirit of empowerment, the manager set the stage for why we need to split and promptly left the room. It was then left to the team to self-organize in to two teams. Typically a manager would make the decision, as in "you go here, you go over there, you I don't need." By giving us the opportunity to self organize, we discussed in length about the pro and cons, how to address the cons and it resulted in a better understanding of the WHY and the HOW.

All this without having a manager in the room.