Patterns of project behavior

The book “Adrenaline Junkies and Template Zombies, Understanding Patterns of project behavior” contains 86 patterns, written in an easy readable and recognizable style which make you think about how people behave in projects.

The authors have a lot of experience in various areas; their different views help you to get a broader understanding of issues that you can face in projects.

Using Patterns

Patterns help us to understand things. They are not necessarily good or bad; in fact they may or may not be applicable given the situation at hand.  I see many of the patterns that are described in the book in my projects and daily work. Reading the patterns made me think on how we do things, and helped me to discuss them with colleagues. Below some examples of patterns, and how they helped me to understand and improve our way of working, and become more effective.

Pattern 37: Talk then write: This pattern states that decisions made in meeting should be immediately afterwards communicated in writing. Pretty obvious, but I still see it happening that it takes a long time before we communicate what we decided, or that it is not communicated at all, that we do not inform all involved, etc. Due to time, the decision loses force, becomes unclear, forgotten, or it may even create resistance. With agile we have much better means now to communicate instantly, so let’s do it! Use the war rooms, information radiators, wiki’s etc, as much as possible, quickly after decisions are made, and update them when decisions are revised.

Pattern 56: Undivided attention: This pattern states that undivided attention in a single project improves individual performance. With agile we usually have technical teams with full time members, focusing on the iteration at hand. But what about supporting functions? They are usually allocated to multiple projects, and also in process support, improvements, line support, etc. Task switching makes it difficult to give sufficient attention to each assignment, to build up relationships with the teams, and to really understand the issues and provide effective and timely solutions. Maybe it would be better to combine some of those part-time roles in a project, and have somebody working most of his/her time for one project? Or make the business case for a support role, increase the funding and assure that somebody can spend at least half time on one project, in stead of just of couple of hours or a day each week.

These are just 2 of the many patterns from the book that made me think about things. Reading the book made me feel like attending a good conference. There are a lot of interesting subjects in there, some which confirm what you already know, some which are less relevant for you, but there are certainly useful things in there. So most probably you will find some patterns that help to think about your work, to discuss it, and to improve it.

Note: This book review has been published previously in the IEEE Computing Now bookshelf.

Ben Linders

I help organizations with effective software development and management practices. Active member of several networks on Agile, Lean and Quality, and a frequent speaker and writer.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.