Improving Operations with Agile

wapster

Last week, I suggested that SysAdmins are much more agile than we give them credit for. But, when it comes to organizing their day-to-day work they need just as much help as the rest of us. Today, I want to talk about how agile methodologies work just as well in operations as they do in development.

Roadblocks to Agile SysAdmin Project Work

I presented a couple of lists which listed some negative sysadmin impressions of agile in project work. Let’s take a closer look:

• “hasn’t helped inter-departmental communication”

Organizational problem that doesn’t place enough emphasis on the team, continuous integration and releases. If these 3 things are done correctly your communication will be rock solid.

• “it’s just a back door for developers to get sysadmin time (when we should be fixing server problems)”

Those developers working alone without your input are causing the server problems!

• “SPIKES (research, architecture planning type stories) lack a solid ‘Done’ definition”

‘Done’ for a Spike is simply an actionable/understandable user story in the backlog.

• “team is too large for scrums to be beneficial (overwhelming amount of subjects/topics)”

If you have more than 12 people on a team, its time to break it up. You’ll get better focus and efficiency.

• “estimating bugfixes is really hard because of unknown root causes”

It’s just an estimate! Don’t spend so much time on it – important is that you estimate the next “similar problem” in the same way.

• “not sure about my exact role on the team if I don’t have assigned stories”

Get involved – surely there’s something interesting going on that you’d like to work on with a developer? If not, you’re probably in the wrong team!

Roadblocks to Agile Operations

• “impossible to plan daily operations work as it’s highly reactive”

For every critical incident in production, add a “Root Cause Spike” to your backlog (prioritized accordingly). Address root causes and you’ll shift your work from reactionary to planning.

• “meetings interrupt the daily flow of work”

Communicating with your peers is why you come to work. A regularly scheduled, 10 minute stand-up meeting is about as painless (and informative) as things get in agile.

• “complete backlog and sprint reviews too much overhead”

You need a backlog to plan your work and a sprint review is your chance to showcase your accomplishments to the team.

• “lack a test environment so testing operational work doesn’t make sense”

Well, at least they realize they’re lacking something. Deploy changes to a test environment first and don’t turn your customers into guinea pigs.

Examples of Successful Agile Operations

Andrew Shafer (of Puppet fame) made a comment last week that “Operations is evolving” and made some excellent justifications in his post “Agile Infrastructure”. He asks “How does it change things when your infrastructure is code? Can be versioned and diffed? Can be shared and reused? Can be tested? Continuously?”

Well, Shopzilla engineers and sysadmins have been doing exactly this for almost a year now. Listen to part 1 of the podcast in this Redmonk post by Michael Coté with Luke Kanies (Puppet) and Abe Ingersol (Shopzilla). About 15 minutes in, Abe starts describing how strange it was for the sysadmins to start doing sprint plannings and retrospectives but also how much more successful they have been as a result. Less time putting out fires and more time playing ping pong! Even Microsoft employs agile in its operations department!

Hopefully, I’ve piqued your curiosity by now and you’re wondering about the first steps. I’d suggest you do a basic value stream map, and then start thinking about user stories in the operations realm. Mike Cohn wrote a great post just last week about how to wrap non-functional requirements as user stories. Go out there and have some fun – and good luck!