23 March 2019
Why SAFe can be agile kryptonite
“Scaled agile” may be an oxymoron. The original authors of the agile manifesto were largely concerned with the dynamics of individual development teams. There was little consideration of how this style of development might be applied across a larger organisation.
This was deliberate. For them, agililty was about helping teams to overcome the impediments to building great software. Collaboration, iterative delivery and flexibility were valued above detailed planning.
Many organisations want to be “agile” because they associate it with greater productivity. There is an inevitable degree of cargo cultism involved here. People see the benefits that agile practices can bring to small groups of collaborators and wonder how this can be applied across the wider enterprise.
The Scaled Agile Framework (SAFe) attempts to frame larger-scale programme management in terms of agile principles. The framework may have its critics and detractors, but it can be an effective way of accommodating the various dependencies that are part and parcel of large-scale development.
It’s just not terribly agile.
The team gets buried
SAFe is based on a central assumption that development in large organisations is inherently complex. It often isn’t. Even in large organisations a lot of projects can be handled by a single development team. Product owners can work out how to collaborate with colleagues without the assistance of formal process.
This assumption that a “big solution” is needed can divert attention away from self-organising development teams. Technical practices such as continuous integration are paid lip service by SAFe, but they are not central to the process. You can implement SAFe without writing a single unit test or automating a single build. This feels a little wrong.
This is reinforced by the charts that describe the different flavours of SAFe. Development teams can be found lurking underneath layers of processes and actors including epic owners, strategic themes, value streams, release trains, architectural runways and enablers. With all this noise it can be easy to forget that the first tenant of the agile manifesto is to favour “individuals and interactions over processes and tools”.
SAFe is built around a planning cycle that typically lasts for two to three months. This cycle tends to create its own gravity, pulling everything into its orbit. Features are defined at the program level and distributed downwards towards development teams. In theory the teams get to decide which features to pull and how they should be delivered, but in practise teams tend to be bound to the tyranny of the “program increment“.
Teams don’t have full control over their workloads. Priorities are passed down from on high and teams invariably come under pressure to take on more work within an increment – i.e. the work that “has to be done this quarter”. The development organisation as a whole also tends to focus on a “big release” at the end of each increment rather than delivering working software in more frequent increments. It can start to feel like a series of quarterly waterfalls.
In fairness this isn’t the intention of SAFe. There’s nothing in SAFe to stop a team from deploying and releasing whenever they want to. The “release train” metaphor is just a coordination mechanism for dealing with dependencies. Deployment and release should be completely de-coupled from SAFe planning cycles. It just depends on the teams having developed the technical maturity to run at their own pace.
Who does what in SAFe?
One of the more challenging aspects of development in a large organisation is the sheer number of stakeholders you need to engage with. Like it or not, development is shaped by a much wider range of actors than the team.
Assigning formal roles to these extra actors can serve to diminish some of the responsibilities of the team. The product owner is reduced to a project management role that co-ordinates the delivery of a feature set. The ScrumMaster becomes a glorified administrator. Developers are confronted with an “architectural runway” that tells them what technologies to use.
Perhaps there is an unspoken power struggle in larger development organisations. Product owners want to be free to run backlogs without having to submit to a wider “release train”. Scrum masters want the freedom to organise development in the best interest of their teams. Developers want to make technical choices without being bound by standards or strategies.
It is unhelpful to frame this problem in terms of the struggle of humble development teams against the machinations of ruthless management. Working in a large organisation inevitably leads to some constraints over the freedom of a development team. They are bound by greater complexity and dependency as the number of stakeholders increase. SAFe merely attempts to formalise this and put it into a context where these stakeholders have more clearly defined relationships.
Agile and SAFe should be complimentary
Perhaps the problem might be that the word “agile” has become such a morally loaded term. It has inspired more than its fair share of unhelpful zealots and obstructive cant.
SAFe might be its own worst enemy. You can’t really “scale” agile. It’s a set of ideas designed to help teams to become more effective. Layering a portfolio management process over the top risks suffocating the very things that improve the productivity of individual development teams. There are plenty of command-and-control structures out there being justified in the name of “agile”.
Ultimately, the approaches should be complimentary. After all, they operate on two very different dimensions. Where agile practices focus on the dynamics of team delivery, SAFe considers how self-managing teams can fit into a wider organisational framework. The danger is that this focus on the team is reduced to a nuance that gets lost in the small print of a sprawling framework.