Tag Archives: Dysfunction

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

Advertisements

Dysfunction: Avoidance of Accountability

The ancient Romans had a tradition: whenever one of their engineers constructed an arch, as the capstone was hoisted into place, the engineer assumed accountability for his work in the most profound way possible: he stood under the arch.

Back to The Five Dysfunctions of a Team, so we have built up Trust, Conflict and Commitment. What do we need now?

Accountable: subject to the obligation to report, explain, or justify something; responsible; answerable.

In the model from the book, the avoidance of accountability is a psychological byproduct of the underlying dysfunctions of the team. Without firm commitments, after healthy disagreements are addressed, there is a tendency to not hold people accountable. We have a hard time holding people accountable, when we know they never really committed.

Ok. . . uhm, and?

How many of you have witnessed(participated in) the following scenario?

  • Incredible pressure to deliver a product/feature
  • Developers are hacking their little hearts out (very few tests being written, of course)
  • Quality Assurance is testing whatever they can see flying over the wall (with little or no prior knowledge of what it will be, bless their little hearts)
  • Product Management is doing whatever they do (anything but looking at what is actually being developed)
  • Daily stand ups where no problems are mentioned
  • We are so Agile, yay

Features delivered are a disaster. . . PMs are freaking out, Devs are indignant, QA is whimpering in the corner. What happens next? Rinse and Repeat. . . WTF?!??

I believe one of the fundamental principles of all Agile methods is ‘Reflect and Adjust‘. The built in adjustment is only going to help your team if it isn’t used as an excuse to ‘just do better next time’.

It is not only what we do, but also what we do not do, for which we are accountable.

– Molier

That doesn’t mean I’d advocate command and control shock and awe style, that just puts everyone into ‘cover your donkey’ mode and totally destroys the foundation of trust.

Honestly, Good Product Management is HARD. Good development is a creative endeavor that ebbs and flows. Good Quality Assurance is an acquired skill. All of these pieces are heavily dependent on each other.

Holding each other accountable doesn’t have to be antagonistic, but it does have to be honest. (truth, remember)

Brutally honest… Shit happens, but it doesn’t have to happen all the time.

Around the time of Caesar, there was a European tribe that, when the assembly horn blew, always killed the last warrior to reach his assigned place, and no one enjoyed fighting this tribe.

Don’t settle for mediocre, for yourself or for your organization.

Some people can’t handle ‘Truth’, and that is the seed for every other dysfunction.

Change your ‘organization’, or. . . change ‘your’ organization.

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: Fear of Conflict

Truth springs from argument amongst friends…

-David Hume

The ‘fear’ of conflict from The Five Dysfunctions of a Team manifests in teams that have protocols or cultures that steer the group away from conflict as a ‘bad’ thing. Ironically, open conflict can be a positive optimization mechanism.

I know what you are thinking, ‘We’re not afraid of conflict, we’re conflicting all the time.’ Open mean spirited ad hominem attacks are obviously dysfunctional, but maybe Patrick Lencioni’s publisher didn’t think the book should be called, ‘The Five Dysfunctions of a Team That Aren’t Totally Obvious’.

Here’s where things get interesting. . . and there might be a fine line, but if a team can truly conflict with passion, and even frustration, where the sole purpose is producing the best possible solution, they will produce a better solution in less time.

Conflict can never really be avoided. Attempting to avoid conflict is ensuring that there is no true resolution and the latent conflicts will just compound and fester. Eventually, the suppression creates fissures in the team and back-channel us-against-them style back-biting. Even more energy and creativity is lost when the key decisions that were made, without resolving conflicts, result in half hearted actions.

Of course, none of the benefit of open conflict are possible without ‘Trust’.

Where all think alike, no one thinks very much.

– Walter Lippmann

If you want to build good software, you have to start with the premise that your team is made up of creative smart people, or else you have already lost. The type of people that build really good software, also tend to have passion and opinions. Those opinions are often not the same as other people who also might happen to build really good software.

In software development, every member of a team is making decisions that will have short term and long term impact on success. These decisions are often being made minute by minute. Can a team afford not to have a unified vision of what they are trying to accomplish and what they value that has not been purified in the crucible of collective examination and honest conflict?

What are you afraid of?

(ok, one more gratuitous quote)

The harder the conflict, the more glorious the triumph. What we obtain too cheap, we esteem too lightly; it is dearness only that gives everything its value. I love the man that can smile in trouble, that can gather strength from distress and grow brave by reflection. ‘Tis the business of little minds to shrink; but he whose heart is firm, and whose conscience approves his conduct, will pursue his principles unto death.

-Thomas Paine

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: