The Team at Service1st

In a huge reversal of ordinary management practices, Scrum makes the team responsible for managing development activities. Traditionally, the project manager tells the team what to do and manages its work. In Scrum, however, the team selects the work that it will do during each Sprint. After that initial selection is made, it is up to the team to figure out how to do the work at hand. The team decides how to turn the selected requirements into an increment of potentially shippable product functionality. The team devises its own tasks and figures out who will do them.

The pressure inherent in a 30-day Sprint, the commitment the team members make to each other to accomplish something, and the principles of self- organization and cross-functional responsibilities all help the team successfully fulfill this responsibility. The team unfailingly rises to the occasion and manages itself. When anyone outside the team tries to tell the team what to do, more damage than good usually results. I don’t know why Scrum’s self-organization works so well, but that hardly matters. After all, I know of hundreds of successful Scrum projects encompassing thousands of successful Sprints.

The Situation at Service1st

Service1st is a medium-size vendor of customer service software with a large number of domestic and international customers. Service1st’s products are well- regarded in the industry, with a solid release at least once a year. The company’s managers had decided that they wanted some developers to begin working on the next release of the company’s software while the rest of the developers wrapped up the current release. A team was formed of people with the appropriate skills who weren’t needed for the current release. Seventeen people, including engineering and testing leads, were on this team. At first, the managers used PERT and Gantt charts to direct the team’s efforts. But the company had decided that it would be switching all of its development over to Scrum, and so this team made the change as well.

The Team in Action

I conducted a Quickstart exercise with the team. This intensive two-day session teaches the team members Scrum practices and gets the team’s first Sprint underway. The training part of Quickstart went well. But when I got to the first part of the Sprint planning meeting, things started to disintegrate. The room was overcrowded: 17 team members were huddled around a small conference table, and interested parties formed a ring behind them. The room was so crowded that the more aggressive team members questioned and collaborated with the Product Owner while the more passive team members withdrew from the process. By the time I had moved on to the second part of the Sprint planning meeting, in which the team defines its Sprint Backlog, only the more aggressive team members were involved. I interrupted the more active participants several times to call on some of the quieter team members. I asked them what they would be working on. I made sure they knew that nothing feels worse than getting up in a Daily Scrum and saying that you haven’t been doing anything and that you’re not really involved with the project. Although my intentions were good, I only ended up making the quieter members of the team feel worse when I made this observation.

The team was simply too large. Optimally, a team should include seven people. During the Sprint planning meeting of a team of seven people, the team members lean forward, interact, collaborate, look each other in the eye, and form a plan of action. The 17-person team had found a way to do this by excluding the 10 less active members. Seven people were planning the Sprint, but the other 10 were sitting out the process. What could I do? I felt it was too late to reconstitute the team, so I decided to let things proceed—I would see what happened.

Several days later, I was attending this team’s Daily Scrum. Much to my surprise, everyone was reporting about work accomplished and work planned. Of course, the Daily Scrum took 20 minutes with that many people, but it was an active, lively session, and the team members all seemed to be engaged in their work. I asked the team members to meet with me after the Daily Scrum. At that point, they explained that they had decided the managers had been mistaken when it created such a large team. They didn’t want to confront their managers on the issue, figuring that, in its wisdom, the management team had a reason for assigning such a large number to the development team. But the original team simply wasn’t functioning, and the Sprint wasn’t getting under way. So the team decided to break itself into four subteams, each with three to five members. The engineering and testing leads helped formulate these subteams and divided the work to minimize coupling and maximize cohesion. These leads took responsibility for resolving any dependencies among team members as work progressed. The leads were part of the team that committed to the work, so their actions were part of the self-organization.

I’ve believed in the power of a self-organizing team, but this team was especially impressive. It had organized itself into an optimum grouping of team members and found a way to resolve its dependencies. If a third party had tried to devise such a complicated scheme, it would have taken days and been very difficult to explain to all of the parties involved. But when the team tackled the problem collectively, it was able to cut up the problem quickly into manageable chunks.

The Team’s Value

A team member pulled me aside later and told me that the key to the team’s successful reorganization was my discussion about management responsibilities. I had told them that the team was responsible for managing itself and had full authority to do anything to meet the Sprint goal within the guidelines, standards, and conventions of the organization and of Scrum. The team had fully committed to the Sprint goal, and it had simply tried to figure out how it could meet that goal. No one had told the team that it wasn’t allowed to reorganize, so it went ahead and did so.