This week has been a fun one in my world, having multiple conversations of trying to apply project management methods to DevOps personnel. The problem, of course, is the "Ops" part of the DevOps cycle: being responsive to unknown, unqualified, and unquantified requests from an internal or external client.

"The Agile Manifesto is a crock." - Charles Lambdin

More specifically: "If the Agile Manifesto had been framed as a hypothesis, and conducted as an experiment, the hypothesis would have been found false."

There are a lot of good things to come out of the agile paradigm for modern software development. The speed of delivery is closer to the speed of operation, but during this process we've lost our way.

Agile was - and is - a way to address needs in software development, specifically reducing time to delivery and speed to market in an age where you're more likely to win the whole game if you're the first one on the board. Not guaranteed, mind you, but first.

Along that path, managers have tried to drag all sorts of IT organizations into "agile."

Great. I've been saying for 7 years that some things work great about agile. Daily or semi-daily stand-ups: GREAT. For EVERYONE! It's basically a shift meeting. If you are doing it right it is quick, to the point, assignments are verified, and if there are issues, they do not fester for more than the period between these meetings. It is a great way to get ahead of issues and address them before one person's little problem becomes an entire team's big problem.

I have also been saying for that long that some things really don't work about agile - especially for operationally oriented teams that are driven by specific client (internal or external) needs.

For example: how does one sprint plan for an L1 or L2 engineer that has a job completely oriented around a ticketing system and on-the-fly service requests or issues? Metrics and trends might work okay if there is sufficient data to develop a baseline, and then assigning point values to the sprints - but that does not really impact planning in a positive manner.

Alternately, what if one single portion of a job is project oriented, but the rest is operational? The split could be arbitrary, 33/66, 50/50, 90/10 - unknown and irrelevant. If tasks are assigned based on points, and the points are made up and the do not actually matter.

This is, of course, specifically targeted towards using Scrum methodology to implement an agile workflow. It looks nice on paper for organizations that gotta go fast! Again, though, it is an idea that works best for delivering a product, not supporting things.

Think about it this way: I am a manager at Bluto's Fried Chicken or "Bluto's" from here on out, an internationally renowned QSR, or fast food joint, that is famous for its bucket-o-lard fries (but not really its chicken). My employees work 11-8 with a variety of breaks from Tuesday to Saturday. On Tuesdays, the team comes in 30 minutes early for a planning meeting.

At the beginning of each week, at that planning meeting, everyone is assigned "points" and their tasks are put on the board. Some tasks are quantifiable: janitorial, fry station, packing - but register detail is always tricky. The points assigned to working the register are based on the number of orders, which fluctuates. Meaning the person taking orders at the register is usually either in crunch time or underutilized - because the points are assigned based on an average.

This is often how it is when I have encountered Agile and Scrum being applied to operations roles - there may be known, routine, repeatable tasks, but there are often tasks that have no qualifiable metric, so the scrum master (or manager, or whomever) glosses over it and does things like take the total average points for the week (in a 50/50 split), halve it, and then assign half the points to "operations tasks" and the other half to project tasks.

Arguably that's functional, but the operations tasks take priority. So what if there is a particularly needy client? Suddenly the entire day is blown assisting them. The points do not change for the rest of the week, so very likely the ops person is under water or something on the project side gets dropped. Usually both. How does one handle multiple days or multiple people running in to this problem?

In some organizations, there are project weeks and ops weeks for split personnel, so as not to run into this issue. In other organizations, ops personnel are completely left out of the agile cycle because the work is too unsteady; instead they're coached to help pick up tasks when possible. Both are adequate, but one of the goals of any methodology is to understand the work completed versus the work scheduled, and refine the next assignment period accordingly.

Finally, here is a true conundrum: at Bluto's, they tried the first method. Time at the register is half-a-shift, all other quantifiable tasks are the other half. So points are halved and assigned based on known time to execute - one half of one work week. This all gets thrown off, however, when someone is not present - the same way it is in a split-scrum for ops personnel everywhere.

I think the second solution is better: if there is a dip in need and the register folks are underutilized, they should be trained to do other things, or at least ask for tasking. By the same token, an ops lead should be able to tell when the ticket flow dips and pull someone to do something else if the team is not made of self-starters.

I do not think either solution is perfect for operations. Support tasks, register time, or whatever the unquantifiable metric is does not lend itself to completion of project based work.

Possibly the most effective is changing a person's work pattern from week to week: Ops 100% or project 100% but that is still impacted by the fact that if personnel are unexpectedly unavailable, the delivery schedule can be thrown off.

So DevOps personnel are stuck by the very nature of their jobs, especially if they really are straddling the line of "Dev" and "Ops" Is there a solution? Yes, sort of, as noted above.

Is it a truly viable project management technique for DevOps personnel? It's certainly better than more static methods.

In the end "it works well enough" is probably better than "we just don't really do anything," but the idea that Agile is the correct path to follow for DevOps personnel and attempting to enforce the paradigms of Scrum has led me and many of my peers to quite a bit of heartburn.

Finally, project management is about understanding the process and making it repeatable, being able to estimate time, resources, and materials, and having a reasonable expectation of accuracy. Agile may help with this for any static items, but dynamic items like support tickets or service requests do not work well with that paradigm, and going down that path is a losing prospect.