No Group Is a Team on Day One

[article]
Activities to Help You Get Started
Summary:
Assembling a group of people and declaring them a team doesn’t make them one. Do you have the conditions necessary for the team to form? What activities have they completed to help them find an identity, their purpose, and how they’ll interact with each other?

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 [1] 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?

About the author

Don Gray's picture Don Gray

Don Gray’s goal to answer “What is the earliest indicator for a project’s status?” has led him to focus on such diverse topics as communication, personality types, team styles, systems thinking and human systems dynamics. Don’s varied interests and client experience provides a platform for helping clients introduce and work through change as they transition to agile development practices.  His blog can be found at www.donaldegray.com. Don helped create and co-Hosts the AYE Conference.

StickyMinds is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Oct 12
Nov 09
Nov 09