Tag Archives: Team

Dysfunction: Inattention to Results

Never mistake motion for action.

– Ernest Hemingway

The final dysfunction from The Five Dysfunctions of a Team is Inattention to Results. This ultimate team dysfunction occurs when members of the team value something other than the collective goals.

This dysfunction doesn’t mean they have lives and balance outside the context of the company (that’s another post. . .) but that the members of the team are focused on highlighting their own achievements regardless of the overall outcome.

You can smell this dysfunction when individuals or groups start to point to everything they did right, even when the overall project is flailing. (maybe especially when it is flailing)

“Product management did such a good job of creating requirements, its those lousy developers that didn’t understand, I mean just look at this pretty document. Don’t you love the font . . .”

“I wrote the code exactly to the spec, not that those idiot clients and product managers know what they want anyway . . . I am a programming god.”

Have you ever participated in either side of that conversation? Played Not-my-fault-I-am-teh-awesome hot potato?

(Quality Assurance gets blamed for everything, cause as everyone knows ‘kwalytee’ starts with the last people who touched the software, duh. . . You do have QA, right?)

There is nothing so useless as doing efficiently that which should not be done at all.

– Peter Drucker

Inattention to Results is most damaging to an organization when it becomes institutionalized processes. When people stop trying to do the best thing and just make sure they go through the checklist.

When things go South, the checklist becomes a buzzword compliant shield, an Agile security blanket.

When I first read the model, 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 results, if not more. Sure you need to work on trust, because if you don’t, eventually the rest of the dysfunctions grow to be monstrous, but ‘winning’ gives you the opportunity to work through a lot of trust issues. Especially, if working on trust (. . .conflict, commitment, accountability. . .) is an explicit goal.

This is all well and dandy, but what does that mean? How can I use this?

There is not a formula that you can just plug in and solve this problem. On some level, this is all about culture. On another, an individual, not on top of the food chain, recognizing these dysfunctions has to navigate between Scylla and Charybdis. One becomes faced with the prospect of being at odds with the perception of management, watching and suffering the dysfunctional culture, or finding something else to pay the mortgage.

(eh, maybe that’s why the book’s target audience is executive teams. . .)

Insanity: doing the same thing over and over again and expecting different results.

– Albert Einstein

what to do?

Reflect and adjust my friend. . . Reflect and Adjust

add to del.icio.us :: Add to Blinkslist :: add to furl :: Digg it :: add to ma.gnolia :: Stumble It! :: add to simpy :: seed the vine :: :: :: TailRank :: post to facebook


Dysfunction: Lack of Commitment

He who is most slow in making a promise is the most faithful in performance of it.

-Jean-Jacques Rousseau

What is commitment?

When it comes to software development, there are two reasonable definitions:

  • the act of binding yourself to a course of action
  • confinement to a mental institution or hospital

And sometimes there will be great difficulty telling the difference.

In the ideal world, the perfectly architectured codebase has neat little modules with perfectly separated concerns, all perfectly tested of course. Santa Claus, Big Foot and the Leprechauns all love it, pay tons of money for it and are waiting patiently for the next version.

In the reality of software projects I have participated in directly, indirectly, discussed with colleagues or watched from afar, there are often competing internal and external pressures involving time, money, quality, ideology and last but not least ego. That isn’t to say that all these projects went poorly, it is just to recognize the pressures.

So what does all that have to do with commitment?

The Five Dysfunctions of a Team claims that unless the concerns of team members are not voiced and resolved through healthy conflict, the team will lack commitment to a clear course of action.

The original model targets executive decision making, which is paramount obviously.

But… effectively communicating these higher level objectives and the implications they will have in a software product or process in and among the development team, then being willing and able to adjust to the feedback may have an even bigger impact on a software company’s success in the long run.

That doesn’t mean all decisions require consensus to get commitment, but that dissenting voices are an opportunity to reevaluate, clarify and optimize. Simply exercising that opportunity can create an incredible sense of team duty in those who offered the dissent, even if they still disagree.

This is going to be a re-occurring theme, but if you are a software company, and you don’t have smart passionate people building your software, just give up now.

Seriously. . .

Now that there are smart passionate people building the software in a culture of trust and healthy conflict, get everyone unified and committed and you’re pretty much set.

With all the internal and external pressures, the success of a project and often a company hang in the balance.

add to del.icio.us :: Add to Blinkslist :: add to furl :: Digg it :: add to ma.gnolia :: Stumble It! :: add to simpy :: seed the vine :: :: :: TailRank :: post to facebook

Dysfunction: Absence of Trust

“I’m not upset that you lied to me, I’m upset that from now on I can’t believe you”

– Friedrich Nietzsche

Trust is a funny thing.

The absence of trust described in The Five Dysfunctions of a Team is essentially the opposite of what Alistair Cockburn refers to as ‘Personal Safety’. Trust is a ‘prediction of reliance’ that your peers intentions are good and any vulnerabilities will not be used against you.

An ‘absence of trust’ can appear to take other forms in software development, for example, ‘we don’t trust those incompetent mother #$%@&ers in product management/engineering/quality assurance’, but I’m going stick with the model in the book for now. (Maybe you’ll get two bonus dysfunctions: ‘Absence of Faith’ and ‘Absence of Competence’, but I digress.)

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.

How many times have you seen a programmer spend hours, maybe even days, banging away at some problem that the person sitting ten feet away knows cold?

How many time have you endured the strategic conversation about what can and can’t be shared with another team?

How many times have you bit your tongue watching what comes into the version control repository?

Why does this happen? The smug pedantic lesson from someone who learned from banging his own head. The firestorm that happened when information was divulged. The vacant stares and shrugs because the code ‘works’. The seeds of mistrust are planted as a defense mechanism to some unpleasant experience.

The basis of trust is truth. If everyone can focus on the truth, then trust becomes a non issue.

The truth is some people know things you don’t. The truth is you know some things too. The truth is the best thing for the team is to share your knowledge. Ironically, the best thing for the team is to also share your ignorance. The truth is you should try not to be smug when enlightening your team. The truth is you should probably not take things personally when someone is trying to teach you something.

Without the truth, how can you make decisions? Sometimes the truth sucks, would you rather have it dressed up in buzz wordy power points? Is that going to fix anything?

Without trust, a team will waste an incredible amount of time and energy managing their interactions. Without trust, a team will be reluctant to offer or ask for assistance. Without trust, a team will have low morale and unwanted turnover.

What about your team?

add to del.icio.us :: Add to Blinkslist :: add to furl :: Digg it :: add to ma.gnolia :: Stumble It! :: add to simpy :: seed the vine :: :: :: TailRank :: post to facebook

Dysfunctions of a Team

So. . . where were we. Oh, yeah, yeah, software development. . .

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.

The first step is admitting you have a problem.

add to del.icio.us :: Add to Blinkslist :: add to furl :: Digg it :: add to ma.gnolia :: Stumble It! :: add to simpy :: seed the vine :: :: :: TailRank :: post to facebook

%d bloggers like this: