In transforming my organization from Waterfall to Agile, one of my biggest challenges was moving from function-based teams to cross-functional, feature-based teams. After some research, I wasn't able to find much guidance, so I thought I would share my story for others looking to do the same.
The way that work had been done in the Waterfall world, for each new project, teams were formed based on the functional areas of the system that was required to change for the project. If a project required changes to the user interfaces and reports, web and reporting developers and QA were assigned. So instead of having one large team of engineers, I had several small teams of specialists.
Working by functional area created a series of problems. First, we couldn't scale because we were bottlenecked by specialists when there were spikes of projects that required a particular functional area. As a cost-conscious company, we had been focusing on resource use instead of work efficiency, so people were assigned to multiple projects to "maximize utilization." People were always busy, but project delivery times were completely unpredictable. This created a vicious cycle, as we never had time to cross-train because people were too busy. Teams were disbanded at the end of a project, so we were always ramping up new teams with different resources and not able to maintain stable throughput. If there were issues after a project delivery, working by functional area created additional problems: Team members were now scattered into new teams and had to be pulled off their current teams to work on old issues with the previous team.
Based on these issues, to transform to Agile, I set the following goals for resources:
- Create stable teams in which members stayed together and could develop a predictable velocity.
- Cross-train members and expand skill sets.
- Leave slack in the system for nonproject work, such as cross-training and production issues.
- Focus on dealing with idle work instead of idle workers.
- Improve morale and teamwork.
- Reserve subject matter experts (SMEs) to provide cross-training, coaching, mentoring, and architectural activities (so they would not be assigned to a team).
The first obstacle was to determine whom to assign to each team. I had approximately 120 team members, including ScrumMasters or project managers, product owners or business analysts, architects, developers, and QA testers. Our engineering ratio of developers to testers was approximately 3:2, and we had around one ScrumMaster and one product owner for every ten engineers. So I did some simple math and figured that we would have about 20 Scrum teams.
We set up a large meeting room, as follows, to determine how to best resource the teams:
- For each of the 20 Scrum teams, we set up a large sheet of paper on the walls around the room.
- We added an additional sheet for SMEs.
- On the table in the middle of the room we had a sticky note with the name of each team member and their functional area specialty.
- We had four colors of sticky notes, and each color represented a role: ScrumMaster, product owner, developer, and QA tester.
We then called together all the managers for each of the functional areas into the meeting room. Everyone was instructed to pick any team member they wanted from the table and assign them to a team. It didn't matter if they picked someone from their team or not. The goal was to staff each team with seven team members with varied skill sets, the goal being to create cross-functional teams. So off everyone went.
Because the managers knew their team members so well, as they picked names and assembled teams, they were able to discuss in real time how to balance strengths, weaknesses, experience, personalities, and skill sets. In 30 minutes, we had all the names assigned to teams.
Next, we gathered everyone and collectively reviewed the resourcing of each team to ensure that they were balanced. In doing so, we made some minor adjustments and shuffled a couple of team members around. We had to collapse a couple of teams because they were understaffed, and we moved those resources to other teams to strengthen them. We were completely done in under an hour!
We kept the team assignments secret to build up excitement around our entire Agile transformation. We scheduled a meeting with the entire staff to make the announcements. To make it fun, we purchased colored Mardi Gras-style beads and put together a slideshow with each team and their members. As we announced each team, we had managers toss beads of the same color to each member so that they could easily identify each other and assemble afterward.
Finally, each team was instructed to pick their own name and logo. We also asked the ScrumMasters to do some icebreaker activities. In random Daily Scrums, ScrumMasters asked a fourth question such as, "What's your favorite color?" or "Do you have any pets?" Teams began planning their own work events, such as group lunches, or they would announce life events such as birthdays, anniversaries, and births. The teams rapidly came together.
When teams were assigned projects, if they lacked experience in a particular functional area, they brought in an SME. The SME would provide cross-training and guidance, and help with things like design approach and code reviews. Cross-training items were added to the sprint backlog when this occurred. In most cases, the SME would not pull tasks to further cross-training. But in some cases, if requested, they would temporarily join a team to pull tasks and help teams meet their sprint goals.
As with all things Agile, we continued to inspect and adapt, and we made adjustments to teams as things changed. But in the end, we met all of our goals, including predictability, improved morale, and cross- training. The net result: After 18 months, our average project delivery cycle time improved by 300 percent. It worked.