---

One thing that is guaranteed to send a shiver of dread down my spine is anytime the conversation turns to ‘scaling agile’.

It is a difficult moment as on the one hand it usually means that the early experiments with working agile have had some success and it is finding believers where previously there were sceptics. On the other (white knuckling it) hand it is the moment when efforts start to make it more palatable to the ‘enterprise’ — where ‘scale’ actually means ‘risk reduction’ and ‘bureaucracy’.

For me it shows a complete misunderstanding of what agile means — but increasingly I feel I am in the minority.

See as far as I am concerned Scrum, DSDM, Kanban, SAFe, LeSS etc are NOT agile. They are toolkits to support agile but they are the means not the ends.

Agile IS the manifesto and its principles.

Do you see anything there about stand-ups, burn-down (or up) charts, kanban walls or retrospectives? All these agile rituals/ceremonies evolved to support the manifesto — nothing more, nothing less. I am a big fan of many of them (and less so of others) but →

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

..not to be great at Scrum and god knows not to be anything with SAFe.

The greatest power of agile, in my experience, is small, self organising, empowered, multi-disciplinary teams. Somebody smart once said;

The unit of delivery is the team.

Now no team is an island and things like the Spotify approach of squads, chapters, guilds and tribes is one approach to keeping things joined up beyond the single team. Emily Webber has written a lot (including a book) about the importance of ‘communities of practice’ and also I’m a big fan of her thinking about the agile onion of collaborators and supporters.

I think what both these approaches have in common is that they aren’t trying to scale agile — they are trying to atomise the organisational structure and reshape it into something that supports the agile approach.

This idea of ‘atomisation’ is also relevant to the architecture thinking at these organisations. It isn’t agile that needs scaling but the architecture / portfolio being re-conceived to consist of products that these teams (or squads) can deliver. Atomised architecture.

Now any large, complex system (i.e. “a set of connected things or parts forming a complex whole.”) is going to need some coordination but the goal should be the ‘minimal viable bureaucracy’ relying primarily on the communication channels created elsewhere (via the communities or the ‘tribes’) rather than imposing additional overheads or undermining the ability of the teams to make the best decisions for their users.

…and don’t even get me started on ‘lean’ and the misuse, misrepresentation of ‘minimal viable products’.