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…