Most larger organisations want to be more "agile", even if they don't align themselves explicitly with the term. There is an almost universal desire to be adaptable and able to adjust on the fly to meet the evolving demands of customers.

According to agile principles, this means focusing on value for customers, working in small teams on short cycles, and preferring networked collaboration to top-down bureaucracy. It's easy to understand how this approach might work in smaller engineering shops with a few teams. However, it's difficult to imagine how this can scale to meet the more complex challenges of larger organisations.

There are frameworks that attempt to solve this problem. The Scaled Agile Framework (SAFe) is perhaps the best known, but there are numerous others, including Disciplined Agile Delivery, Large Scale Scrum, and Accenture's AutoScrum framework. They each attempt to describe an operating model that scales development using "agile" and "lean" principles.

Branded agile and fake agile

They also attract a fair amount of criticism - some of it verging on fanatical. I've written my own take-down of SAFe based on the familiar argument that it doesn't feel terrible agile. It enables a form of "agile washing" where existing management structures and behaviours can be reframed in terms of an "agile transformation". The charge that it represents "fake agile" does stick to an extent as stakeholders can pay lip service to agile without having to change their behaviour.

These frameworks are often dismissed as "branded agile" schemes that are designed to extract training and consultancy fees from customers through buzzwords and empty promises. It's easy to be cynical about something so obviously concocted to chase the zeitgeist, but many of these frameworks are attempting to solve some very real problems.

Larger organisations want to deliver value for customers, but they also need to distribute limited resources between competing priorities, co-ordinate delivery, and demonstrate some return on investment. They need some way of managing the wider portfolio of work, ensuring alignment with the objectives of the business, and engagement with relevant stakeholders.

Are self-organising teams enough?

Some agile zealots might argue that none of this is necessary. Organisations should be composed of an interacting network of small teams, all focused on working to deliver increased value to the customer. This is unrealistic as it denies the reality of large organisations.

Larger organisations are beset with practical obstacles such as outdated technology and manual process. They expect to achieve some economies of scale by reducing repetition and eliminating waste. They often need to deliver complex systems that require the input of multiple teams. In this context, the "customer" can be a network of internal and external stakeholders that can include other engineering teams.

This gets into the murky world of organisational politics, where stakeholders and departments compete for resources. Relying on self-organising teams to solve your problems is a simplistic notion that denies the reality of the way that larger organisations operate. There are no easy answers here and the organisational landscape will always be beset with complexity and ambiguity.

Methodologies such SAFe try to provide a map for these environments by applying agile principles to them. The problem is the phrase "scaled agile" is itself a bit of an oxymoron. You can't really "scale" agile beyond autonomous teams. SAFe is really just a portfolio management process, which isn't a particularly "agile" thing to say. However, you need something like this in a larger organisation, whether you apply a branded process to it or not.

The dangers of rolling your own

SAFe might be a bitter pill to swallow, but development in larger engineering organisations is untenable without some form of portfolio management process. Thomas Hobbes described life without government as "nasty, brutish and short" and the same could be said of a development environment without project governance.

You need a mechanism for identifying the larger initiatives, capturing the appetite for investment, and agreeing some form of prioritisation. Ongoing development is beset with scoping decisions that need the input of both internal and external stakeholders. You need to provide some certainty around when returns might be expected on any engineering investments.

None of this is addressed by the agile focus on autonomous delivery teams. You need some process, and an organisation must choose between rolling their own and adopting some form of branded agile.

Rolling your own process may seem attractive at first, but it is based on the conceit that your organisation is somehow unique. It probably isn't. Most branded agile processes are informed by years of experience of working with similar organisations solving a very similar set of challenges.

If you design your own process, you may find yourself drowning in implementation complexity. You'll need to explain your process to every stakeholder, without the benefit of prior experience or a widely accepted canonical definition of your process to fall back on. The implementation will be uneven as edge cases emerge that don't fit. You will need to make changes to accommodate unexpected realities that further undermine collective understanding.

The advantage of a branded agile process is that, for better or worse, they are battle-tested with many prior implementations in similar organisations. They would have accommodated your problems before and should have the distilled wisdom embedded into their processes. Home grown portfolio processes tend to wilt in the face of the inevitable difficulties and awkwardness that always crops up in development.

There's no agile nirvana waiting for the lean...

This might seem like a weak defence of branded agile frameworks, i.e. "they're not great, but it's better than rolling your own". The point is that there is no "agile nirvana" where large organisations can achieve the agility of a lean start-up.

Most of us work in enterprises that have mountains of technical debt, monolithic systems based on legacy technologies, and lots of manual process. They are beset with complexity that cannot be addressed by autonomous teams focusing on value alone. At least a framework like SAFe recognises this and offers some solutions based on hard won experience.

Filed under Agile, Development process and Strategy.