Cobbled Together Scrum Teams

I’ve seen cobbled together Scrum teams for years, but I realized just the other day that I’ve never written about them. So, now I will…

What are they?

They are an anti-pattern and are a team in-name-only. That is, there is no collaboration because everyone works on a unique product, application, service, or platform.

I often see this anti-pattern in Ops organizations where the overall company is adopting Scrum. The leadership team feels compelled to form teams everywhere—out of individuals with very different skill-sets, roles, and application-level responsibilities.

For example, if it’s an IT administration and support group, probably every member of the group has 1-10 applications or platforms that they are individually supporting. With little to no overlap in skills or area ownership across team members.

Indicators

• During the daily Scrum, nobody really listens or engages with anyone else. They’re literally working on individual, unrelated work, so there is no need for it.

• During sprint planning, everyone individually plans their serial work. The sprint goal is a cobbled-together mess of individual goals.

• The product backlog is composed of individually “owned”, disparate items.

• A sprint review is a lonely place, where individuals present their work efforts with no connection between people.

• Pairing or swarming around work is nearly impossible.

• Oh, and the retrospectives are equally disengaged as every other event.

Often the team resists actively participating as a Scrum team because it simply doesn’t make sense to them.

Why do it?

It seems like the primary reason is that the organization is adopting Scrum, so everyone needs to be ON a Scrum team.

And this begs the question of what to do instead? I’d say the most congruent, honest, and humane thing you could do is disband the Scrum team. Or, look for better alignments across the work so that there is a chance for meaningful collaboration.

Kanban is usually a much better fit for this type of work anyway, so you could try that as a better approach.

Wrapping Up

My advice is to not do this to your teams. It’s demoralizing and nearly inhumane to force a group of individuals to be on a team when there is no logical reason or work alignment for them. It just creates confusion. And it also wastes a lot of time in team members going through the motions of the Scrum events.

I’d encourage you all to look around your organization for the symptoms I listed above. If you see them, chances are you have cobbled together Scrum teams. And if you do, please uncobble them.

About the Author

Bob Galen is an agile practitioner, trainer & coach based in Cary, NC. In this role, he helps guide companies and teams in their pragmatic adoption and organizational shift towards Scrum and other agile methodologies and practices. He is a Principal Agile Coach at Vaco Agile, a leading business agility transformation company. He is also President and Head Coach at RGCG a boutique agile coaching firm. Bob regularly speaks at international conferences and professional groups on topics related to software development, project management, software testing, and team leadership.