DevOpsGroup Blog Avoiding the pitfalls of one-size-fits-all Agile adoption

Avoiding the pitfalls of one-size-fits-all Agile adoption

Agile methodologies and frameworks have a firm hold in the world of software development. The most widely used framework, Scrum, has become synonymous with Agile itself for many people and tends to become the default for Agile adoption.

Yet Scrum isn’t without its problems. Even an experienced Agile practitioner can get more caught up in Scrum implementation than achieving the desired outcomes of Agile. It’s easily done, especially given how successful well-implemented Scrum adoption can be within feature delivery teams.

However, as Scrum is rolled out, one team can be left in the corner: operations.

Ops: The Australia of IT

In my experience, operations is usually the last team and workstream to get onboarded. This isn’t because Ops is less important or valuable. It’s just that in many organisations, particularly in the enterprise space, Ops is the Australia of the IT world. Isolated, out-of-the-way and a bit different. The adoption of a rigid framework or new way of working is most likely to hit issues here. Having previously worked in operations myself I can assure you that operations engineers aren’t trying to be difficult. It’s all due to the nature of their work. Let me explain.

Feature delivery teams, once established, usually have a stable, quasi-predictable workflow velocity – the odd production issue or bug notwithstanding. However, in operations teams a massive amount of available capacity can be taken up with unplanned work, toil or firefighting as they support aging systems in dire need of a refresh. Anecdotally, I’ve experienced upwards of 80% of team capacity being spent this way in some Sprints. Surfacing and visualising this unplanned work can be incredibly difficult given its reactive nature. That’s the problem with Australia, there’s a lot of outback for critters to hide in.

The challenge of Scrum for operations

This can hinder adoption of prescriptive Agile frameworks generally, and Scrum specifically, with its reliance on regular ceremonies and commitment to Sprint goals. It’s fine to commit to delivering a specific functionality within an iteration. But if one or two critical systems need more attention than you accounted for the entire Sprint can be jeopardised very quickly.

This leads to frustration, demoralisation and ultimately pushback on the whole process. Why spend time on backlog refinement or planning when the work is never delivered on time or is no longer relevant by the time it’s complete?

Resolving these issues can be a real challenge.

Don’t worry about the recipe when the kitchen is on fire

“What’s the problem?” you might ask. Set up your backlog and start chipping away at that tech debt each iteration, over time the problem goes away. Easy.

In theory? Sure, given enough time and effort you might get somewhere.

In practice? Well let me explain through another tortured analogy.

Agile frameworks such as Scrum are like a recipe on how to deliver value in an Agile way.  Ideally, they provide the chefs (the team) with just enough detail to repeatedly achieve the desired outcome with slight alterations for personal taste. They are also pretty much universally designed for those predictable feature delivery teams mentioned earlier.

So, the feature delivery kitchen is nice and functional. It occasionally sets off the smoke alarm because you forgot to clean the oven but generally has no major mishaps. The recipe works well for the most part. It may need refinement over time, but nine times out of ten you have an enjoyable meal at the end.

In the operations kitchen, however, the more detailed the recipe the more of a hindrance it becomes. The chefs are busy trying to put out a grease fire, half of them occasionally vanish to help in the feature delivery kitchen and the store is out of a critical ingredient until next week.

Best case scenario, through herculean effort and some creative thinking – or more commonly, very late nights – the team occasionally delivers what the recipe asked for. At worst we get cold beans on burnt toast.

Either way the team is left demoralised and resentful at being made to follow the recipe when there was so much to do, and all the while it clearly wasn’t helping. What this kitchen really needs is something lightweight and extremely flexible. And maybe a fire extinguisher while we’re at it.

So, can Scrum ever work?

None of this is to say that Scrum can’t work in an operations team. It absolutely can and I’ve seen it done. But there needs to be a certain level of workflow stability and capability maturity before it’s suitable.

When fires can be snuffed out before they’re noticed and chefs in the other kitchen can help themselves to ingredients already laid out in front of them, everyone can focus on the recipe. When the conditions in the two kitchens are the same, they can share recipes.

So before promoting Scrum adoption to your operations team it’s worth asking; can they work as predictably as a delivery team? Or is Scrum adoption something to aspire to rather than to implement right now? Is there something else that might suit the team better in the meantime?  

If you don’t ask these questions, you could end up with a lot of burnt toast.

If you need support with cloud-based operations and Agile ways of working, DevOpsGroup can help. We offer practitioner-led Agile training and cloud managed services tailored to our clients’ needs.


Leave a Reply

Your email address will not be published. Required fields are marked *