The world of consulting is not immune from this rapid change, if anything, depending upon the type of consulting that you do, you may actually be in a worse position. Not recognizing that you passed the “peak oil” of whatever your specialty happens to be, going from project to project looking for better ways to extract crude from the shale, without realizing that there is an abundance of productive new fields opening up all over – has you looking at the wrong side of the profit margin slope and stuck on projects that don’t position you for the next “big thing”.

I’ve been a consultant for 15 years now after spending about 6 years in industry. I’ve worked for boutique firms, “Tier 1″ firms (Andersen represent!), and “firms” in the middle. One of the things most of them have in common is their general operating model. You know, how they make money, how they sell, and their general outlook on the marketspace. These are some of things that are going to need to change over the next several years in order to move ahead.

As part of this series, the main idea I want to explore is reversing the order of precedence in a consulting company (or any organization, company, department, etc.) where a marketable talent should be the basic unit-of-measure by which that organization is judged. Where the success of whatever organization that talent is attached to is dependent upon nurturing, marketing, and harvesting that talent. Make the talent be the entry point to new projects, not the sales staff. To this end, we’ll be:

1. Building a model that operates more like a sports team rather than like a 1950s, top-down, “Tin Men”, sell-or-die mentality;
2. Avoiding a fall into a “Jennifer Government” type relationship with your employer. Consultants are responsible for their own marketability, thus their voice needs to be their voice. If done right, the voice of the consultant can be of simultaneous benefit to the “firm” too.
3. Focusing the message, generalizing less – but at the same time not becoming hyperfocused.

The selling model will be first. What we will need to breakdown is the notion that because sales is a low-supply, high-demand scarce resource, it is more valuable than the plentiful resources used on the delivery side of the house. While I’m not one to try and turn basic tenets of simple economics on its head, I am one to flip the problem around a bit so that I can show that maybe the types of people we generally think we need to fill the sales and delivery roles, are not the ones we actually do need.

My goal is not necessarily to marginalize the sales effort or the people that perform it, as I don’t think they should be an order taker any more than I want to be considered an order filler. Rather my goal is actually to make people that focus on doing delivery well, worth a dozen dimes instead of being a dime a dozen. 

I’m working on a series of posts that deal with making us (myself included) better consultants, changing the old sell & deliver model that rewards the wrong side of the equation and nets our clients a “net-static” solution at best.  The theme will be to quit proposing a “business as usual” stance.  All too often, we as consultants tell companies, “You’re not in the ’so-and-so’ so you need to focus on your core strengths.”  Maybe that’s not the right answer anymore.

Things are changing.  Rapidly.  The old solutions are just that…old.  It’s time we start embracing the change and tell our clients, “Sorry, you used to be an insurance/medical/financial company, but now you are a technology company – and you’re doing it wrong.”

What is the backchannel? Murmur, background noise…you know, those annoying side conversations during a meeting that usually only serve to disrupt and distract from whatever the main person in the room happens to be talking about. That’s the backchannel. Sometimes they’re secret discussions about you (at least in your mind they’re about you) that take place in closed-door offices. Or sometimes they’re all the chatiness happening over instant messenger while you’re sitting on a boring conference call. Or it can be even something as simple as the comments on this blog posting. Some people refer to it as a meta-conversation (conversation about the conversation) or even sidebar discussions, but regardless of you choice of phrase, the backchannel represents all conversations that are not part of the main thread of discussion – however are somehow contextually related to you either by subject-matter (topical), geography (locational ), and/or intimate frame-of-reference (personal).

Topical
The topical backchannel context involves groups of people that are congregating for a specific purpose. These could be meetings, rallys , conferences, concerts, sporting events, etc. – but essentially everyone is there for a common purpose. The participants may or may not be all physically in the same location (for web conferences, people are scattered all over the world) but it’s the subject matter that draws them together. It’s a shared purpose.

Locational
Where topical backchannel conversations have people sharing their experience around a subject matter, the locational backchannel has experiences being shared around a common geography. The geography can be hyper-local such as a stadium or arena, or more widespread like a neighborhood or town. The topics being shared can be varied, but the context maintains relevance by tying everything together via the proximity to the other participants. A perfect example of this is using your Twitter client to see all the tweets being broadcast in your immediate area. The subjects of those tweets can range from announcing dinner plans to lamenting about work but interest is piqued by the fact that these are neighbors of your in some way.

Personal
Personal conversations may or may not have topical or locational contexts that relate to your own situation at that particular moment, but you care about what some people say because you have some vested interest in the actual person. They could be friends, family members, co-workers, or someone of a varying degree of celebrity. While, it may not always be interesting conversations they’re having, but it is always pertinent to you. This is why you follow certain people in the first place isn’t it?

Purpose
The primary purpose of the backchannel is to give someone an opportunity to be heard. Whether it’s about expressing an alternate opinion, obtaining/providing clarification on a comment, or airing some form of agreement/disagreement – it’s an empowering form of expression. There may be 1000s of people involved with whatever is going on, but each backchannel voice is equal in weight. Assuming you’re even listening that is.

The secondary purpose is for sharing experiences. “I am here”. “We are here”. People at the front of the group, relaying messages to the people in the back. “I just saw so-and-so, I think the band’s coming out”! “Accident on I-71, take the lateral to I-75 instead”. These relationships can be formed and broken in a matter of minutes or hours, but the value of the interaction can last for much longer if you listen correctly.

To the actual participants of these out-of-band conversations, they get value from the interaction itself. But if you, the provider, are savvy enough, you can give them extra value by reacting timely to their discussions.

Value
The forechannel discussion, without the backchannel is a flat subject. Two dimensional in that it has height and width, but no real depth. A backchannel discussion without it’s forechannel has no context, It’s essentially just random noise. Together though, these two channels can form a symbiotic mesh of discussion where the forechannel gives relevance and shape to the background noise, and the backchannel gives the main idea more depth and understanding. OK, that’s maybe a little obtuse. How about a couple of examples:

1. Giving a presentation for a local user group, the speaker has been through this material dozens of times. In order to keep it fresh for himself, the speaker gives the audience a Twitter #hashtag to use while he’s wading through the material.  He tells them that while he welcomes any questions during the talk, if they ask them via Twitter, he can address them during the appropriate portion of the presentation. A positive of this approach is that all of the gathered questions can be compiled and used to refine the message, establish FAQs, get direct contact information of the participants, and possibly sift through the conversations to find new avenues of business.
2. A downtown venue is hosting a sold out concert event and a few hours before it begins, starts to monitor the backchannel of patrons registered for the event talking about excitement for the event, traffic issues, and what they hope the band will be playing that night. Based on the number of messages about leaving for the event, the venue can estimate when the bulk of the crowd will be arriving. Complaints about traffic can prompt response back out to the incoming fans about alternate routes and which venue gates have the shortest lines. And the performing band can use the desires of the audience to maybe add a song to that night’s set that originally wasn’t scheduled to be played.
3. Getting ready to go out on the town, every couple, family, and group of friends has the same discussion - “Where do you want to go/eat? What do you want to do/see?“. Each person surfing their personal backchannels can quickly come up with new restaraunts or movies that quickly get narrowed down into a decision. Sure, there are web sites and iPhone apps that will let you see reviews of local places, but the power of the backchannel is that it makes recommendations more personal. In the end, all decisions are made with a mixture of logic and emotion and the personal backchannel provides that emotional element when logic cannot choose between two or more equal unknown options.

Obviously, a lot of things need to happen in order to make this work, but the building blocks are all there to do it today. Web Squared, the follow-on to Web 2.0 according to Tim O’Reilly, will help make these mainstream capabilities. Acquiring the data will not be the barrier in making use of the backchannel, rather it will be the sifting and application to their specific needs that will require the imagination and effort. This is why high-end data skills will be one of the hottest markets and job opportunities during the next wave.

It’s Not About Control
You can’t control the backchannel. Don’t even try. The more you try to shape the message, the more you’re not going to like how it comes out. Your job is to enable the conversations, capture them, and adapt yourself based on them. You can take the inputs and transform them into something useful for yourself and others, but in the end, it’s not your message because you didn’t create it, you just allowed it to happen.

Summary
If not officially provided by the venue, sponsor, or host, these backchannel discussions will occur organically. People will make up hashtags or keywords that make the most sense, or follow the lead of their neighbor . Some of these conversation snippets you may be able to find later by randomly looking for tell tale keywords that your audience may have used, but a good portion will be lost into the ether – at least to you. These could have been the most damning comments or those harboring the most praise. In either case, you won’t be able to use them to your advantage if you can’t find them.

I read the pro-Wave viewpoints and I read the anti-Wave viewpoints. Each had good points, and each had “I don’t think they get it” viewpoints. And I waited. Waited for the day when I could try it out and form my own viewpoint.

Fall 2009
Rumors began to circulate that on October 1, Google would be expanding their pool of testers. Maybe, just maybe, my self-proclaimed tight relationship with Google would get me the invite I so desired, or rather “needed”. I needed to be out in front. If Wave leaned even a little bit in the direction of the positive spin, being out on the front in of this “next big thing” could be useful in so many ways. I watched my inbox throughout the day. Nothing. But Twitter had my answer. One of my co-workers had an invite! Know that there were 8 additional invitations attached to each invite from Google. Surely he could give one up! I begged, pleaded, and cajoled, and thankfully – he ponied one up. In my euphoria, I don’t recall if I actually promised anything unfortunate in return. I’m sure he’ll remind me if I did.

Again with the waiting. I continued to watch my inbox. C’mon Google, where’s my invite. Maybe he didn’t really send it. Wait, wait, wait. Still nothing. The conjecture engine on the Internet was saying that Google was hand approving the invites, and a few days later, reports of the “nominations” being released start to trickle out. Still waiting. Tuesday, Wednesday, Thursday….

Driving home from Columbus Thursday night, I got an email “ding”. While driving (yes, I know), I reached down to check who it was from…gasp! Google! It was the invite! I called my buddy Tom. “Dude! Check your email!” A few minutes later he pinged me back. He had gotten his too and I now knew what I was going to be doing that night.

The First Wave
“Look! We’re typing at the same time!” I’m almost ashamed to admit it, especially since chat clients have done that for years – but that was the jist of my first interaction with Wave. Tom and I did that for a while, getting used to the navigation, adding pictures and files, checking out all of the extensions, ‘bots, and gadgets that were available. Essentially, the digital equivalent of kicking the tires.

The Next Day
After getting my fill of the simultaneous typing exercises, I wanted to do something a bit more useful and figured that getting a handle on developing for Wave would be a good way to spend my time. I needed the Google App Engine so I went ahead and downloaded that. Then I chose Python to be my language of choice for creating a ‘bot (Java to me is going to become the COBOL of the 21st Century, but that’s a discussion for another time) and sat down to hook it all up. Aside from some Google instructions that lacked a bit a of clarity, the ‘bot was working a short time later. Satisfied with my progress, I put Wave aside for a couple of days to let the whole thing ferment a bit.

The Rest of the Week
So now it’s been a couple of days since my invite. Tolerance for the “Look, I can see you typing! Isn’t this cool!” comments has waned. If I could kick these people from my wave, I would, but “Delete” doesn’t always work. Overall though, I’m finding good uses for Wave, but so far, all of them are in the collaboration camp:

• Getting feedback on blog entries before I post them;
• Discussion of events or activities (hmmm, maybe a Wave hosted Windows 7 House Party!);
• Group updating of BC/DR or other “living” documents;
• Keeping an internal company list of people to invite to Wave once we have more invites to give.

One idea I really like is using Wave to operate as a backchannel discussion conduit. When I’m speaking about whatever the topic du jour is, having a conversation running in the background can help me direct the event in ways the audience wants it to go instead where I may be forcing it. Similar to monitoring for #hashtags in Twitter. Value for them, value for me.

But there’s got to be more. Maybe replacing Sharepoint as our internal “Knowledge Base”? That would be awesome. Like Twitter, I don’t see it as being a chat tool (at least a general chat tool. Discussions around a central topic, yes.).

It’s a given that Wave will replace our company group mailing list, at least once we all have Wave. Before Wave, we’ve had tech discussions that have lasted for days and have generated 100s of emails. Then, as quick as they start, they’re forgotten. Which is unfortunate because our internal topics generate a lot of good thought and content.

A few other observations:

Stability

Look folks, it’s not even beta software yet. Some options that I really want to work are grayed out. There are times when you can delete things, and times when inexplicably you can’t. There have been a few times when Wave has crashed, but I can count them on one hand after several days of decent use. And I have yet to lose any data (which makes sense as everything is saved as soon as you type it).

Offline

I’ve been able to do a few things offline which then get posted up to the cloud once I get connected. However, I have not tested to see whether anything is stored locally by turning off my laptop. My gut feel is that would be a situation where you would lose data if you’re not connected. If Google Gears were running, maybe…don’t know yet.

Browsers
Most of my Waving has been with Safari (on Mac & iPhone) and Chrome (on Mac & Windows). I did do some Firefox on Windows, and while it worked, mostly, it was the least stable of all the browsers. I may have to try IE just so I can get the error message.

iPhone

The iPhone implementation of the Wave interface is actually pretty nice. It’s a browser still (obviously), but done up to look like an application (you even get the cool Google Wave icon for the desktop). It works the same way as a regular browser does in that you see updates live as they happen (and even though I said my tolerance for people talking about that was waning, seeing it happen on my iPhone was pretty cool). Now if I can figure out how to get things into Wave from my phone (e.g. pictures), that would be useful. The File/Upload function doesn’t seem to work. If I could email content into a Wave that might even be better.

Public Waves

The few of these I’ve been a part of make me wonder what the purpose is going to be. In the current iteration, these public waves can fill up fast (to the point where they can no longer be updated) and the conversations so disjointed that no value can be extracted without mounting a full mining expedition. Some sort of sub-grouping or organization mechanism may be required here to help keep sense of things.

Summary

Wave will be useful. It actually already is even in its not-beta, mystifying usage model current form. The extensions and ‘bots will be part of what makes it a success, and being willing to change the way you think about how information needs to be shared may be the key to really exploring its opportunity.

The Execution phase of our Agile Data Center move is where all the fun stuff happens. As a reminder from the previous entries about the project setup and preparation, we’re doing a data center move where the schedule is flexible (the client is more tolerant of time, less tolerant of risk) and the requirements are somewhat nebulous. Our current migration strategy has us virtualizing as many physical servers as possible as well as using SAN replication as our data pusher whenever we can. Our basic currency is an application (Migration Element) to be moved as compared to a feature or requirement that you would usually find in a software project. Our iterations (Migration Events ) are a week long and occur during the weekly 6h maintenance window on Sundays. Essentially, our goal is to make the migration as a whole the least disruptive it can possibly be.

If you refer to the classic diagram, aka, the Agile Circle of Everything, you’ll see we have five main work areas that get performed during a Migration Event (I’m purposefully leaving out the “Perform Warranty” piece for the moment). Let’s look at each of these work areas in more detail:

• Plan Migration Event
• Begin Staging Activities
• Perform Event Staging
• Perform Event Cutover
• Conduct Lessons Learned

The first task for the Migration Event is to set up a plan of the work that needs to get done over the next period (whatever amount you selected as the duration of each event: week, two-weeks, month , etc.). This essentially is going to be a list of all the Migration Elements that are next in the priority list, or are leftover from previous Migration Events, or even those that have been prioritized up from subsequent Migration Events. If this is the first Event of your overall Migration Plan, you will need to make a somewhat educated guess as to how many points you can get during during the period (your initial velocity). After you complete a few Migration Events you’ll have a better feel for what your actual velocity is, but until then, it’s an estimate.

Select the Migration Elements from your prioritized list, paying close attention to the Migration Groups (this helps assure that you’re getting applications that need to travel together). Based on your velocity (either experienced or estimated), select as many Elements as can fit in the Event. If you have any holdover Elements from the previous Event , those usually go at the top of your list (unless of course they’ve been deleted from the project due to a business change. Hey, it happens.) Once compiled, you have your marching orders for this Event. It’s time to get down to the real work.

Now that you know what it is you’re trying to accomplish, it’s time to start setting it up. In our data center move, we’re anticipating a setup stage where we stand a temporary environment up at the current data center, get the application configured and ready for how it will exist at its destination. Then, in most cases, ship it across the wire though SAN replication or some other electronic other means where it’s stood up in an identical configuration on the other side. There may be some forklifting occasionally, but we’re hoping to minimize it. To manage this process, and the following two: Perform Event Staging and Perform Event Cutover, I’ve created a Migration Element Worksheet that tracks: Element ID, Assigned Migration Event, Assigned Migration Group, Migration Element Sizing, Migration Element Priority, Migration Element Value, Environment, and a progress checklist. This worksheet rolls up to another worksheet which tracks my overall process within the Migration Event, which in turn rolls up to a Burndown Chart.

The metaphor I’ve been using for the migration is a moving truck where, being the Virtualization Guy, means I virtualize whatever application I need to move, throw it on the truck (aka the SAN) and then wait for it to get to the new data center. Once there, I unpack it (attach it to the new host) and fire it up! Obviously I’m glossing over the details of the configuration for the destination environment and testing of the connectivity and the application itself – in part because I’m more concerned with the process of moving at the moment, and in part because we haven’t really worked out all of the details yet. Nevertheless, what I described, while definitely the “happy path”, is how we hope to get the bulk of machines to the new data center.

For virtualization activities that have to deal with high-availability, SLAs, replication, high-utilization, etc. – I’ll make sure my sizing exercise reflects the extra effort required to move these types of machines, but the overall process will stay the same. If during this process I find I can’t get all of the work done as specified in the Migration Event Plan, then I’ll need to defer those Elements (with consent of the business) and adjust my spreadsheets accordingly (although I’ll probably use Pivotal Tracker when it comes time to do it for real).

The last step in the process, “Conduct Lessons Learned” is one that should never be overlooked, even if you have a large number of Migration Events. This is one of the areas where an agile process excels because it takes the tight feedback loop generated by a short Event cycle and turns it into process improvement. Use this time to tweak your Fibonacci scale, determine what’s working and what desperately needs to be improved (or even improved just a little bit).

What about the Perform Warranty step in the iterative process? Once the work is completed and accepted by the business, the Perform Warranty is actually a separate thread of execution following more of a “help desk” set of processes. In the diagram, I just wanted to show the hand-off from the main line of work to that sub-process. Essentially, as we complete a migration, the warranty clock starts running. If that group uncovers anything that needs to be addressed by the migration group, we would fold it in to the next Migration Event at the top of the queue along with any deferred items from previous Migration Event.

Summary
Over these three posts, we discussed a situation where it is possible to use an agile methodology to perform a data center move. The constraints that seem to work include:

• A protracted execution timeframe where the client is more apt to avoid risk than either time or money.
• A strict schedule for performing the migration (in this case during weekly system maintenance windows).
• A willingness to allow elements to “slip ” from one event to the next.
• A nebulous set of requirements and constraints.

These are not requirements, although a systematic, repeated schedule is somewhat. If the client were to do a “big bang” or a more sporadic implementation, then getting the rhythm and predictability required for an agile process would prove problematic.  If you’re interested in looking at my spreadsheets for how all of the things I described above fit together, just let me know via Twitter @nexidecimal.

The Fibonacci sequence is essentially a relative scale of effort required to complete a task.  It’s not meant to be an absolute value of how long something will take – rather, Task A is a lot harder than Task B, but twice as easy as Task C.  The smaller the numbers, the more accurate the sizing should be.  So if I know how to do a series of tasks because I’ve done them over-and-over, then I can baseline those as a “1” or a “2”.  Every task after that becomes a factor relative to that baseline and is based on how much you don’t know about a requirement (or feature) in addition to how much “you know that you don’t know”.

The Fibonacci scale is good for two reasons (and I’m leaving out the obvious “because Fibonacci sounds cool”) each of which addresses a different estimating concern:

1. I know how to do it, so the scale becomes relative to how difficult a task is, or
2. I don’t know how to do it very well so the scale is a measure of how much I don’t know.

In my head, I break it down this way.  Other people’s definitions may vary, but the scale should be roughly the same:

• 0: No effort required.  Or, there is some effort required (possibly not trivial), but there is no value delivered so no credit is given for doing the work. It’s essentially a chore that has to be done.
• .5: I’m a Fibonacci purist that likes to split hairs (the two “1″s in the 0,1,1,2,3… sequence are redundant so some people put a .5 in place of a “1″).  Or, since 0 is reserved for chores that provide no business value, I can use this in place of “No Effort Required”.
• 1: Trivial.  This will be an easy point for my burn-down chart.  I can do these all day to pad my stats.  Or, I underestimate everything I do because I assume I understand the requirement.
• 2: A little bit of thought is required, but I’ve done so many, I won’t even break a sweat.  Or, it sounds trivial, but I’m going to hedge my bets a bit.
• 3: I’ve done this a lot, I know what needs to be done, maybe a few extra steps, but that’s it.  Doubtful that I’ll need to Google anything. Or, hmmm.  I don’t want to overestimate or underestimate, so I’ll stick this one in the middle.
• 5: OK, now we’re getting into the heart of the problem.  Or, I don’t do this very often. I’ll need a fair amount of assistance from Google.
• 8: This is going to take some time and planning. Or, I’ve seen other people do this and I prototyped something like it a few years ago.  I’ll need to buy a book.
• 13: Possibly the maximum amount I can do and still get it done in one iteration or sprint.  If this item is truly reduced to its simplest form, then it’s a complex piece of work and depending upon my iterative velocity, I may or may not be able to get it done in the time required.  For example, if my average velocity for an iteration is “10” or “11” points, then this one task will be a struggle.  If my personal velocity is “16”, then I should be able to get it done, but there’s obviously a lot of unknowns associated with it otherwise it wouldn’t have been given such a high number.  Keep in mind that 13×1 != 1×13.
• 21: I don’t want to do it.  This is designed to show people that it is very complex and cannot possibly be done in the timeframe of an iteration or sprint.  Either the requirements are so fuzzy that it’s rife with danger, or someone keeps asking for something stupid and I want them to go away. Some people put their “21” at “34” or some other higher value.  Some make it an even “100” just to give it some distance from the standard sizing numbers.

One reason why this approach is used in Agile is because for absolute estimating, you need to tie the estimate to the actual person doing the work in order for it to be accurate.  Something that takes you 8h to do may take me 16h, but on a relative scale they can both be the same point value.  The nice thing is, that no matter what, the scale is the same for everybody.  Your “1 Point” and my “1 Point” may be different in regards to how long we each take to execute the task, but the since the scale is relative to our own individual abilities, I should see the same work completed curve as we both work through tasks with the same point values.

For team estimations, there is a nominalization process that occurs to make sure we’re all making the same assumptions behind our sizing.  For example, if I size a task at a “2”, but you throw down an “8”, given we share a similar amount of ability, we obviously are interpreting the requirement differently, or approaching it from different directions.  We get together and hash it out so that the actual sizing estimate is agreed upon.

You can also use the same scale for assigning priorities to the tasks so that it becomes easier to know what to jettison based on time constraints and also for measuring business value for help in prioritization.  The principles are the same.  The lower the number the higher the priority or the more definitive the expected value.  The higher the number, the more a priority is a “nice-to-have” or the more nebulous the value proposition.

I’ve only been able to play with it for a couple of hours thus far and the collaboration benefits are obvious. This weekend I hope to be able to get into it enough to start to see all the possibilities (including writing a bot or two).

1. Migration Element = Feature or Story
2. Migration Event = Iteration or Sprint

Some of the characteristics of Migration Elements are:

1. The base-level of a migration is a Migration Element
2. Migration Elements are assigned relative priorities
3. Migration Elements are assigned relative effort (e.g. 0,1,2,3,5,8,13,21)
4. Migration Elements are associated with like elements into Migration Groups

For those of you used to agile methodologies or projects, these notions should be familiar even though the names have a more Data Center-ish flavor to them.  For the purposes of our detailed discussion, I’m going to use the same major segments of work that we’re using in our project: Preparation, Execution, and Validation. Today, I’ll go through Preparation.  It’s definitely not the fun part of the process, but we gotta do it.

The Preparation
Preparing for a data center move can be a huge endeavor.  Data volumes are measured in anywhere from dozens of terabytes to petabytes.  Mission critical applications, stringent disaster-recovery requirements, and inconsistent backups all factor in to making a thorough and detailed setup for such a project – absolutely key for being able to be successful.  In my current situation, we’re handling the preparation as a traditional waterfall approach, trying to know everything that’s knowable before actually getting to work on migrating systems from the old to the new data center.  Doing the prep work in a more agile way may be more difficult than it’s worth, given the interconnectedness of the applications.  We can’t really take them a company or department at a time and going in we don’t have visibility into all of the systems to know which “wire hangars” we can pull out alone or which ones are hooked together in a big wire blob.  In addition to that, the facility won’t be ready for us until mid-November so the only thing we have to do anyway is plan.

Discovery
Ah discovery.  This is the part where you know next to nothing at the beginning of the stage, and think you know everything at the end of it. Where Planning will be the phase to create my agile flow, Discovery will provide my raw material.  Now, we’ve all done discoveries before, and since the preparation portion of our data center migration project is not really agile, I’m going to gloss over the act of discovery a bit.

For our project, the big things we need to know during this phase are:

1. What are we moving/not moving?
2. How do systems & applications interrelate?
3. What BC/DR and security rules do we need to follow?
4. What are the time/budget constraints?

There are other things too, like strategic directions and all the paths you can possibly take to get there.  But for the purposes of what we’re talking about, we’ll stop the list here.  Hopefully, we are able to put together a lucid set of documents that organizes all of this collected data into information that is usable for our Planning phase because that’s where it all starts to take shape.

Planning
Now that we know everything – at least mostly.  We can start figuring out how we need to fit it all together.  While we’re producing many deliverables as part of this effort, in order to support the agile stuff I want to do during the execution phase, these are the things I need to know coming out of the Preparation phase:

1. Assess Migration Grouping – Which applications and servers go together? What are the upstream and downstream dependencies? Are there any service-level agreements in place dictating which applications have performance requirements, cannot be virtualized, or needs its own box?  Most of this info would have been uncovered during the Discovery.  Here, we need to coalesce it into something useful so I can better plan my Migration Events.
2. Determine Grouping Priority – Which groups are high, medium, and low, priority?  Essentially, who does the business say should go first? This will determine the order of the migration events and if I need to defer an application (or promote one) based on time constraints, I’ll have a good idea of the best candidates for that.
3. Determine Grouping Effort – How difficult will each migration be relative to other elements?  As an example, if an application already sits on a virtual server, it should be easier to migrate than one that sits on a physical server.  Also, applications that touch many other applications will require additional steps and testing so would have a higher effort number associated with them.  The end goal is to be able to gauge my migration velocity for each migration event thus allowing me to track performance and increase sizing accuracy over time.  It also lets me “horse trade” migration elements if the business were to ask me to re-prioritize an element from a later event into my current one.  Just like in an agile project, we’re not estimating hours here.  Whether you call them: units, points, or rocks, the intent is for them not to be time-based. You need to know how complex a Migration Element is relative to all of the other Migration Elements or some sort of standard baseline.  Personally, I use a Fibonacci scale because it gives me more separation in sizing the less I know about it, but feel free to use whatever you wish.
4. Create Migration Event Plan (iteration or sprint plan) – With the priority and sizings now known, I can lay out an overall schedule of migration events.  This would include the number of total events (iterations), the date each migration element would be delivered, as well as the estimated cost.  This plan would be modified over the course of the migrations, being refined by the actualities of the execution, adding or subtracting migration events as necessary (and adjusting the cost appropriately).  Since we’ll be using the weekly maintenance window to do our migrations, I’m going to assume that a Migration Event is 7 days.  I could easily have picked 14 days for two-week Migration Events, but given that my maintenance window is only six hours per week, I’ll leave it at 7 days until the actual migration velocity proves me wrong.

Assuming a one week iteration, where my maintenance window falls on a Sunday, my week could kind of look like this:

My constraints somewhat force me into a situation like this, where an iteration starts on a Wednesday and ends on a Monday.  Whether or not this would be workable depends upon how much migration I can get done in my window.  If I can only get 10% done per Migration Event, then I’ve got 10 weeks of Sundays to look forward to.  Unless I want to go to an every other week schedule or maybe open up the maintenance window for a longer period of time, or even accept mid-week planned outages.  However, if I get 25% done each window, then maybe we can all “suck it up” for that long.  In the end, the business, and the IT folks will decide how to distribute the pain.

We should have everything we need now to start iterating through the work.  I know how long the project should take, how much effort is going to be required, and how much it will cost.  However, the most important thing I know is that I don’t know everything.  My knowledge is still based on estimates, and these estimates won’t be tested until I actually start doing the work and measuring the results.  Once I start getting real data, I can refine these estimates into something a bit more bankable.  I’ll cover that in the next segment.

• 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.