This is a title of a book by the Atlantic Systems Guild, a group that includes Tom DeMarco and Tim Lister, authors of Peopleware (one of my favorite books) and Waltzing With Bears (a terrific perspective-shifter about risk analysis). (I interviewed Tim Lister here in 2003). It was published in 2008 by Dorset House, a company I respect; they've been publishing books on software process management fairly exclusively from their inception.
The subtitle is "Understanding Patterns of Project Behavior," and the book is a reasonable attempt to follow the Design Patterns movement by presenting a sequence of free-standing "Patterns" regarding project management. It soon becomes clear that "project" usually means "software development project," although some of the patterns apply to projects or teams in general. Fortunately, they do not slavishly follow the software design pattern structure, which would be overkill in this case. Here, a pattern is a name, a one-line description, and two or three pages of prose. The patterns are independent so you can jump around.
This book has a lot of value for someone who is unfamiliar with Agile software development methods and is working in an old-style organization. The problems presented that focus on creating software are almost always solved in the book using Agile methods. The patterns for organizational behavior point out difficulties that arise from industrial-age management.
The book didn't work that well for me, though. I find anything that accepts industrial-age ideas to be rather depressing, and try to avoid those things. And I'm well-schooled in Agile methods so those patterns didn't do much for me, either. In most places the book clearly espoused Agile, but there were some places where it didn't seem to fully grasp Agile. For example, on page 160: "If you really are committed to shipping exactly on-time, every single time, you are left with only one correction available: relaxing your ship quality criteria." Well, no. You cut features until you can meet the deadline. That's Agile 101, and it was strange for them to have missed it.
Although writers didn't put their names on the various patterns, the authors might not have followed Weinberg's coathoring maxim: "everybody works on everything;" things were not grossly inconsistent but every once in awhile it seemed like there were different voices.
One guideline that popped out for me was pattern 61, "Orphaned Deliverables." This discussed the demand for lots of deliverables that exist for form and not for function. The solution given was to ask, "Who is the sponsor of this artifact?" Every artifact needs a sponsor, who must not only be able to ask for it but also to provide resources for the creation of that artifact. If no one can step up, you don't create the artifact. This is an excellent way to trim unnecessary fat from a project.
One particularly annoying oversight was a little chapter called "The Cutting Room Floor," where they listed the names of all the patterns that were left out. In all the other chapters, the name was followed by a one-or-two-line description of the pattern, from which you could get a good idea of what the pattern was about. "The Cutting Room Floor" left all these descriptions out, and the pattern names were thus rendered meaningless.
I got value from the book, but it felt like it left a lot of unfulfilled potential on the table. I suppose I was hoping for another Secrets of Consulting (and even Weinberg seems unable to duplicate that feat).
Posts
