Is scrum or kanban really useful for SRE teams?
More nuanced & Long-form answer:
Speaking from many experiences at various software companies:
Niether strict Agile nor strict Kanban has ever truly "worked" for any Operations team that I've seen. Whether the company leadership labeled them as the "DevOps Team", "SRE Team", the "Core Operations Team", the "Platform Team", or any other label for that type of Ops work, those strict type of methodologies were never a perfect fit for all the unplanned and ad-hoc work. No matter how hard the company leadership tried to shoehorn the team into some form of those methodologies.
The reasons were due to all of the bullet points you mentioned above:
- The work is very dynamic in nature, with priorities changing on a daily basis. Because of this, the sprint duration of two weeks seems very aggressive and it adds unnecessary overhead.
- People being on call adds another dimension to the problem. Sometimes, more than one team member might get involved in on call / post-mortem tasks.
These ones are precisely the issues why Agile sprints are not useful. The type of work is very dynamic in nature. Planned vs. Unplanned work constantly compete for the Ops/SRE/DevOps/Whatever-you-label-it Engineer's time, bumping and shifting priorities as the "sprint" goes on. Most Agile practices such as "planning poker", or adding "points" to stories/tasks, also fail due to the "Planning Fallacy". This is a built-in cognitive bias that all humans share. It means that we tend to underestimate the amount of time it will take us to complete a task. Supposedly the Agile methodology has this concept that is alleged to alleviate the issues caused by the Planning Fallacy and the "Mythical Man-Month": The "Story points" system.
Most planning-poker style meetings on Software & Ops teams either used a "T-shirt size" (
Large), or fibonnacci number point system, which had no basis or equivalence to "time", by design. This exercise was by definition intentionally useless to estimate time, although leadership at these companies expected it to do so thanks to their conflation of the Agile methodology's concept of "cadence" and the average number of points that were assigned to these tasks in a sprint. These average point estimates changed and evolved over time as team members, tasks, and projects all changed. Unfortunately, the planning fallacy also applies to non-time-based difficulty estimates, because most all humans are overly optimistic about how difficult an unknown problem or task might be. For unknown or unplanned tasks, the actual difficulty can wildly vary and is not actually plannable.
So, all of the above results in lots of carryover of tasks to the next "sprint", whatever time period is chosen for a sprint cadence. As things change (change is the only constant), the point system estimates change too. However, managers' and company leadership's expectations generally aren't as flexible. This sets the team up for failure, because it's inevitable that at some point things change enough to throw off the sprint estimates.
Reliability & Ops Engineering is not a "sprint", it's a marathon.
- The team doesn't have a single "product" and hence it doesn't yield itself to a common planning process
This is another aspect describing the same dynamicity of the type of work mentioned above.
- Daily standup meetings may not make much sense because of the lack of overlap among tasks. The team might be working on tasks related to more than one partner teams and hence spanning multiple Jira projects. Since a sprint or kanban board allows only one Jira project, it may not be able to fit in all the work.
This is yet another reason why most Agile methodology concepts do not fit this type of work. Working across teams & projects is very common for Ops teams. Overlap is rare when working across teams unless there is an underlying common infrastructure that these teams all depend on.
Every single company ended up doing some form of loose Kanban in the end. That is to say: A board was used to track tasks and these were organized by priority. The team was encouraged to limit tasks in progress so as to not become burned out, or overwhelmed by context switching. There was no usefulness of tracking cycle time, nor any of Toyota's Kanban metrics.
These were software companies, not car factories.
The usefulness of strict Kanban was very debatable, due to the fact that it was developed at a car factory. Factories have processes and machinery to fabricate the same type of parts repeatably. Software engineering and Operations are not like a car factory, even when you try to make things repeatable and deployable by putting them into containers. Containers just hide the internal complexity, they do not eliminate it. For these reasons, strict Kanban also is not useful for this type of work.
The SRE & DevOps methodologies themselves, and the type of work involved are at odds with the Agile methodology, which was developed with Software Engineering in mind, not Operations. I've observed many dysfunctional software companies where development teams can chuck things over the fence and call it "done", and then tell Ops to deploy them. They then expect Ops to keep all these plates spinning until the end of time. There is no end point unless a product or service is decommissioned. Additionally, those companies made the mistake of not building in reliability into the product from the beginning of the product lifecycle. This is a recipe for Operations Team burnout and overload when all these complex pieces of software start building up and breaking in complex ways. The company leadership did not scale the Ops/SRE/DevOps team appropriately, nor did they allow Ops Engineering or Developer Engineering time for reducing toil.