Project Management Antipattern 2: Pardon My Dust

I ran across this anti-pattern on a non-software project, but it definitely applies.  This one comes from painting my living room and kitchen.

My wife and I did a little repainting last week as part of converting our unused formal living room into an exercise space.  Last weekend, we basically finished the change-work after installing light fixtures and a five foot by nine foot mirror.  However, it took until today for us to really begin moving furniture back into the adjoining (and also painted) dining room.  Why?  Because we had book shelves that didn't look good with the new colors, and because we needed more light now that the mirrors were installed, and because... yada yada yada

It's scope creep, pure and simple, but not the kind that injects itself at the beginning of the project.  That kind is easy to stop.  Nope, this is an altogether different animal.  This is "pardon my dust" scope creep.  This one happens with full cooperation and insistence of the customer.

I call this "pardon my dust" because a customer will be forgiving of a project's lack of completion as long as new features are being added.  There is hope.  There is a bright, shining future!  And there is one more dinner in a family room filled with dining room furniture...  We are forgiving of the mess because we are getting what we want. 

As a project manager, especially on a Scrum or XP software project, it is tempting to simply "add another sprint" so that Features 88-94 can be added, especially since they are demonstrated monthly to the customer.  That customer keeps adding the next sprint, adding the next set of features, without ever asking for the deployment sprint to start!  (Deployment sprints are irritating.  You get no new features, it takes just as long, and you have to deal with messy details like QA reviews of the installation guides and maintenance documentation.)  The project manager has deniability because it's the customer who keeps asking for the sprint, and it's her money, after all.

It's a trap.  The way out is for the project team to set, at the outset, a maximum number of new-code sprints between each deployment sprint.  I suggest three as a good maximum.  That way, the rest of the end users get an upgrade at least semi-annually, which should serve to keep frustration low. 

Now to invite company for dinner...

Comments

• Anonymous
  January 20, 2006
  The comment has been removed
• Anonymous
  January 20, 2006
  Hi Malcolm. Long time, no see.
  
  I like the idea of a deployment sprint. It includes stabilization, minor corrections ("fit and finish") and the tedium needed to get an app into a very conservative production environment (documents, scripts, procedures, and the like).
  
  The notion that the app is actually ready to deploy at the end of every sprint is laudable and should be followed, but the reality is that there isn't time to truly QA the deployment bits during "sprint time." That conservative support organization doesn't work that way, and shouldn't. Therefore, at the end of each development sprint, the app should be deployed to a UAT or SIT environment (User acceptance test or system integration test). These are machines that mimic the actual production environment.
  
  So you practice deployment each time. The deployment sprint is when you get it right.