Put down the org chart, snowflake: Why largile's for management crybabies

If 'the process' is still 'the process', you're doing it wrong

There's a stink growing out there in agile land: a debate over how to scale up agile in large organisations. Should we put frameworks like SAFe or the most awesomely named DAD in place to scale it? How about LeSS?

These "agile in the large" frameworks have been on the ascent in recent years. A 2015 Gartner survey found that DAD, SAFe, and LeSS had been adopted by 10-12 per cent of organisations. SAFe was driving the most interest with 34 per cent of respondents checking it out.

As ever when the adoption of agile matures, there's much gnashing over whether things are being done properly. On the one side are the agile poets and on the other are the agile formalists. The poets like the emergent, dynamic, small-batch nature of agile and don't want to bind teams to locked-down rules and requirements to "align" with the rest of the organisation. The formalists want to put in place and document processes that ensure that thousands of people can work in lockstep on software.

The infantilism of management

Compared to staid, friendly discussion, there's a particularly vitriolic conversation going on about SAFe now. Words like "infantile" are being thrown around! The fear is that SAFe focuses too much on keeping existing IT bureaucracies in place for the sake, you might say, of giving management something to do. Instead, the agile poets say the focus should be dramatically changing how the organisation works as a whole, not keeping all the separate groups in place that need constant "alignment."

It's this notion of "alignment" that acts as good dipstick for the discussion. If there are hundreds, thousands of people working on a unified portfolio of software, there's the chance for lot of coordination. As an example, in his recent book on scaling up DevOps, Gary Gruver uses the example of putting omnichannel retail in place, a seemingly simple, but very complex system spanning multiple back ends, shipping, and in-store systems, not to mention the mobile and web apps buyers use.

The alignment anti-pattern

"Alignment" then is the need for groups to come together and plan out how their sub-components interact together to create the entire system. Next thing you know, you're scheduling meetings, writing Word docs, and spending weeks integrating various systems together. A typical straw-person nightmare of slow software development.

The critics of "largile" are worried that this focus on alignment should instead be on removing the need to coordinate and align groups, at least manually. At a technical level, this means removing as many dependencies as possible and, usually, giving each team more responsibility. The whole idea of DevOps is an example of dependency erasing at the process level: by collapsing together the roles of development and operations, you strip out the time and hand-off errors that occur when you throw the application "over the wall" of the operations. The fear is that you end up with exactly the same process as you had before. Renew those up Word and PowerPoint EULAs!

Requirements cathedrals

A few anecdotes from my flâneuring about in the enterprise world illustrate this alignment anti-pattern. I spoke to the people at a large, US health insurance company recently trying "the new way" of developing software. They started the project with several hundred pages of requirements that business analysts had build up like a perfect cathedral. After throwing this pile of paper to a unified, balanced "two-pizza team" who walked through the user problems and how to start the discovery cycle for solving them with weekly builds, most of the cathedral was dismantled and ignored.

Once this team started deploying software weekly and studying how the user interacted with the software, they learned what was actually needed and changed the requirements appropriately. The team removed the need to "align" with others in their organisation. Sure, there were external systems to cope with, but removing the need to coordinate and take ongoing input from parts of the organisation that weren't close to the actual users speed up the schedule tremendously, delivering months ahead of time.

Taking a similar approach, a large bank scoped down the coordination needed across organisation by pushing responsibility down to the team level. They were able to speed up their delivery by 57 per cent. At a micro-level, the act of pair programming removes the need to "align" on with code reviews as they happen while the pair codes.

The hope of much of the container and cloud crew nowadays is that cloud automation removes a huge amount of infrastructure, networking and security functionality, removing the need to align on those glide paths. Looking at Gruver's recent book again, the idea of standardizing on CI/CD pipelines is another tool to automate alignment, removing the need to align in the meat ware levels.

Time and time again, the goal of the agile poets to “remove” the need to align, not facilitate it. As one large European bank put it:

When we were doing big design upfront, downstream changes had to go through a rigid change control process. We wound up being busy with our own process rather than delivering value, and either we didn't deliver or we delivered late. Don't pave the cow paths.

Don't pave the cow paths

Now, I don't think proponents of largile practices would say any of this is their intention. Indeed, I wouldn't be surprised if agile in the large practices didn’t marble my own examples above. The agile poets would argue that, regardless of intention, the effect is the once again prove out Larman's Law: the bureaucracy will be in place, just with new words describing the infinite process gates and alignment drones.

I'm not convinced perfectly either way. As usual, someone's probably spun the dichotomic dial so hard it's busted off. I've spent recent years studying the seemingly impossible task of scaling agile techniques up to large organisations. As the DevOps Reports have found, organisations with 10,000+ employees are 40 per cent less likely to be high performing than organisations with 500 or less employees.

Clearly, it's hard for large companies to improve how they do software. There are real needs to align and coordinate between organisations. Thinking back to that omnichannel example, one team of four to 12 people can't build and maintain all parts of the system. The goals of (buzzword alert!) "microservices" try to address this alignment problem at an architectural level, but that school of thought is relatively new.

This is still uncharted territory for many, and I suspect it'll be the usual situational problem: how you scale agile will depend on your organisation peccadilloes. A recent Gartner study found that a meagre 27 per cent of surveyed organizations are using agile approaches for "most or all" of their projects, a shockingly low number. Before these organisations even worry about doing agile at scale, there's plenty of work to be done at the team level.

One thing is for certain: you don't want to simply keep doing the same thing. If you find that the org chart, the flows of information and – gasp! – approval processes are exactly the same as before your largile transformation, you're probably doing it wrong. ®