Do you find the title as curious as I do? If titles are designed to encourage you to take books off the shelf and at least look at them, this title works for me. But now I have it off the shelf, what is it about?

In 1996 the authors established a laboratory to study high performance teamwork and to apply their work to teaching/training high-tech teams to work more efficiently. The method was to take a team, give them a product to develop and asked to imagine the product, agree on how make it and then design, build and ship it on time. The earliest teams were almost entirely experimental subjects but after the first couple of iterations new teams got the benefit of the author's past experience. As time went by the authors successively refined methods that seemed, pragmatically, to help teams work more effectively.

Now five years on they have attempted to distil all they have learnt into a book. They have identified a number of helpful approaches as well as a number of detrimental ones (Patterns and anti-Patterns in modern terminology) both at team and team-member level. Most of the book addresses these.

Now the question that crosses my mind is whether a book such as this can replace expert mentoring aimed at team building. My feeling is that the book is a useful read for anyone involved in a team, but its real value will be to anyone who is responsible for building a team (and I do not mean the team leader). The first thing to come out of such thinking is that teams need an outsider who can look at the team as a whole and pin-point weaknesses. Most teams will not be able to do this for themselves. However when a team has read this book they might reasonably use it as a guide for introspection. Set aside some time on a regular basis and take any one of the (anti)Patterns and consider to what extent it is relevant to the team.

Then there is the way in which accomplished people use Pattern language for communication. If all team members are familiar with the pattern language introduced by this book it becomes possible for any member of the team to wonder aloud if they (the team) are exhibiting something such as 'Align Me'. Or if the 'Decider' is applicable here. Of course such questions mean nothing to those that have not read this book, but a major point of a pattern language is to enable quick communication. I, also suspect that negative criticism comes over betterthis way because it, to some extent, depersonalises it.

As you will note, I am only speculating. I think the authors have done important work and that this book has considerable potential but I would be interested in the experience of others. Currently I would definitely recommend this book to anyone responsible for training teams and give a guarded recommend-ation to those who are members of teams.