Many organisations want to be "agile" because they associate it with greater productivity. There is an inevitable degree of cargo cultism 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) is one of many attempts to frame larger-scale programme management in terms of agile and lean 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 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. The customer seems pretty incidental too. 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".

Unintentional waterfalls

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 teams. In theory the teams get to decide which features to pull and how they should be delivered, but in practice 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 "release train" metaphor tends to enshrine the idea that lots of software should be released at once, discouraging progress towards the kind of frequent, small releases of working software that tend to be associated with low defect rates. 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 the dependencies that are part and parcel of large-scale development. 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.

A mandate for the bureaucracy?

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 dilutes some of the responsibilities of the team. 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 the freedom to design solutions without being confronted with an "architectural runway" that frames their technical choices.

In this sense, SAFe enables a form of "agile washing" that can be used to justify the existing bureaucracy. It gives managers a mandate to call themselves "agile" without insisting on any genuine reform that places both team and customer at the centre of development.

This line of argument can be unhelpful. It frames the problem in terms of the noble development teams' struggle 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, agile practices and SAFe 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.

Filed under Agile, Development process, Favourite posts and Rants.