gruntzooki
In trying to crack this conundrum myself, I decided to ask sysadmins directly – “What do you think about agile? Would you consider using it in your daily work?”
Here are their responses:
SysAdmin Impressions of Agile within Project Work
| Pros | Cons |
|---|---|
| more communication/contact/awareness among team members | hasn’t helped inter-departmental communication |
| well understood practice that gives everyone a common ground for approaching their work | it’s just a back door for developers to get sysadmin time (when we should be fixing server problems) |
| scrums put more focus on running daily tasks | SPIKES (research, architecture planning type stories) lack a solid “Done” definition |
| velocity is great at managing expectations | team is too large for scrums to be beneficial (overwhelming amount of subjects/topics) |
| structured work where everyone understands priorities and schedules | estimating bugfixes is really hard because of unknown root causes |
| product owners have dedicated teams to create business value | not sure about my exact role on the team if I don’t have assigned stories |
| sprints provide a stable time frame for completing important tasks | some planning games come with pre-defined (i.e. unfinished) stories |
SysAdmin Impressions of Agile within Operations
| Pros | Cons |
|---|---|
| planning and daily standups a good starting point for organizing work | impossible to plan daily operations work as it’s highly reactive |
| would help with prioritizing stories | meetings interrupt the daily flow of work |
| assigned project manager would ease transition and help kickstart agile | complete backlog and sprint reviews too much overhead |
| backlogs would help focus & coordinate the team’s work | lack a test environment so testing operational work doesn’t make sense |
SysAdmins Are Agile
Reviewing the Agile Manifesto summary:
When it comes to soft skills, we all know that most SysAdmins point people to the trouble-ticket system and would rather back patch their FreeBSD server than sit in any meeting. But, in the next point, if you replace the word ‘software’ with ‘systems’, we know they absolutely love making things work (even if there might not be much documentation lying around afterwards telling how they did it). They’d much rather get a quick overview of the customers’ needs and go off to configure a few servers to demo a basic running website than draft a detailed contract for expected work in the coming month. And how many admins do you know that would follow some task list when the web servers are on fire?!
I think Operations folks are much more agile than we give them credit for (and even what they might believe about themselves ;). But, the question remains – how can Agile methodolgies help SysAdmins in their day-to-day work? Tune in next week, and I’ll tell you how!
Agile Web Operations 
Operations is evolving. I think Agile plays some role in that, especially in situations where the ‘application’ runs on many servers.
Shopzilla runs all their operations with Scrum. This podcast is about Puppet, but Abe Ingersol from Shopzilla talks about their process a bit.
http://www.redmonk.com/cote/2008/10/10/puppet-at-shopzilla/
LikeLike
Thanks for the links, Andrew! I’ll definitely take these into account in my upcoming post.
I also think ops is evolving (one of the reasons why we started this blog actually). I have so many friends in this area that I don’t want to see be left behind – especially, when I know they are already so close to ‘living it’ 🙂
LikeLike
I’m running a sysadmin department where we experiment with agile concepts. Some of them do not work very well others are not so much.
Daily standup, prioritized backlog of larger projects and so forth. There are of course issues in how to handle events (the reactive part) but for us there has been a clear improvement in visibility.
LikeLike
Visibility is certainly one of the most obvious improvements you get with agile.
As for the reactive part, I had a lot of success in adding user stories to the backlog for determining the root causes of any “critical incident”. The more critical the event, the higher priority the root cause story had and the sooner it was addressed.
By fixing root cause problems during our plannable time (within sprints) we drastically reduced the overall number of critical events. This gave us more time for planned work where we were able to shift focus on preventing such events from ever happening – an upward spiral of planned over reactive work!
Thanks for sharing, Niclas!
LikeLike