The agile training class for a newly formed team was almost complete. We’d covered values, practices, roles, the product backlog, done simulations teaching the Scrum process and I could see the end of training. A little team building activity, and we could start tomorrow with building the backlog, story sizing, then start the first sprint. Forging ahead, the team selected a name, came up with a list of team norms, and they became a team with me as their ScrumMaster.
Or did they?
Over the next few weeks, I noticed cracks appearing. One member tried to find ways to avoid the daily standup. Another member only checked in code toward the end of the sprint. Yet another happily worked on what he was assigned, but never volunteered to take tasks from the task board. At times, the entire team struggled to understand how its activities blended with and supported the activities of the other teams on the project.
There didn’t seem to be a unifying focus, something with which all the team members could identify. What could I have done differently?
Forming a Team
Over the years, I’ve seen teams formed many different ways. There’s the Five You process where the manager goes “You, you, you, you, and you. You’re now a team!” Often, these team members were selected because they were between projects, they possessed approximately the right skills, and it was time to get a new project started.
Matrixed teams form somewhat differently. Team members get assigned by skill level to projects. The greater (or rarer) your skill, the more teams you get assigned to on a part-time basis. This way, everyone has 100 percent of his time assigned to project work. I once met a QA “resource” (which in itself says a lot about the company) assigned to three Scrum teams. For some reason, he didn’t seem to get much done but go to meetings. Matrixed team assignments guarantees all projects get delivered in the maximum amount of time possible, if at all.
In the case of the team I worked with, the developers became a team because they all worked in the same office. I believe in collocation, but being together, in itself, doesn’t provide impetus to become a team. So what might?
What Makes a Team?
In The Wisdom of Teams  we find the conditions needed to exist for teams to form:
- A compelling work goal
- Interdependent work
- Stable membership
- Shared history
- Five to nine members
Interestingly, a compelling work goal often gets overlooked. The team had work to do, but I don’t believe “We’re part of an project that will save the company a bunch of money” constitutes a compelling work goal. Don’t get me wrong, helping the company save money is a good thing, but does it call forth the urge to slay dragons or at remove impediments from the development process?