Agile frameworks and orthodoxy

There is a world of difference between agile and Agile™. One of these is an ethos (or a doctrine?) for delivering work in a positive and responsive way, and the other is technical-industrial complex of rigid processes and frameworks. 

The agile with a small “a” is about building healthy teams that are empowered to get valuable work done. It is about reducing risk (and with it, cost). And it’s about keeping the focus on the people who you are delivering for - your users. 

Despite the agile manifesto being over 20 years old, these ideas are still sound. To paraphrase a bit, teams work best when the people in them communicate well, when we prioritise delivering things that work, when we help our peers or customers, and when we are able to adapt as circumstances evolve.

The last ten years has seen these ideas permeate technical delivery in the UK. I remember working in a big old fashioned PMO team not long after the Government Digital Service has been set up. They challenged us to rethink our approach to delivery, calling out the hidden costs and risks that came with a lot of up front detailed planning. Big projects with a very lengthy design phase followed by an even lengthier build phase are less common now, and that’s a good thing.

But there is a big difference between agile as a way of doing things, versus Agile™ as something that you need to be certified in, as the one true way. 

Frameworks have value

First of all, it is a good thing that people have articulated different ways that you can do agile. If we don’t articulate these things, then the only way to learn something is by doing it. The risk of that is that it creates a club, and clubs are not always open. Having a wide array of open approaches that people can easily find and understand can make this world less exclusionary. 

Frameworks can also be useful when you’re forming a team for the first time. It’s not uncommon in the UK public sector to see teams made up of people from multiple different organisations. If you don’t have a common language, then things can feel chaotic. Structure helps many people work at their best; if things are too freewheeling it can undermine your ability to build a healthy team. 

So agile frameworks and methodologies have value. But the context of the team and the environment both really matter.   

All these things should be used as inspiration

As soon as a framework becomes a rigid mantra, then the priority is about the process or the way of doing things. It’s no longer about actually getting things done. 

Establishing a smooth team flow is vital. But if you are spending more time honing what happens at each stage of your kanban flow, then you are not getting things done for your users. 

Breaking work down into small chunks is essential, and helps the team attack problems without getting stuck or overwhelmed. But if you spend more time talking about how to size something, and whether it’s an L or an XXL, then you are not getting things done for your users. 

Getting the whole team involved in generating ideas is hugely valuable. But every hour spent discussing how your ideation will work is time spent not getting things done for your users. 

These are anti-agile traps that teams can easily fall into, where the process becomes more of a priority than working out how to deliver real value. The process itself becomes a barrier in the way of getting things done. 

And often this happens when models and approaches from various places get fetishised. People often talk about the Spotify Model for scaling agile. This talks about organising a group of teams into squads, tribes, chapters, guilds, etc. Lots of people also follow the Spotify approach for team health checks. The Spotify Model represents one organisation’s approach for trying to follow an agile ethos. It may have worked in that culture with that group of specific individuals. It may have some ideas that anyone can use as inspiration. But your environment will not be the same. So don’t try and rigidly follow this, because you will end up spending more time worrying about whether you’ve got the model right than about whether you are getting things done for your users. 

The same applies to things like Scrum, SAFe, Lean Experimentation. They are all very specific interpretations of ideas and principles in the agile manifesto. Use any of them as a source of inspiration or a guide, but don’t follow any of them to the letter. As soon as you make a framework a priority, then you are no longer listening to the needs of your team or your users. 

Artisanal handcrafted services?

The idea of a factory line crops up frequently when people get fixated on agile as a set way of doing things, as opposed to an ethos. One of the great things about factory assembly lines is the consistency in what they produce. And if you have a big organisation, then consistency is probably something you want to aim for (understandably). 

But the drive for consistency comes at a cost. This paragraph in a blog about “The Failed Commodification Of Technical Work” puts it rather well: 

You can pay people to churn out bad self-help all day, but none of those are going to be worth a damn without allowing the human element to flourish. But you still need a factory which can print the things, and as clinical as a mass bookbinding operations sounds, I really believe that you're only going to get a beautiful binding when that factory is run by people who have the connection to the work necessary to exercise taste.

Use them with a pinch of salt

Frameworks have their place; they can offer ideas and inspiration for helping teams deliver iterative, incremental work focused on users. Without having these approaches documented in the open, we would be in a world where it is harder for us to learn from each other - a closed shop where people can only learn how to do this stuff because of who they know. 

But we need to take frameworks and delivery models with a pinch of salt; they are a guide that we can cherrypick from and adapt. How you borrow from them depends on your purpose and the outcomes you’re trying to achieve. They are not the gospel. The context of our teams and the organisations in which we work matter hugely.