//Project Management Antipattern 2: Pardon My Dust

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…

By |2006-01-19T09:35:00+00:00January 19th, 2006|Enterprise Architecture|2 Comments

About the Author:

President of Vanguard EA, an Enterprise Architecture consulting firm in Seattle focused on the Pacific coast of the US. Nick has over 30 years of professional experience in management, systems, and technology. He is the co-author of the influential paper "Perspectives on Enterprise Architecture" with Dr. Brian Cameron that effectively defined modern Enterprise Architecture practices, and he is frequent speaker at public gatherings on Enterprise Architecture and related topics. He coauthored a book on Visual Storytelling with Martin Sykes and Mark West titled "Stories That Move Mountains".

2 Comments

  1. Malcolm Anderson January 20, 2006 at 8:30 am - Reply

    <begin re-write # 3>

    I still need to put some thought to this, but one of the things that originally caught my attention about the whole agile process was the promise of handling pain early and while it’s still doesn’t hurt much.

    Maybe I’m just smoking crack, but the whole concept of a "deployment sprint" makes me twitchy. Mostly, this is because historically, “Deployment” and “Roll Out” tend to mean pain and late hours.

    By having an environment where a developer pushes his code from his machine and "rolls it out" to "Development" and that when a sprint is done, the Dev team "rolls it out to "QA", who "rolls it out" to "User Acceptance Test" who in turn, "roll it out" to production.

    By doing 3 "roll outs" before ever getting to production, the majority of the migration issues are going to have surfaced, (and more importantly, been automated) before you ever get to production, you decrease the need for a "deployment sprint".

    Admittedly, the sales job to get a company to spring for 3 additional environments might be tricky, but I’m willing to bet, that if you are big enough to have a full QA team, and a full UAT phase, that the extra equipment (plus the wonders of virtual servers) could be easily shown to be a drop in the bucket compared to the labor costs currently associated with "roll outs"

    </end re-write # 3>

  2. NickMalik January 20, 2006 at 11:41 am - Reply

    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.

Leave A Comment

5 × five =