The Five Dysfunctions of a Team: Book Review
Date: 2009-04-22 06:50:43

== The Book

http://www.amazon.co.uk/Five-Dysfunctions-Team-Leadership-Fable/dp/0787960756/ref=sr_1_1?ie=UTF8&s=books&qid=1240314513&sr=8-1[The Five Dysfunctions of a Team] by Patrick Lencioni

== The Review

I heard about this book a while ago but I was intrigued to actually get a copy http://twitter.com/dcotterill/status/1554291688[by Darren Cotterill], the Iteration Manager on the project I'm working on at the moment.

I was particularly interested in learning whether the ideas of agile and/or lean help to solve any of these dysfunctions.

== What did I learn?

* The book is split into two sections. In the first section a story is told about an organisation with a dysfunctional team and the dysfunctions are gradually introduced. The second section covers them in more detail and provides ways to overcome. The dysfunctions are as follows:
 .. Absence of Trust - team members are unwilling to be vulnerable within the group
 .. Fear of Conflict - team cannot engage in unfiltered and passionate debate of ideas
 .. Lack of Commitment - team members rarely have buy in or commit to decisions
 .. Avoidance of Accountability - team members don't call their peers on actions/behaviours which hurt the team
 .. Inattention to Results - team members put their individual needs before those of the team
* One of the most interesting arguments the book raises is around getting everyone to be focused on the same goal whereby the *collective ego gets precedence over individual egos*. This requires a *lack of politics* which is defined as 'when people choose their words and actions based on how they want others to react rather than what they really think'. This idea also seems similar to the idea in lean thinking of http://www.markhneedham.com/blog/2009/04/14/lean-big-picture-over-local-optimisations/[favouring the big picture over local optimisations] - the team as a whole succeeding is more important than any individual success.
* The other danger of individual goals being favoured over those of the collective is identified as being *specialism* in teams whereby everyone is responsible for their part and noone else knows anything about it. http://www.markhneedham.com/blog/category/pair-programming/[Pair programming] with frequent rotation is one approach that we can use in software development teams to help avoid this specialisation as well as encouraging team members to become http://www.markhneedham.com/blog/2008/08/11/does-generalising-specialist-mean-you-cant-be-the-best/[generalising specialists] rather than expert in just one area.
* The ideas around healthy conflict are quite interesting. Meetings should have *some level of conflict otherwise we probably just have false harmony*. This sounds a little similar to the idea in lean that 'no problem is a problem' - i.e. we shouldn't keep things to ourself but instead get them out there and find a way to solve the problem. The author also points out that conflict is never going to feel comfortable but that doesn't mean that we shouldn't engage in it.
* I particularly liked the ideas for creating trust on a team - team members are given the opportunity to share some information about themselves including their greatest strength and weakness in relation to the team. I've not seen this explicitly done on any teams I've worked on but I think that when pair programming people do share this kind of information so maybe we do actually get some of the benefits of this approach. The idea is that team members should be 'confident that their peers intentions are good'. Reading this reminded me of the http://www.retrospectives.com/pages/retroPrimeDirective.html[retrospective prime directive].
* An idea which I don't completely agree with is that we should look to make decisions because 'a decision is better than no decision' - the author claims that not making decisions can lead to a lack of confidence in the team and that dysfunctional teams wait until they have enough data to be certain that their decision is correct. He does then go on to point out that if the decision is wrong then we should not be afraid to change it which I do agree with. In software development teams though I question the value of making decisions too early - there is some value in following an approach such as http://xp123.com/xplor/xp0611/index.shtml[set based concurrent engineering] where we try out several approaches before converging on the actual solution later on.

== In Summary

I found this book really interesting and I could definitely relate to some of the the things that were talked about.

I think lean/agile ideas do solve some of the problems but certainly not all of them and it would definitely be interesting to try out some of the exercises suggested on future teams I work on.