Customer Reviews

Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior

5 star:		(10)
4 star:		(3)
3 star:		(2)
2 star:		(0)
1 star:		(0)

 

 

Adrenaline Junkies and Template Zombies is a collection of 86 patterns of project behaviour collected and documented by a group of 6 authors from the Atlantic Systems Guild.

Each pattern is presented with a title, a picture, a one- or two-sentence summary, and a few pages describing the pattern in more depth. This format works pretty well, and the book is both funny and very easy to read. However, when I finished reading the book and asked myself what I had learnt from it, I had to answer "Not much".

That's not to say it's a bad book, just that if you have been working in software development projects for a few years, there aren't that many new insights here. However, the book does a good job of singling out and labelling various project behaviours (usually bad ones), which is useful.

Of all the patterns in the book, the ones I liked the best were "The Blue Zone", "Practicing Endgame", "Mañana" and "Time Removes Cards from your Hand".

"The Blue Zone" describes the green zone, which is anything that is explicitly ordered or allowed by the project, and the red zone, which is anything explicitly forbidden. The blue zone is everything else, activities that are neither explicitly allowed, nor explicitly forbidden by the scope of the assignment. In the authors' opinion (and in mine, too), it is good to sometimes operate in the blue zone, in addition to in the green zone, in order to achieve the best outcome. Or, in the words of the quote ending the pattern: "The correct amount of anarchy on a project is not zero".

In "Practicing Endgame", the idea is that you should be thinking about and testing against your release criteria continuously, as opposed to leaving that till the end. The analogy given in this pattern is that of the university course, where you may have several tests throughout the term, in addition to the final exam. This "continuous" exam preparation gives better results than the one-off method of only having the final exam.

The last two of the patterns I liked the most both deal with time.

"Mañana" simply states that if your goal date is more than 30 to 90 days out, you need to set sub-goals that are within 30 to 90 days, in order to make the people on the project feel the right sense of urgency.

"Time Removes Cards from your Hand" describes how you have fewer and fewer options the longer you pretend that everything is fine, even though things are not fine. You might end up with many half-finished features, instead of a few completely finished features, and it might not be the most urgently needed features.

Except for the concept of the blue zone, which I like and which I had never seen explicitly described before, even the patterns I liked are not really teaching me a lot that I didn't already know.

In fact, if you are using agile methods like XP or Scrum, then you will recognize a lot of the patterns and advice as standard agile working procedures ("Straw Man" is another example of this).

On the other hand, there are a number of examples of anti-patterns from (it seems) process-heavy larger companies, for example "False Quality Gates" (documents are check for format, not contents), "Paper Mill" and "Orphaned Deliverables" (both deal with places where the measure of progress is documents, not working software), and "Cider House Rules" (rules are made by people unconnected to the project).

When it comes to the names given to the different patterns, there are some hits and some misses. A name that is both catchy and describes the pattern in a good way makes the pattern so much easier to remember. My favourite is "Template Zombies", which I think is pretty self-explanatory, but "One Throat to Choke" is also very good. But naming is hard, and there are many patterns that I feel have pretty awkward or non-descript names, like "Lease your soul" (about how to adopt new technology - I'm thinking more in terms of a tool-box than selling/leasing your soul to some new technology) and "System Development Lemming Cycle" (that the process used isn't tailored - but where did the lemmings come from?).

Another complaint is that the different patterns presented in the book are not organized around themes - instead they are just put in random order. I would have preferred if they were grouped together, since many of the patterns deal with related concepts.

So, in summary, the patterns in the book cover many different project behaviours. The descriptions are useful and well written, but if you have been involved in software development projects for a while, most of the patterns should already be familiar to you. Still, they may serve as a useful reminder - plus, you get (in many cases) snappy names for some of the behaviours, which may make them easier to diagnose and talk about.

Also, if you're interested in this book, check out episode 131 at Software Engineering Radio. That podcast is an interview with Tom DeMarco and Peter Hruschka about this book, and it is well worth listening to.

Patterns are all the rage these days in software development. You can't be a serious software person unless you invoke a pattern here or a pattern there. The bright folks at the Atlantic Systems Guild have named us 86 project patterns so that more of us can drop a pattern name here and there and get the mantel of being serious project folks.

Most of what you read in this book are patterns of things gone wrong patterns more than patterns of things gone right. I think that this is OK though I did find it a bit frustrating at times. There would be a suggestion on how to disrupt the negative patterns occasionally but, given the short, blithe entries, not a lot of detail. This book is more about diagnosis than about treatment.

So, read it more for enjoyment rather than serious project help. Anyway, most of the patterns, certainly the names, are all made up. "We make no claim to the universality of our observed patterns." Not measured, not tested, just observed. However, these are keen observers and I found myself agreeing with most of the entries.

The title and cover caught my eye (today!) in the bookstore and after flipping through, I couldn't wait to get home and blow through it.

It's clear why this is getting a 5-star average here @ Amazon. Written by the same folks who authored Peopleware (classic skilled-person management book), it contains ~80 patterns of project behaviour alternating between helpful and harmful.

Almost immediately I had several, "Ohhh yeah! That's what's going on!" moments. The authors do a terrific job of identifying patterns and the reasoning behind them. Being relatively new to a management gig, this sort of resource is invaluable. You might not be able to fix some of the issues, but you'll certainly be able to notice them more quickly - which is really the first step.

Each pattern is about 2-3 pages long, clearly identified in the table of contents and with pattern headings that stand out. This presentation allows me to quickly refer back to find out the suggested cure.

Most patterns are presented with prescriptive, corrective behaviour. Granted it's not a detailed dissertation on how to fix organizational issues, but enough to get an idea of the scope of the fix; work through it, or time to find another employer?

I'm already in the process of recommending this to my peers. It's such a brief, valuable read that anybody with skin in the game (from developers to CEOs) should give it a look.

I love this book.

These guys must have been spying on my office for the past 20 years. Most of the bad things that happen where I work (and a few of the good things) are in this book. They truly are patterns of project behavior.

The book includes 86 project patterns. Each has a title, a one sentence summary, two or three pages of text, and a great illustration or photo. The first pattern is "Adrenaline Junkies" - the place I worked in 1986 where every thing is urgent and must be started now and no one eats or sleeps until it is done. The last pattern "Template Zombies" - the place I worked in 1996 where every thing is a template that must be filled without any thought. Working complex projects without any thought - not a good idea.

Flip through this book. Find a pattern - either good or bad - that fits your current project, bring the book to work and show people that your workplace is not unique, that others have done the same before, and what the result will probably be if you don't change.

This book reads like a series of blog posts on software project management. The Principals of the Atlantic Systems Guild, which include the authors of Peopleware, present a series "patterns" observed during years of working with developers and project managers. The tone is far from dry and didactic, however. This is a very entertaining book to read.

The episodic quality of the writing makes summary difficult. Basically, the authors espouse an agile development philosophy without being too rigid about any single methodology. They take aim at project teams which love coding against impending deadlines ("Adrenaline Junkies") as well as at teams which love documenting all the irrelevant details of their work ("Template Zombies"). Dysfunctional patterns (anti-patterns?) can arise in agile teams as well as traditional groups.

Every project manager will likely pick up some new tips from reading this book. For instance, the chapters "Fridge Door," which advocates posting progress reports in high-traffic locations for all team members to see, and "War Rooms," which counsels setting up dedicated project rooms to 'center' projects, helped me to work out a strategy for lining up and coordinating the activities of people working on different aspects of our next big project.

By and large, the book consists of more anti-patterns than patterns. I learned more about what to avoid--and how to discern when projects have taken on the 'smell' of failure--than what to promote. But I suppose that avoiding anti-patterns is a good step toward implementing successful patterns. A few of the "patterns" are commonsensical or non-sequitors--like the observation that many software developers are also good musicians. Still, this is a quick and enjoyable read for managers who want to foster the agility and effectiveness of their teams.

The descriptions of 86 common organizational behaviors described in a concise and entertaining way, using stories, guidelines, and metaphor aren't really patterns, as the authors claim, but they bring out, in a memorable way, practices teams should avoid or emulate (depending on the behavior(. Managers, developers, and students of organizational behavior will enjoy reading this book and want a copy around for reference. Those with more experience will find that the patterns resonate with them, and those newer to software development will get an idea of what to expect in team dynamics. Like may great books, you'll have learned much from the experience of the authors while being entertained and amused.

How can you keep from getting sick by infection? You need to build up immunity. There are two ways to do this. One is by surviving an earlier bout with the disease, and the other is by getting vaccinated.

Reading this book will "vaccinate" you against the negative project behaviors it describes, so that they can be recognized and dealt with before they cause project failures. Learning from the failures of others is a lot faster and cheaper than learning "the hard way" (by taking part in failed projects yourself). Get everyone on your team a copy, so that the cries of alarm cannot fail to be heard.

With "Adrenaline Junkies and Template Zombies: Understanding Patterns of Project Behavior," The Atlantic Systems Guild team of DeMarco, Lister et al has done it again - a book about projects, project work and software development that is both useful and readable. I highly recommend this book.

Many books that relate to technical or managerial subjects are difficult to read - a lot of stuff you don't care about, and the occasional nugget. "Adrenaline Junkies" is a book of nuggets. Each chapter is a nugget or "pattern," including a phrase, a picture, a sentence and a couple of pages of descriptive text. One of my favorites, "News Improvement," refers to the tendency of bad news to be "improved" as it makes its way up the organizational chain. Another, "The Overtime Predictor," talks about how fear can drive people to overtime.

Not everyone will care about every pattern, but the book is organized in such a way that the reader has control over what to miss. Some patterns validated my own experiences. Some provided new insights. A couple I didn't get. My recommendation: read through the book, paying special attention to the patterns you care about. Skip some of the descriptive text if the pattern doesn't resonate with you, but first make sure you understand it. (Hint: the last paragraph of each pattern usually has a brief summary.) Then, when you're done, take a few minutes and go through all the patterns again to refresh your mind. That way, when you encounter these situations in real life, you'll remember the pattern. Even if that's all you can remember, you'll be able to refer back to the book for advice.

God, what a great read! Serious topics, but plenty of humor to take the edge off. As usual, this team of folks have got it right. For everyone in the software development arena, this is a must read!

I have been a fan of Tom DeMarco and Tim Lister for some time, their insights into the right way to manage information technology (IT) projects could be entitled, "The Way It Should Be Done." In this book, they are joined by their colleagues in the Atlantic Systems Guild to describe 86 project patterns, some of which you would enjoy being used to describe how you do things and others that you would avoid if you could. The descriptions are generally short, less than three pages and include a figure for emphasis.

Unless you have been blessed to a level that no one to my knowledge has ever been or you have never worked, then there will be patterns in this book that will cause your head to nod in agreement. Using colorful language on occasion and consistent blunt talk, the authors tell it straight, providing advice that pulls the façade off of some of the common notions of what makes a project work. Some of the titles of the patterns are:

Project slut
Rattle Yer Dags
One Throat to Choke
The Too Quiet Office
Everyone Wears Clothes for a Reason
What Smell?
Sanctity of the Half-Baked Idea
Seelenverwandtschaft
The authors are big advocates of creatively goofing off, arguing forcefully that the most productive teams are those that do things together that are anything but work related. Eating together, attending a movie, playing together in a band and a regular poker night are suggested ways to build cohesion and a sense of respect between the members of the development team. They also insist that some of these things should be done on company time.

The group is also strongly opposed to strict rigidity of any form, believing that a bit of chaos, animated discussion with disagreement and respectful truth telling are all signs of an efficient and productive team. In the "Miss Manners" pattern, they point out that extreme civility is misdirected and results in deep mediocrity. Everyone is subject to generating the occasional error or bad idea and if it is accepted rather than rejected for fear of hurting feelings, everyone suffers.

This past year, I authored a new major and minor program in Management Information Systems (MIS) for the college where I teach. Two of the upper level classes in the program involve the study of the proper ways to manage IT projects. This book will be used as a supplementary text when I teach those courses.

Published in the online Journal of Object Technology reprinted with permission