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:

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 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. 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 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 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 set based concurrent engineering where we try out several approaches before converging on the actual solution later on.