Dysfunctions of a Team

The scope of most software projects are such that at least a few people need to be involved to keep the whole thing together and moving forward. (Of course there are exceptions, but the need for people is probably true about most undertakings)

Computers, for the most part, do exactly what the software tells them to; people. . .uhm, not so much.

I’m going to borrow from a model in the book: The Five Dysfunctions of a Team and apply it to software ‘teams’. (The original model is formulated and applied to executive teams and is presented in the context of a ‘fable’. This is a short book, packaged and marketed to executives, but we shouldn’t hold that against it. The model makes sense to me, though I may be distorting things, so I encourage you to read it for yourself.)

The dysfunctions are modeled as a pyramid with five levels, with dysfunction at a lower level ensuring dysfunction on every higher level.

The dysfunctions from the foundation to the apex:

Absence of Trust

Fear of Conflict

Lack of Commitment

Avoidance of Accountability

Inattention to Results

A software development team is not just the ‘developers’, which have their own special taxonomies of dysfunction. The ‘team’ would include the business analysts/product managers, the testers, the developers and in some Agile Fantasy Land ™ maybe even the customer.

Each of the dysfunctions probably deserves to be illuminated, but for now you get the condensed version. . .

Without trust that everyone involved has good intentions, teams tend to break into silos and bunkers and hide anything that might be seen as a vulnerability from the untrusted. Therefore teams do not genuinely engage and fear healthy conflict. As a result of latent unresolved conflicts, the team will not truly commit. Psychology takes over and we do not effectively hold others accountable without their commitment. And finally no one is focused on overall results; we are too busy focusing on how to frame personal accomplishments in the best possible light, while the disasters all around us are some other’s failing. . .

Notice, there is no mention of software, but I’d venture that most people reading this with any experience in software have seen these dysfunctions ‘in the wild’. Let’s be honest, most of us have probably contributed to the dysfunction.

4 responses to “Dysfunctions of a Team”

[…] The book contends that trust is the foundation of teamwork and if a team doesn’t trust each other enough to personally expose weakness or raise concerns without fear of reprisal, then they are condemned to suffer from all the dysfunctions. […]

[…] I thought the most important dysfunction to address was trust, because it is the foundation of all the other dysfunctions. After a little reflection, I’m starting to think that you need at least as much focus on […]