Tim Lister is a principal of Atlantic Systems Guild and co-author of the acclaimed books, Waltzing with Bears: Managing Software Project Risk, and Peopleware: Productive Projects and Teams. Freelance writer Bob Cramblitt spoke with Lister about the patterns that help determine software success or failure.
Cramblitt: You’re working on a new book. Tell us a bit about it.
Lister: Actually I’m working on it with the five other principals of Atlantic Systems Guild. The book is tentatively titled Project Patterns: From Adrenalin Junkies to Template Zombies. It’s a series of nearly 100 short essays on project patterns for good and bad. If they are healthy patterns, we talk about how you promote them within the organization. If they are dysfunctional, we tell you how to stop them.
Cramblitt: Let’s start with the bad ones. What are three things that project teams can do to ensure failure?
Lister: One is what we call Brownian Motion, based on the physics term defining a constant state of random motion. In our definition, it means loading a project with people when you still haven’t decided what you are actually going to do.
Another pattern is project sluts – organizations that can’t say no; they have far too many projects for the staff they have, and things never get done.
We also see a pattern called dead fish. This is a project that is doomed from the start because the schedule is outrageously unrealistic.
Cramblitt: What are some good patterns?
Lister: One of the best is strawman: building low-fidelity, low-cost prototypes for projects even if you know the approach isn’t right. Strawman projects help you discover where you are going wrong early on, and help people articulate what they want and need.
Seasons for change is a pattern that specifies that changes will be made only during certain windows of time, avoiding problems with constant tinkering.
Testing before testing describes a pattern of doing quality assurance in parallel with the project, instead of waiting until the end. This helps everyone understand project specs in the early stages of the project.
Safety valve is another one. People involved in projects need to blow off steam and do goofy things like jump up in the afternoon and go bowling. There are other things related to this that are important too, such as sharing food, and setting up opportunities for people to get to know one another outside of work. My dad once said, “it’s hard to hate someone when you know their name.”
Cramblitt: Has project management improved in the 20 years since you co-wrote Peopleware?
Lister: Yes, I think so. More organizations realize that system building is a deeply human activity, rather than a high-tech, engineering effort. People are looking at bigger projects differently. Good organizations aren’t doing things in a ballistic way – where you aim a gun, shoot, and the bullet goes where it goes. The new approach is more like driving a car: you drive a bit and if don’t like where you are going, you steer in a different direction.
I think the agile development people have a tiger by the tail. They don’t attempt to build a perfect spec that will be the bible for the next two years of development. Instead, the approach is to spec a little, build a little, run it by people and get some feedback, then get another cycle going, continuing until you hit the moving target. Larger projects are much riskier, and agile development is a way to minimize risk.
Cramblitt: What do you think about the reliance on best practices?
Lister: I get chills when I hear that phrase. From my point of view there are some pretty good practices, but no best practices because that implies generic software development. All projects are related to the domain they’re in. A best practice for defibrillator software is not the best practice in another domain. I’d like people to think about patterns – abstracting their work and recognizing the patterns they’re in, good and bad, and making informed decisions to promote those patterns or replace them.
Tim Lister will talk about project sluts, strawmen, safety valves and much more at the Business of Software 2007 conference, October 29-30 in San Jose.
He’ll be joined by other software luminaries such as Guy Kawasaki, Joel Spolsky, Rick Chapman, and Jeffrey Pfeffer. For more information and to register, visit www.businessofsoftware.org.