This post is over 6 months old. Some details, especially technical, may have changed.

Teams or People?

A team is much more than a group of people thrown together for the period of a project. This is quite common in a utilisation based business model where downtime is viewed, on the balance sheets at least, as money wasted. I'd call that myopic.

Putting aside other arguments for a moment (downtime is quite often good for allowing motivated people to learn and grow) lets think about Tuckman's Stages of Group Development.

Half Baked Tuckmans Model

Tuckmans model suggests that teams go through various stages of development, as denoted above. During these phases various things happen,

  • Forming - the team comes together shares their history and begins to develop an understanding of the problem to be solved.
  • Storming - after the gentle introduction people begin finding their place in the team. Dominant parties fight for control, less dominant sniff out their leaders and the power struggle kicks off.
  • Norming - the power struggle is over and people understand their place in the team. Less impediments occur through communication.
  • Performing - the team has gelled and is working effectively, everyone is in the role they need to be and everyone trusts each other.

There is a final stage - Adjourning where the team, as a collective whole, part ways - but I'll get to that later.

What does the y-axis in this pseudo-graph represent? I guess the obvious answer is team productivity but given the many factors that can affect team productivity/efficacy this isn't a realistic metric. No, the y-axis in this case reflects the teams focus on their goal of delivering the solution. In this situation it makes sense that a "team" become a staple unit of delivery vs the old resource rumble of "whoever is free". Short-lived teams of randomly selected individuals are always going to be operating at sub-optimal levels due to the very nature of team dynamics. Now here's the rub - more often than not this performance is nigh on impossible to quantify. In fact if "people as units of delivery" has been a thing for a while you'll find people making excuses for inefficiencies by front-loading of estimates. What happens then in sales and bids, how can a company who's estimates are derived due to sub-optimal team output remain competitive but keep their process the same? One dubious tactic would be for sales team gently massaging numbers and rates to make them more appealing. This makes the entire delivery process from sales to final delivery of a solution highly inefficient and pressured and we haven't even touched on the evils of potential overselling and micromanaging!

So - the team a a unit of delivery makes sense IMHO, but it's not without it's problems. Moving to a team-based model requires a significant jump in company culture, accounting, sales and, if you'll let me use the word, resourcing. There are potentially huge visible risks in long stretches of downtime for teams. Arguably though large visible, almost predictable risks, are significantly better than unquantifiable consistent loses right? At least you can mitigate them.

Adjourning

A team can't stay a team forever. People get hit buses or worse get bored and a long lived team that refuses to change is simply another silo of knowledge that methodologies like agile try and crack open.

But adjouring the team isn't about throwing the core team to the wind. Too much team churn and you end up back a square one. Too little team churn and you've got the silo problem. Team members should be rotated to allow knowledge to propagate (inwards and outwards from the original teams perspective). However this clearly brings its own problems (is a person who's constantly rotated really ever part of a team) and the balance needs to be struck over time.

Spotify is decent example for this sort of cross-team knowledge sharing and I'd recommend checking out Scaling Agile @ Spotify

The team as a unit of delivery is certainly more suited to product based companies or large, long running projects because it feels more natural. In a services based outfit or consultancy house being able to ship people about at will is easier but thats not to say its actually beneficial. While it brings its own unique challenges team-based resourcing can allow organisations and project to greater realise their true potential.

Published in Agile on April 07, 2013