Monthly Archives: March 2008

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.

Like this:

“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.

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.

Some people might consider me somewhat a technologist but that is misleading and superficial, at least in my opinion.

I’m fairly decent with technical things and thankfully that has allowed me play with some really cool stuff and to cash some checks to feed my family, but I have other interests and abilities involving art, communication, culture, athletics, food and the human condition just to start the list that extends into the horizon.

I think that makes me better at technology, but maybe it just keeps me from being bored

Living in Salt Lake City has also given me the opportunity to absorb Agile software development philosophy and practice from close to the source. Alistair Cockburn‘s Agile Roundtable is an excellent resource for anyone who wants to drink from a well of creative insight. I’ve also been influenced by the local XP community, specifically Zhon Johansen.

I’ve recently dedicated myself to building a life for my family around an Open Source software project called Puppet. (crazy, I know) Puppet was conceived and written primarily by Luke Kanies, after working for years as an operational sysadmin and then as a system automation consultant. I believe Puppet represents a significant step forward in system management. I am not alone.

Puppet is written in Ruby, which is a pleasure to read and write, at least after years of primarily C++ and Java. (with a smattering of bash, python, perl, tcl, matlab and javascript thrown in for good measure) Ruby (and Puppet) also awoke a latent interest in functional languages and declarative constructs.

This blog will capture my thoughts and observations, my trials and tribulations, both past and present, concerning how technology and people come together to create value and opportunity. Maybe it will be useful or amusing to someone else. . .