Agile Guardrails: An Alternative to Methodologies

Introduction

I recently wrote about the limitations of the Agile Manifesto when adopting agile. Following on from that I thought I would look at the limitations of agile methodologies, and discuss why guardrails prove an alternative — or complimentary — approach to putting agile software delivery into practice.

The Limitations of Methodologies

Agile adoption tends to be dominated by methodologies — Scrum, Kanban, LESS, SAFe and so on. And this is not altogether surprising. Fundamentally lean and agile are about a set of principles, and translating principles into practice is hard. A set of principles with no guidelines are much like ingredients with no recipe. The various methodologies provide a recipe. These recipes can be helpful, but the danger is that following the recipe becomes more important than the results that recipe achieves.

Methodologies become counter productive when we understand what we should be doing but not why. To be clear, I am not anti-methodologies per se. They form a useful part of my toolkit. However, the goal is to achieve agility, not to adopt a methodology.

Rather than focus on methodologies, I have found it helpful instead to use a set of guardrails to guide agile adoption. In this article I’ll discuss the purpose of guardrails and share a set that have worked well for me.

Using guardrails

Back in 2018 I attended a training course on how Spotify practices agile. One of the many useful things I picked up was the concept of “Minimum Viable Agility” (MVA). This is a concept Spotify had adopted from Em Campbell-Pretty’s book Tribal Unity. In the book MVA is described as follows:

Consider the minimum level of agility you expect from teams and make this the only constraint you place on their work practices. A number of practices that have close to universal applicability.

Spotify’s Minimum Viable Agility

The “essentials at Spotify” are non-negotiable — these are things teams must do. Outside of these, teams are free to choose how they work.

I was really inspired by the idea of using guardrails. I see them as an alternative form of “recipe” — a different way to help teams translate principles into practice. I have found they provide enough practical guidance to adopt agility whilst also giving teams the autonomy to tailor their practices and processes to suit their particular context. A team practising high tempo experimentation has a very different context to a team building a large feature. A good set of guardrails can ensure both those teams achieve agile working whilst allowing them to adapt their ways of working to their own particular needs.

Defining Guardrails

When it came to defining my own set of guardrails, I started by being clear about what they should achieve. I have previously written that I define the goal of agility as working in short feedback loops:

The goal of agility is to work in short feedback loops. Short feedback loops are important because they allow us to learn, validate and course correct early.

By course correcting early we can:

• Avoid waste and increase value by ensuring we’re building the right thing — that ultimately, the products and services we create meet our customers’ needs and drive value for the business.
• Avoid expensive mistakes and improve quality by ensuring we’re building the thing right. Early validation that our software behaves as expected ensures we’re building reliable, resilient products.

In summary, agility means optimising to work in short feedback loops so we can increase value and improve quality.

I would argue that as long as we are working in short feedback loops, the methodology or framework within which we work doesn’t matter too much.

With this goal in mind, I worked backwards to define a set of guardrails that would define how to work in short feedback loops.

Delivering in Short Feedback Loops

Through long and often painful experience, I have learned that delivering in short feedback loops is actually quite straightforward. I have boiled it down to this simple formula:

Small batches + Limiting WIP = Short Feedback Loops

I have consistently found that if work is broken down small and there is a focus on finishing work (using WIP limits) short feedback loops are achieved. So these form the heart of my guardrails. Beyond these are some additional supporting practices that I believe are valuable.

My “Minimum Viable Agility”

The guardrails I’m going to describe work well for software development. While the concept of guardrails is holistic, I wouldn’t automatically use this particular set outside of software development. Practical guardrails for a marketing team might have some overlap but wouldn’t necessarily be identical. It’s also worth noting that these guardrails are specific to software delivery — they presuppose that discovery has been completed and we are confident that we are “building the right thing”.

This is my default set of guardrails which I then tailor as necessary.

My default “minimum viable agility”

The image briefly summarises the purpose of each guardrail, but here is a little more context for each.

Define goals and measures of success

As I described above, one reason to work in short feedback loops is to increase value. Before we build anything we should understand what value we expect to deliver and we should know how we can measure the success of our deliverables.

Measure platform health

The second reason to work in short feedback loops is to improve quality. If we are measuring quality we can ensure that this is indeed being achieved. I have also found this particular guardrail reassures teams that we are not trying to increase speed at the expense of quality.

Work in small batches & Limit work in progress

As discussed above, these are the critical elements that achieve short feedback loops. As “small” is relative, I find it useful to be specific about what “small batches” actually means. I adapt this depending on context, but by default I suggest that “sprint level” stories and tasks are small enough to be completed in 3 days or less. So the workflow from “To Do” to “Done” (on production) should be achievable within 3 days. However, this depends on having feature toggling capability and continuous deployment. Where those don’t exist this number will be challenging — although it is definitely worth having it as a goal to work toward!

WIP limits are dependent on the team size and shape so they cannot be prescribed. I encourage teams to consider board and column level limits and experiment to find the optimal set. As a rule of thumb I recommend a board WIP limit the size of the team — so if there are 6 people in the team, aim to have no more than 6 items between “To Do” and “Done”.

Visualise work & Hold daily stand-ups

Both of these support limiting work in progress and encourage teams to focus on finishing. While visualising work highlights bottlenecks, stand-ups provide the opportunity to discuss and resolve them.

Stand-ups are often run as status updates, but I find they are more valuable if used as a short planning session for the day ahead. By walking the board and focusing on tickets rather than people, the team can decide where to spend their effort that day in order to keep work moving and get it completed.

Hold regular retrospectives & Measure cycle time

Both retrospectives and measuring cycle time support continuous improvement. Retrospectives are the feedback loop to ensure teams have time and space to inspect and improve how they work. They should be “regular” to keep that feedback loop short — as with everything else, we want to course correct early.

I’m a huge fan of data-driven process improvement and there are a host of metrics that I use, but cycle time is the daddy. Cycle time measures the length of our feedback loop; as that is ultimately the goal, it is the one metric I consider to be non-negotiable. Retros provide the ideal opportunity to review cycle time and to provide an objective measure of improvement. It’s worth noting that I’m not suggesting retro discussions are limited to discussing cycle time, but rather that it is a useful input and a valuable topic.

Why are my guardrails different to Spotify’s?

There is nothing in Spotify’s list I disagree with, it is simply that my guardrails have emerged from a different use case. I typically work with teams where a continuous deployment capability, automated tests and code reviews are the norm. Those practices have been specified as part of a technical strategy but have not necessarily resulted in iterative agile delivery. My guardrails were defined to ensure that delivery practices exploit those existing technical capabilities. The ability to continuously integrate and deploy is not much use if we don’t work in small batches. Conversely, working in small batches is very hard to achieve if you don’t have automated testing!

The key to guardrails is to make them relevant to the context. Guardrails, like methodologies, stop being useful if they are one-size-fits-all.

Conclusion

I have now had the opportunity to apply my guardrails across multiple industries, multiple platforms, multiple companies and multiple teams, and thus far they have always worked. Very often the teams I work with are already using a methodology (typically Scrum or Kanban), but with limited success. Helping teams understand the goal of agility and introducing these guardrails has enabled them to move beyond methodologies to agility. It has also given those same teams the confidence to flex their ways of working. They can shift their focus to achieving agility rather than conforming to a methodology.

That said, if you want to try using guardrails, they need to work for your particular context. Take inspiration from Spotify’s guardrails or my own, but define a set that makes sense for your company and your teams.

Has this article piqued your interest? Could I help your teams? I am a coach and consultant that helps teams and organisations adopt agility. Find out more about what I do at betterfasterhappier.com.