After the Agile coaching group shut down at Yahoo!, I decided to take a chance at being an independent coach. I quickly found work with a network management group. The business unit consisted of over 70 people, mostly working in San Jose and Bangalore. The Vice President of the technology group wanted to “burn all the ships”, and hoped this no retreat attitude would help the team convert to Scrum within a quarter. I spent over nine months with the business unit.

Creating the Initial Teams

To begin Scrum, the managers created three large teams along architectural boundaries and HR reporting lines. Each team was around 15-20 people. Immediately, integration issues in the system and between the teams showed themselves. It was the norm that for one feature, at least one person from each of the teams would need to work on it. Stand-ups were taking a long time and I would see the same person in multiples.

Using Story Themes for Organizing Teams

I noticed that the Product Backlog was organized into themes and this gave me an idea. At the next planning meeting I tried an experiment. I wrote down each theme on a separate piece of paper. At Sprint planning I held one up and exclaimed, “If you work primarily in the area of the sign I’m holding, come stand over here.”. As people gathered, I handed them the sign, moved a few paces and held up the next piece of paper with another theme on it, repeating the process.

People collected in groups of two or three and as I got to the end of the list of themes I asked them to look around. Did they see any other groups and/or themes they worked with closely? People shuffled around a little and before long, we had six teams of around eight to ten people each.

There was one holdout group and once that was settled, we had a few people that still hadn’t decided where they belonged. Finding them a place required a little management intervention. I then asked each team to think of a name, so that we could continue Sprint planning using the new names for our new teams.

I asked the teams if we could try this experiment for a Sprint and if necessary, people could switch teams in the next Sprint. A balance was reached between steady, persistent teams who felt comfortable in the code, and the capability to move people around to share knowledge.

Benefits of the Team Restructuring

Within a quarter continuous integration was in place. Another quarter after that and each check-in produced a disk image. The image included the operating system, all necessary third party applications, and packaged code the team built, installed on an appliance, which was then rebooted. Within another quarter all tests passed with each build and unit tests covered over 90% of the code base.