Rich Hundhausen

Of the many teams I’ve met, most were practicing Scrum. Others were considering it. They all wanted to become more Agile. When asked if they were working as a team, they always answered in the affirmative. Each member of the team was busy doing something, and the team usually got something done. And they would stand up every day, too.

Great, but were they working as a team?

There are many ways to work as a team. Some ways are highly collaborative. Some maximize learning. Some minimize cycle time. Unfortunately, there are ways that are all about individual specializations and output. To the untrained eye, they can look like a harmonious team. However, they actually maximize the risk of not delivering, as today’s complexity requires combining skills and even cross-learning of skills to succeed.

Over the years, I started identifying and classifying the various styles of teamwork and assessing their impact on the collective.

There are four ways that are dysfunctional in terms of the ability to collectively deliver and to transcend being just a group of individuals:

Hoarding

After Sprint Planning, a Developer claims ownership of multiple Product Backlog items to do all the work on those items in isolation. Intra-team dependencies (such as knowledge) and external impediments get the Developer to cherry-pick among the selected items, ending the Sprint with all items open but nothing “Done.”

Hogging

After Sprint Planning, a Developer takes ownership of a single Product Backlog item to do all possible work, moves on to do the same with the next Product Backlog item, and so on. Dependencies and impediments are similar to hoarding, but the single-piece focus slightly increases transparency, reducing the risk of not getting the item Done.

Specializing

Developers work those tasks pertaining to their specialties on different Product Backlog items and “maximize” their specialization across all items. Dependencies are high but remain hidden until toward the end of the Sprint, when late integration greatly increases risk.

Generalizing

A Developer works a few different types of tasks. Not having all the skills required, the person will still start work on a new Product Backlog Item (PBI) when blocked. Dependencies may not be as high as specializing, but integration still occurs late, increasing risk.

Teams that start working in any of the following three ways enter the “Circle of Team Collaboration Goodness,” where mutual learning happens as an opportunity for professional development and is a must to reduce dependencies and risk:

Pairing

Two Developers co-create the same PBI, as a pair, potentially changing the pair composition in search of all expertise to get the item Done. Pairs may be part of a larger swarm on a single PBI.

Swarming

All Developers (alone or in pairs) work on a single PBI, doing whatever is required until the PBI is Done.

Mobbing

All Developers work on a single task of a single PBI until that PBI is Done. Like in swarming, there is no jumping or moving on before the PBI is Done.

I hope this helps you contemplate how your Development Team works. Where would you situate your team on their journey? What patterns have you observed emerging? How can you help the team move forward to become a highly collaborative team, rather than a group of individuals?