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”
- “it’s just a back door for developers to get sysadmin time (when we should be fixing server problems)”
- “SPIKES (research, architecture planning type stories) lack a solid ‘Done’ definition”
- “team is too large for scrums to be beneficial (overwhelming amount of subjects/topics)”
- “estimating bugfixes is really hard because of unknown root causes”
- “not sure about my exact role on the team if I don’t have assigned stories”
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.
Those developers working alone without your input are causing the server problems!
‘Done’ for a Spike is simply an actionable/understandable user story in the backlog.
If you have more than 12 people on a team, its time to break it up. You’ll get better focus and efficiency.
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.
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”
- “meetings interrupt the daily flow of work”
- “complete backlog and sprint reviews too much overhead”
- “lack a test environment so testing operational work doesn’t make sense”
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.
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.
You need a backlog to plan your work and a sprint review is your chance to showcase your accomplishments to the team.
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!
2 thoughts on “Improving Operations with Agile”
I gave a related talk on agile 2008 on Agile Operations and Infrastructure. It’s a bit unorganized but might still prove useful.
Great stuff, Patrick. Project work often clashes with operations – trying to convince both parties that there’s a common goal in working together is an extremely difficult chore which requires a lot of understanding and even more patience.
I still am convinced that Agile is the best bridge for these two worlds – a methodology that focuses on _deliverables_ not plans.