Slow Blue Camera

I recently gave this tech talk, basically "meat & potatoes" agile, for the team I'd just started working with.  There was a bit of extra emphasis on continuous integration, as at the time I was persuading on of the projects to set up a build box to generate their deliverables (as opposed to crafting on somone's desktop).

During talks, I sometimes worry about going of on tangents and diluting the message. So this time experimented with baking two tangents into the talk itself.  And it kind of worked!

The two tangents were:

• IT projects are (relative to other projects) often very expensive, and IT people well compensated (relative to other people, who do _real_ work, like teachers, journalists, firefighters, etc.).  We need to respect this.  One way to respect this is to work hard to deliver actual value to the customer as quickly as possible.  This is a lot of what agile is about.
• I make a mild joke, contrasting the points of view where new stuff is considered hip & innovative, and old stuff antiquated and out-moded, and the point of view where new stuff is crazy and untested, and old stuff is classic and reliable.  I try to use the joke to suggest that keep perspective, avoiding the hype cycle, as well as excessive caution, to choose your practices with pragmatism in mind.  With agile crossing its first decade, there's no shortage of dogmatism, so this is important as well.

--

Discussing "hierarchy" in relation to agile teams is generally pretty difficult.  Agile teams tend to pride themselves on being flat, self-organizing, and via all-in retrospectives democratic, though perhaps with a "benevolent dictator" or two to move things along.  But within any group, there are implicit hierarchies, and often, power mist.

But when roles and responsibilities get unclear, does it really matter?  I've always thought it was important, but something you could work out over time.  I also thought that as the team became more familiar with each other, things would get better.  I'm not so sure about this now.

A recent working paper from Harvard Business School, Disagreement about the Team's Status Hierarchy: An Insidious Obstacle to Coordination and Performance, "used survey data from a longitudinal field study of 89 consulting and accounting teams from a Big Four firm to test a model of how teams experience status disagreement over time", indicates that not only does this disparity a significant impact on performance, team familiarity actually makes the problem worse.

Keep in mind, we're not talking about massive bunfights for control, boardroom battles, or territorial pissing matches here:

"... [team members] sometimes arrive at different assessments of each other’s relative rankings. In a cross-functional team, for instance, designers might bestow status according to the creativity of members’ contributions whereas engineers might bestow status to those who demonstrate quantitative excellence; these team members’ perceptions of the status hierarchy might therefore differ significantly. Although members might generally behave as if there were a consensus on status hierarchy, especially in situations in which social norms are highly regarded, they might actually disagree about it."

As the bulk of the study's data is survey-based, they found that even if the team just felt unclear on hierarchy, that was enough to cause significant issues:

"One novel finding here is that difference in team members’ perceptions of the status hierarchy is itself enough to hamper team coordination and generate task conflict; the difference in perception doesn’t have to generate blatant status rivalries —or even be recognized at all—in order to cause trouble. While prior research has examined the effects of overt contests ... team members in our study were not necessarily even aware that disagreement existed. Our qualitative evidence suggests, in fact, that most team members assumed that everyone on their team did agree on 'where they stood on the totem pole,' even in teams where status disagreement was actually high. After hearing his team’s actual status disagreement score, one AuditCo manager initially expressed deep surprise; two weeks later, however, he telephoned us to say that he’d been doing a 'mental post-mortem' on the team’s processes. 'I can’t stop thinking about this disagreement [that existed within our team] – it was like an insidious obstacle to performance. It was the unknown unknown that pulled us down.'"

Surprisingly, the damage apparently gets worse with teams that know each other well, or "high familiarity" teams.  These teams showed status disagreement worsened coordination and task conflict problems.  So you can't rely on it simply working itself out over time as the team gets to know one another, it just gets worse!

I think its often a cherished myth that development teams are flat and structure free.  It is important to identify the hierarchy your team has, even if its a shallow one, and work out everyones role and responsibilities within it in an open manner.  This might lead to some disagreement but, like continuous integration, better to get that sorted out early in the process than to find yourself with an "insidious obstacle" further down the road!