Agile

It’s not a mandatory part of DevOps, but I believe that DevOps works a lot better if operations teams adopt Agile. But all that most systems teams know about Agile is that “it’s that thing that makes the development teams not plan worth a damn any more.” Well, though there may be some truth to that, a well run agile process is very effective and not uncontrolled at all. Constructing and maintaining infrastructure in an agile manner is very possible – we’ve done it. In the beginning it seems daunting, just as it did initially to the legions of software developers who were steeped in waterfall based thinking, but once you adopt it I think you’ll see a lot of traditional pain points get a lot better – that was our experience. This is the first in a series of posts about using Scrum for Web operations, and I thought I’d start with explaining what Scrum is from an ops guy’s point of view.

While developing our first two products that we delivered on the cloud using DevOps, we used an “agile-ish” methodology, which is to say not a formal agile approach. This time, we’ve decided to run Scrum by the book, not just for the feature developers but for our systems engineers, operations staff, security engineers, and system automation developers. Some folks are talking about hybrid models like Scrumban (Scrum + Kanban/Lean) to better incorporate ops work, but we’re going to start with Scrum first and see where we get to.

As a system administrator, that’s scary, because we don’t know Scrum. But Scrum is pretty darn simple.

But if like me you think videos are not an efficient method of conveying information, here’s the short form.

The Team

In Scrum, you form a small crossfunctional team to all work together on a product instead of having to cross organizational boundaries and fill out forms to get any work done. The roles consist of:

product owner – the “business guy” who has say over what features get greenlit and when

scrum master – the project manager who keeps everyone on track

team – ideally 5 to 7 developers writing code (this is where Ops will plug in, in DevOps)

testers, security, other folks – probably should be included too, but adoption of that varies

Of course in a mid to large sized organization there are other stakeholders, like customers and management and legal and whatnot. But you form a team that has everything it needs to complete its work.

The Backlog

All needed features are brainstormed and put into a master list of features called a “product backlog.” This backlog contains everything – including your systems tasks. The backlog is then broken up into smaller chunks, like release backlogs (features targeted for a specific release) and sprint backlogs (specific tasks for a sprint). The sprint backlog is basically your work breakdown structure, if you’re more comfortable with that terminology, except that the tasks are worded more in terms of what feature they provide instead of in terms of what specific things you need to do; this fosters communication with the product owner.

The developers (and, ideally, operations staff) on the team help generate the backlog and provide time estimates in hours for each task. The product owner owns the prioritization and ordering (as constrained by things that are actual dependencies).

The Sprint

Work is performed in month-long iterations called “sprints.” Requirements are frozen for the sprint and the development is time-boxed – it must end at the termination of the sprint. At the end of the sprint, whatever features were put in that sprint should be complete and “ready to ship.”

The Standup

As the scrum, or sprint, progresses, there are daily “standups” – 15 minute meetings where everyone stands up, reports what they have done since the last standup, what they plan to accomplish by the next standup, and any roadblocks they are encountering. By keeping this meeting short it doesn’t waste time, but by having an actual face to face meeting you get very rapid and effective collaboration that cannot be achieved via managing project plans, sending emails, generating status reports, or the like. It cuts out all the busywork and keeps the kernel of coordination that lets a team keep up velocity.

The Burndown

The progress of the team against the sprint backlog is tracked by a “burndown chart.” As each team member completes their tasks for the sprint you can easily see whether you are on track for successful completion or not.

And that’s Scrum in a nutshell. Five things. Small integrated team, backlog, sprints, standups, burndown.

Next Time

I’ll talk about each of these areas more in depth later in the series, as we go through them ourselves as we develop a real product, and explain how a system administrator (aka systems engineer, infrastructure admin, operations ninja) can fit their work into this structure. But first, I will explain why Agile/Scrum is not just “crazy talk.” To a hardened system admin, or really to anyone used to working in a waterfall environment, it is very counterintuitive that this approach doesn’t just degenerate into the IT equivalent of orcs pillaging a city. But agile has several interesting practices that make it work, and should be very interesting to an operations person.

4 responses to “Scrum for Operations: What Is Scrum”

Thanks for the introduction. I had a few items that I’m wondering whether future articles will cover.

The goal of a sprint seems to be focused around getting software ready-to-ship or ready-for-release-to-production and not “released”. There are many tools and processes available to make deployment very easy but they don’t seem to be a part of the Sprint. In my admittedly limited exposure to Scrum, deployment is where many of the infrastructure and operational issues surface and is probably the reasons behind the poor-planning criticism. In practice (and not theoretically or idealistically), where does deployment actually fit within scrum?

In larger organizations, it’s not unusual for the “network guy”, the “firewall guy”, the “server guy”, the “web guy”, the dba, the network and enterprise management guy, and the security and compliance guys to be completely different people. DevOps seems to be all about getting Development and Operations communicating and working together during Sprints but with deployment not necessarily being part of the Sprint, what type of work gets done with Operations during a sprint? And which Operations folks?

I have many questions on agile operations and devops so I look forward to reading more of this series.

Definitely good questions that I plan to try to address. The short form is that continuous deployment is one of the earliest places ops people can bring value to the devs. Even traditional desktop software shops wrestle with this, ours has an “installer guy” and a team that blows new images onto PCs for testing, and ops deployment slots in here. It’s one of several things that’s not called out as part of the sprint because it’s assumed to be a pervasive underlying thing. CI is probably one of the biggest DevOps talking points.

And working in a bigger shop, I definitely see the issues with figuring out how to include different kinds of tech specialists into the process. The good news is that devs have specialties too, and have come to a kind of equilibrium on that front.

I plan a whole article on “so where does ops slot into this?,” in addition to one on pervasive practices that make agile work, and then it’ll be more lessons learned as we actually do it.