Jeff McKenna's Agile Development Blog

Junkies and Zombies: Patterns of Project Behavior

Yesterday I finished reading Adrenaline Junkies and Template Zombies - Understanding Patterns of Project Behavior by Tom DeMarco, Peter Hruschka, Tim Lister, Steve McMenamin, James Robertson and Suzanne Robertson. Whew... with a list of authors like that it must be good or at least long.

It is good and it is not long. It is a very readable compendium of 86 patterns with a couple of ‘interludes’ to break things up. The patterns are in a short, fairly informal format of some two to six or seven pages. Each describes a way we operate or operate in organizations. There is some gentle discussion of details. And an even more gentle treatment of those patterns that are judged less than ideal.

The book supports achieving a goal of mine for all teams and individuals on those teams: Becoming more conscious of the work that we do and more conscious of the relationships that we are in as we do that work. The patterns are presented as a way to think and reflect on how we work together. Some are more technical, some are more relational, and some are individual.

The names give many of them away: Face Time – about talking together; It’s Always the Goddamned Interfaces – exploring the congruence of teams and components that they build; Sanctity of the Half-Baked Idea – notices that if only ‘good’ ideas are allowed the great ideas are more difficult to find.

I recommend this book. Enjoy it one small bite at a time.

P.S. As I was reading the book I found myself wanting to score myself and score my current job situation. How was I doing? How were we doing? What was our Zombie Score? Perhaps the authors can provide a simple spreadsheet and do some analysis. If the Zombie score of an organization is good, are they more successful?

Comments on Amr Elssamadisy's new book Agile Adoption Patterns

I just took a detailed look at Amr Elssamadisy's new book Agile Adoption Patterns - A Roadmap to Organizational Success.

I like it. It brings together a wide range of agile practices and gives good analysis of each. As with good pattern books, it shows why, how, why not, and such for each pattern. Since there are 38 (!) practices, finding the one that matters for you is important. They have been clustered a bit and are still hard to find.

I personally find patterns a useful way to capture and present what is needed and at the same time difficult to understand. Since I already understand these patterns I found them useful and occasionally found a new way to think about a particular one. If I did not already know the pattern, I am not so sure how useful the book would be. I will defer on this to others in that position.

And one comment early in the patterns did catch my attention and has, I hope, influenced my thinking: Amr comments on the importance of learning. Much of the agile feedback mechanisms can be viewed as opportunities for the team to learn.

The importance of the learning cannot be dismissed. Getting better in every aspect of creation - planning, design, measuring, coding, testing, communication, delivery - is critical to create a high performance team. Such teams look at every change, comment, bug, and hick-up as an opportunity to improve.

I use the repetition of activities as an easy way to identify an area for improvement. If the team is spending time on activity over and over again then an opportunity exists for improvement. In particular these opportunities often are automated to eliminate the human time/errors that are present.
So, Amr, thanks for the stimulation.