Conflict & Dysfunction

I had a short conversation about conflict the other day with Mr. Chris Chapman.  The conversation took place where all good conversations took place: on twitter.  Since it’s completely too difficult to be concise, I decided to write more about it here.

Quick Plug: If you’re in Canada, and need a team-whisperer, give Chris a call.

I hear this word – conflict - tossed around a lot these days.  Especially as organizations realize value comes from teams, and therefore conflict is going to happen whenever we get a group of humans together to do work.  So until the robots take over completely, it behooves us, and is in fact economically beneficial, to learn how to exist, work, and thrive amid conflict.  Lencioni’s Five Dysfunctions of a Team is a good place to start exploring this.

On the 1st dysfunction, I too agree that fear-of-conflict is a team killer.  Seen it a dozen times.  Nobody on the team is willing to discuss hard tradeoffs with each other, much less with management.  Punch the clock and hope everything turns out.  Clearly not the best business strategy.

Once you get past the first dysfunction, teams start to openly discuss and debate issues.  This is where things get interesting.  There’s a crucial point here where teams either thrive or devolve very quickly.  And in my experience, the devolving case is typically triggered by one or two individuals.  Indeed, it seems the very people who urge us to have open conflict are those that aren’t actually very good at being in conflict.  They are the people that want to debate for debates sake.  Or sucker you into an argument that doesn’t much matter.  Or tell you all the ways your reasons don’t make sense, but offer no alternatives.  Or approach the situation already knowing the one and only right answer.  Lencioni says this state should be characterized by harmonious disequilibrium.  Don’t forget the harmonious part! 

Here’s three quick ways you can practice this skill:

1.     Actively pick discussion topics that you don’t have a strong opinion on.  Practice these skills in a context where you can focus on the cognitive part of conflict.  Where you can be observe yourself in the conversation and start noticing how you behave.  This will be easier at first if you choose topics that you have no strong emotional tie to. 

2.     Be curious, but in a real way.  Ask questions, be genuinely interested in others points of view.  Be careful though, if you’re not really open to the situation, you’ll come across as trying to cross-examine and entrap.  This takes some work, and you have to be self-aware in the conversation to do this. 

3.     Call it out.  As a coach, I might say use level three listening.  When you sense a group entering conflict, call it out.  “I think this is an issue worth discussing, yes?  Is everyone willing to have a real conversation on the subject?”  This helps set the stage and ensure everyone enters the situation on an even footing.  Too often these discussions start with one person coming from a place of power – having just discovered something, just learned something, or simply being senior to other member of the group.  That’s a recipe for disharmonious conversations.  Setting the stage for the discussion will help level the playing field.

Experimentation is the New Planning, taken further...


This article in FastWeek, “Experimentation is the New Planning,” inspired me to write this.  Not only is experimentation the new planning, but it’s really the only way we can ever be sure we’re ever building the right thing.  

There is a strong legacy mindset to develop “the whole feature.”  I still see it even on mature agile teams.  We still think that if we spend some time refining it, understanding it, and detailing it, then it must be valuable to build it.  

What I’d like to see is more experimentation at the micro level: for every theme, feature, even every PBI.  Why assume we should take the time to build the whole thing just because it’s on the backlog?  Let’s instead break everything up into smaller pieces - the first of which is an experiment to prove that the whole feature is actually valuable.  

I think PO’s would love this approach.  Invest the minimal amount of time and money into designing an experiment, and then only once we’ve proven the feature is valuable, invest in building the whole thing out.  You can be reasonably assured to avoid the dreaded “60% of features are rarely or never used” statistic by employing this technique.  

Envision a feature -> Test for Value -> Build