Part of being a consultant for a company that doesn’t really specialize in one specific area, is being thrown into environments that don’t always directly align with my specialties (read, things I like to do).  For example, here’s a recent exchange between me and one of my matrix-bosses:

• Bill, can you manage part of this project to move a data center?
• Do I get to pick how it’s managed?
• Umm, no – not so much.  But you do get to play with virtualization.
• Hmmm. Alright I guess.

In this case, I’m one of five project managers on a data center migration project.  I, being the only one without a PMP and a software developer by trade, immediately start looking to find an Agile angle for my piece.  At first, I admit, I wasn’t seeing it.  Then we had a meeting to try and sync up the five projects with regards to their overall migration process when the nice round circles of iterations started to come into view.

Part of the current issue we’re facing with the move is that nothing is really set in stone.  Is it going to be one large migration event or maybe several dozen? Does the mainframe go first or last?  Are we forklifting anything at all?  What about the best virtualization strategy?  All of these questions and very few definitive answers. Hazy requirements. Score one for an agile process.

Additionally, there is currently no fixed timeline as the only current constraint is quality.  The more we move towards zero tolerance for unplanned outages and/or extended downtime, the more lenient we can be with the overall length of the schedule.  While an extended number of migrations does not negate all risk of an unplanned problem, it does let us move things to the new location using a more controlled approach.  I can, of course, make the argument that an extended timeline actually increases the risk of problems because every time I take apart a piece of the network, I introduce the possibility of all sorts of bad things happening; however, in this environment, it’s a lesser risk.  Score two for agile because now I have the ability to add iterations as necessary in order to handle any complexities we uncover during the process.

We’ve also been chartered to build a repeatable process for executing the migration.  The client wants something that can be performed over and over for however long it takes to get all the servers and applications from the current data center to the new one.  Essentially a checklist or a handbook to walk them through the sequence of events.  In order to do this, I need to break migration types into components so that I can try to homogenize the process as much as possible.  This gives me small, discrete units of work that can be prioritized, scheduled, and assigned effort.  Score three for an agile approach for being able to treat a migration element like a feature or story card.

In the end, the process we came up with looked like this:

Lastly, we want to try and fit our migrations into predetermined time slots that the client uses for maintenance windows.  These maintenance windows occur every week for six hours.  If we can utilize these six hour increments as much as we can, then it may be possible to get all of our moves done during scheduled maintenance slots making this a “non-event” series of events.  These maintenance windows don’t move and they happen regardless of whether there is any work to perform or not.  A non-movable date is a core agile tenet.  Score += 1.  If we can’t get all of the migration elements completed in a maintenance window, we can just push it to the next window.  That sounds agile to me too!  Score += 1.

So all of these things fit within the spirit of an agile opportunity.  The business value being delivered over each time period are existing systems being brought up in the brand new data center (more reliable, better managed).  Delivering business value at the end of each iteration is again, a core agile tenet.

As we got through mapping the approach, at a high level, it looked suspiciously like Feature-Driven Development.  All of the investigation and planning being done up front, and the actual execution of the effort (which in our case is moving machines instead of building software) being done iteratively.

So, overall – yes, it looks like we can move a data center using an agile-type methodology.  I’m not going to say that it IS agile simply because I don’t want to draw the ire of my fellow project managers.  And even if they don’t agree and subsequently run their respective projects using more traditional methods where the “Execution” phase of the project lasts for 6-9 months instead of 2-4 week increments, that’s fine.  I’ll run my piece with an agile flavor, and in the next entry, I’ll break it down to a detailed level showing you how.