Developer Tribes
I recently finished an interesting book called Tribal Leadership. The book is full of insights about how people behave in groups and what it takes to lead them.
Tribes
Humans naturally organize into small groups (tribes). These tribes behave in specific and predictable ways (stages) best described by a short sentence representing the dominant sentiment of the tribe:
- Stage 1: “Life sucks”
- Stage 2: “My life sucks”
- Stage 3: “I’m great (and you’re not)”
- Stage 4: “We’re great”
- Stage 5: “Life’s great”
As it turns out, most organizations operate in Stage 3. People in these tribes focus on individual achievements, cooperate reluctantly, and see others within the organization as adversarial and incompetent.
At Stage 4, the focus changes to cooperation and common goals. Teamwork is natural, your colleagues are not the enemy (your competitors are), and everyone is united by common values.
Authors make a big deal about moving organizations to Stage 4 (and beyond), which they see it as critical to sustaining business success. In their view, most problems facing today’s companies are too complex to be tackled by individuals, even talented ones.
Reading descriptions of these two stages, I couldn’t help but think about how different software development methodologies fit these tribal Stages.
Software Development Tribes
In a typical waterfall shop, people of similarly skilled individuals (i.e. BAs, Devs, QAs) are grouped into small tribes. Each one works on their slice of the project, usually independently of others. Their goals and success metrics are typically independent.
In a typical agile shop, people of diverse skills are grouped into small tribes. Each tribe works on the entire project, highly dependent on others. Their goals and success metrics are shared.
If you consider the development organization as a whole, it’s not too difficult to notice that agile methodologies are much better suited to create a Stage 4 environment. For example, people in Stage 3 tribes tend to consider others incompetent, which happens constantly in waterfall teams. Why is that?
Well, imagine a dev who gets a big spec full of “The system shall..“s from some nameless BA. As she starts implementing, reality of the project starts colliding with the vision outlined in those requirements. It turns out that things were missed, or not thought through, or were just wrong based on what we now know. Is it really such a huge surprise that she starts thinking of the BA who wrote them as incompetent, no matter how skilled that BA actually is?
On the other hand, agile team devs get stories relevant today, based on the latest information the team has access to. Aside from that, BAs aren’t some nameless evil doers, they’re guys literally sitting next to you, talking to you daily. All that makes it a lot harder to think of them as incompetent.
Final Thought
There is certainly no guarantee that agile teams will function as Stage 4 tribes. It’s just that they’re better suited to promote such a culture and, by extension, deliver good software.