The Case Against Stable Teams, Part 2

In The Case for Stable Teams, Part 1 , I wrote about stable teams as a way to create jelled teams. My guideline was that the longer it took for people to be useful in the team, the more you needed a stable team. Otherwise, the cost of changing membership is too high.

But what about non-stable teams? We’ve seen jelled teams—often “tiger” or “swat” teams—in organizations. They come together for some emergency or high urgency problem, they solve it, and they disband. And yet, they seem to be a jelled team.

Here’s what I’ve noticed about those teams:

The team has a high-urgency specific deliverable. People know exactly what they have to do and when the organization needs that deliverable. The team only works on that one deliverable. The team knows their purpose.
Everyone assumes each other person is part of the team because they have the skills to be there. They have sufficient functional skills and domain expertise (mastery) to be able to solve this problem. That helps the team members build respect early.
The team members focus on the work. The team members have autonomy to work as a team to solve this specific problem. Often, the team isn't bound by “we've always done it this way” ideas that can prevent a team from fixing this problem. As long as the team fixes this problem, and it's legal, the team can work any way they want.

Here's the story of one team:

A Very Important Customer (VIC) had a big problem. That meant Dan, the senior manager, had a big problem, too. Dan realized this was the most important work the company had right now. He asked Libby, a senior developer, to lead the fixing work. Libby said she would, as long as she had these other four people to work with her: Tristan for the UI, Sandy for the platform, Jack and Terry for the testing. Dan asked why these people? Libby trusted them.

Libby had worked with everyone except Terry before. She'd heard great things about Terry. In addition, Jack vouched for Terry. Libby understood everyone's capabilities, and she was sure they could work together.

Libby asked about the boundaries of the problem. She'd worked with other people from VIC in the past, and they sometimes liked to see what else they could get for “free.” She cautioned Dan about this stretching of requirements when he explained the problem to the team.

Dan explained the customer's importance and what he knew about the problem. The team asked him a few more questions, and then they started to work.

The team created several experiments to narrow down the possibilities for finding and fixing the problem. Libby spoke with the customer representative to clarify the problem when the team had questions. Libby managed the customer's expectations over several calls, once with Dan's help.

This team spent six days experimenting, creating more tests and trying different solutions. They knew they needed a real answer, not a half-baked solution.

The team members had questions for each other and the customer during the week. Jack and Terry taught Sandy a new testing approach, which Sandy crowed about during their lunches. Libby and Tristan experimented with different ways to prototype the UI fast, so the Customer could provide feedback.

They finished solving the problem on days seven through ten and delivered the solution. Libby and Dan checked with the VIC representative to verify she was happy. The team had a little retrospective, and a little celebration and then returned to their previous project teams. The customer was happy.

This team focused on the work. They trusted each other. They created and extended their initial feelings of safety as they continued to work together.

They were a jelled team even though they only worked together for a week.
They were a tiger team—they worked together to solve a specific problem and then disbanded.

In Part 3, I'll talk about the manager's role in creating effective teams.

All three newsletters:

Early Announcement of Johanna's New Book

My new book Create Your Successful Agile Project: Collaborate, Measure, Estimate, Deliver is in beta. That means we are combing through it for typos and anything that doesn't make sense. Yes, you can buy the ebook now.

Here's why I wrote the book: Every project and every team is unique. Your agile approach should reflect your uniqueness. And, yes, I have a chapter on teams and the interpersonal skills a team needs to be able to be a jelled team.

New to the Pragmatic Manager?

Are you new to the Pragmatic Manager newsletter? See previous issues.

Here are links you might find useful:
* My Books
* Workshops I offer
* Coaching
* Managing Product Development Blog
* Create an Adaptable Life

If you like the idea of romance between smart technical women and just-as-interesting men, I’m starting to write romance in my spare (!) time. See Johanna’s Fiction.

Till next time,
Johanna