So. In so many of my roles, the first diagnosis I observe in a software product delivery group is simply this: they aren't a team. It's been so consistent, I think it's worth sharing.

tl;dr

If a group of individuals aren't collaborating as a team, any efforts at agility or organizational improvement are wasted.

What will you see?

When you encounter a new team, what do you see? Each developer diligently working to deliver their task? Or a hubbub of conversation punctuated by time spent coding what they'd discussed?

And the planning meeting will immediately prove the point. If the story breakdown includes the person who will be tasked with that story, that's an indicator. If the scrum master (or team lead or manager) finishes the planning meeting with a list of task assignments for each individual for this sprint... that's an indicator.

What's wrong with that?

I often hear comments like "well, what's wrong with that? everyone's doing what they're best at." Or "just let me do this" or "Brad just likes to be left alone" or worse "we have to let Ann handle that API because she's the only one who gets it." "I'm working on a pet project because I finished my tasks for the sprint"

At the end of the sprint, the only comments are how the individual's experience turned out. You don't hear any shared accounts of what happened.

You can probably hear my responses, but... here we go.

The Team IS the value

What we miss when a group of individual developers each code alone is leverage.

It's the collaborations of the group that bring insights no individual coder can imagine alone.

The team's ability to deliver is at risk when only one person understands how to do a given part of the work.

It's only as a team, together, that we develop the consistency in understanding problems ('estimation' discussions) and in shared coding on the solution to gain some predictability.

Your next step

Start a conversation.

In every sprint planning, look to the group for estimates on every story. Use the time to bring new members up to the point that every person understands what will be delivered.

Celebrate every win as a group. Minimize the celebration of individual "rock star" contributions as grand standing.

Adopt a "least qualified person" strategy for each task. This ensures they'll need to reach out, to collaborate, to get the task done. Everyone is a newbie at something so use that to encourage a learning attitude.

If a change (adding a person, losing someone) doesn't affect the group's delivery, you're not a team.

epilogue

Again, my imposter syndrome is screaming "everyone knows this!" but my experience tells me this is the first failure point almost everywhere I've tried to contribute to a software product delivery organization.

How about you? Do you always see groups working as functioning teams? Do you see any of these warning signs in teams you help?