Since losing my job in March I’ve been using some of my time for professional development. One of my pursuits is learning about agile project management with a focus on Scrum. As someone who has spent most of his career in IT infrastructure and operations, I have had limited exposure to agile. Agile is primarily geared towards software development projects, though it can be used for just about anything. I’ve been seeing and hearing the term more and more often, including in just about every project management job ad.

My recent research has consisted of:

• The ITProTV Agile Scrum Master course
• Two seminal books by Mike Cohn, one of the founders of the Scrum Alliance
  o Succeeding with Agile
  o Agile Estimating and Planning
• Several blog posts and articles on the web related to agile IT infrastructure practices

At this point I’m sold on the advantages of agile. Cohn does a great job of backing up the advantages with studies. For my part I am interested in exploring how best to utilize agile practices in IT infrastructure projects and potentially operations. Following are some observations on the subject based on my research:

Agile is incompatible with fixed fee contracts
Okay this heading is a bit bold (har har), but there’s definitely a lot of truth to it. I worked for an IT managed service provider the past couple years. Most of our client engagements were in IT infrastructure hosting and management. And most of our implementation contracts with our clients were fixed fee. Fixed fee is common in projects with a well defined, well understood product or service being delivered.

One of the tenets of agile is to welcome change – to scope, budget, schedule. If the client realizes that an additional feature would be very useful or that they no longer need a certain aspect of the product, we should oblige them. Scrum in particular eschews detailed contracts that attempt to lock down scope. This is at odds with fixed fee contracts. With a fixed fee contract, the project manager is incentivized to prevent scope creep so as not to add work that will drive the project over budget and late. There is typically a formal scope change process which makes the impact clear to the client.

So I would conclude that agile projects should be T&M or similar. It’s fine to provide some estimate up front, but the client must go into the engagement with eyes open to the fact this is an agile project and they should have an understanding of what that means. It ultimately benefits them, but there are expectations of them as well. I recently interviewed with a company in the software development and customization world and I asked about this in the interview. They indeed bill T&M and agreed that their projects and agile practices would not work with fixed fee.

Thou shalt form squads
I am not a big fan of marketing terms or catchy terms people come up with for things. I’m still getting used to user stories and daily scrums. But in my agile research I did find one that I like – SQUADS! As best I can tell this is not a scrum term, but I have been hearing it in agile contexts. I take it to be synonymous with agile teams. A squad is a multidisciplinary team. In the software development world the team may consist of developers, database designers, UX designers, architects, testers, etc. In the infrastructure world a squad may include systems engineers, network engineers, DBAs, ops folks, etc. The idea here is to eliminate delay inducing hand-offs between functional teams and to build shared accountability and camaraderie. I actually applied for a job the other day with a title of Squad Manager. Pretty badass, huh? This comprehensive McKinsey article discusses how squads work in an infrastructure organization. In my experience smaller IT departments of say 20 or fewer are already in effect a squad. They tend to be collocated and in frequent contact. Though sometimes inserting different functional managers into a group of even this size can create barriers. The article suggests that in larger organizations infrastructure squads should be formed around applications or services. So maybe there’s a storage squad or a squad for a particular SaaS application. These squads can work in an operations mode or executing projects in their line of business.

Automate early
Automation has been a hot button topic in IT infrastructure for many years. From shell scripting to automation software packages to the cloud. Larger organizations have usually led the way due to the imperative to scale and the lack of scalability of manual processes. In agile software development, automated tests are critical. There is no test phase at the end of the project. Unit testing happens during each iteration as code is written. Integration testing may be run on a nightly basis against the code checked in end of day.

In the infrastructure world, automated testing or verification is nice to have – like comparing a farm of web servers against a configuration baseline perhaps. What’s even more critical in an agile world is automated operations. Like the use of squads, automation enables an infrastructure organization to become more responsive. Can we spin up a server or push out a configuration change to all our routers with the click of a button? Can we facilitate DevOps by providing self-service options to our developers?

In the project world, I think the usefulness of automation comes in either when working on large projects where a piece of infrastructure will need to be deployed many many times or in the case where you’re executing basically the same project over and over as does a service provider selling Office 365 for instance.

Projects vs. Operations
I think that agile practices can work both in the project world as well as daily operations. Certainly the particular practices I’ve covered in this article can be effective in both. One question I have is how this is all going to work cohesively in an IT organization? I don’t think adopting every agile practice is practical. IT folks need to use some common sense and adopt what makes sense in their particular environment.

For example, Cohn greatly prefers sticking to index cards for managing user stories, sprint tasks, parking lot charts, etc. But try to imagine a service desk that uses index cards for their service tickets. I think someone could make a pretty funny YouTube video on that premise, if they haven’t already. So do you use two systems, an analog one for project management and digital for service desk? Or do you try to find one that does it all? From the perspective of someone who has done reporting of service desk and projects side-by-side, I’d rather have everything in the same database. But maybe it’s better to just find the best system for each job. And while you can maybe put services into operation or perform continuous improvement in iterations, can you operate a service desk in iterations? Probably not. But you can certainly have a daily stand-up to prioritize tickets, review urgent tickets unresolved the prior day and make a game plan.

Your whole IT organization must be agile
If you have agile development teams in your organization, you must have agile infrastructure teams. At the very least you must have heavily automated processes for deploying infrastructure and you must be able to respond to requests from developers quickly. And you should probably have infrastructure representatives sitting in on development daily scrums or at least sprint planning meetings. This way you know what is coming your way and you even have some input.

The consequences of isolating agile to development are well covered by Cohn in “Succeeding with Agile”. At best, inability to complete user stories in some iterations. At worst, a backslide into old ways of developing software. In his book, Cohn provides strategies for getting HR, Facilities and the PMO on board as these are key groups needed to support agile development.

When not to be agile
Okay this is an intentionally incendiary heading. Of course we should always be as agile as possible given the constraints we are under. But in thinking about many of the infrastructure projects I’ve worked on, I would say that a lot of them were sequential by nature….. with many interlinking dependencies. And forget about having a “potentially releasable product” every two to four weeks. That just doesn’t make sense. For this type of a project, does it does it make sense to utilize an agile methodology? I don’t think there’s a hard and fast answer. I think one should employ as many agile practices as possible given the situation. If you are performing a virtual server migration where you are migrating servers in groups over the course of several months, there is an inherent iterative nature to the work and greater opportunity to be agile. In a more sequential project, one can still borrow practices like a daily stand-up meeting and keeping the team small and collocated if possible. One can display big visible charts and dedicate some time to building automated verification tests (if this type of work will be repeated).

One of the big reasons agile software development de-emphasizes up-front planning and estimates work with a unit-less measure (story points) is the acknowledgement that we cannot know the end product with any real clarity before we start building it. It is a waste of time and effort to do a detailed requirements analysis phase. And schedule estimates made before execution begins will inevitably be wildly inaccurate.

With infrastructure projects these things are typically less true. Sometimes we know the end state with a great deal of clarity. Although I can also think of countless instances where the project team and the customer had mismatched expectations. In that vein I try to use historical data to estimate whenever possible. I also employ what the Project Management Institute calls rolling wave planning, which basically means to plan out the first execution phase in detail and later phases in less detail – maybe a milestone plan only. Then break out details of the later phases just before execution starts. This doesn’t help at all with estimating schedule, but it does move planning to more appropriate times when we have as much information as possible to make decisions.

My point is that an infrastructure PM on a sequential project can utilize a waterfall methodology AND adopt certain agile practices as appropriate. I don’t know how an agile purist would feel about this, but I can certainly envision situations where this would be the best approach in my mind. I am very interested to learn how IT infrastructure and operations folks are utilizing agile practices, what successes they’ve had, what pitfalls they’ve run into and some of the adaptations they’ve come up with to suit their situations.