Collection of individuals versus teams

- Do you have a team? Or a collection of individuals? The first time that I was asked this question, it was a light bulb moment for me. I had never really considered that you could have a group of people with a common skillset who are all working kind of towards the same goals, and have them not be a team. Understanding this nuance between a group and a team has been really critical to building an agile culture at my organization. Okay, so what's the difference? Linda Hill and Kent Lineback developed this definition. Quote, a team is a group of people who do collective work and are mutually committed to a common team purpose and challenging goals related to that purpose, end quote. They also emphasize that collective work and mutual commitment are the key characteristics. Turning a collection of individuals into a team is no easy task. But the Agile Fluency Model, developed by Diana Larsen and James Shore, helps provide a road map from being a collection of individuals to a high performing agile team. In this model, the idea of fluency, which Larsen and Shore define as routine, skillful ease, even when under pressure, is used as a way to move through each of the model's various zones. The first zone is focusing. Teams work together on working together, and delivering business value rather than just checking off the tasks that they are assigned. The next zone is delivering. Teams are able to release low-defect software at will and get really good at capturing value and removing blockers quickly. The third zone is optimizing. In this zone, teams are nimble and responsive to change. Business experts join the team full time, and wait time drops significantly. The final zone, strengthening, isn't one that all teams achieve. In this zone, teams work across their organization and sometimes across the industry, to help elevate the effectiveness of others. As the agile manifesto states, team organizing works best when individual members have a say rather than just mandates coming down from some sort of management ivory tower. And this is where Heidi Helfand's work around dynamic reteaming comes in really handy. Helfand identifies five dynamic reteaming patterns to help teams identify how to form and reform as demands shift. The first type is isolation, where a team is intentionally set aside from other groups and given complete process freedom and the autonomy to develop their own way of working. This is typically used for emergency situations, and usually lasts for just a limited period of time. The one by one pattern focuses on adding one new team member to an existing team, and this one's really useful for integrating new members into an existing organization. When a team gets too big, the grow and split pattern mimics kind of cell division, and teams split into two different groups. This can also go the other way, too. Sometimes it's beneficial to merge more than one team together. And finally, switching is a pattern that helps teams distribute knowledge and it seeds fresh perspectives. Ensuring your team is more than just a group is a critical step towards building an agile culture at your organization.