Jun's Alcove

Fallacious Agile

This is a rambling critique and a place for me to air some grievances I have with the software industry, and my experiences with it. If you are currently enamored or deep in the Agile and Scrum mindset, I wouldn't read this.

For context, I have worked in the software industry professionally for about a decade now, and while my experiences are of course not fully comprehensive, I think they speak to a myriad of different company structures and sizes. Nowhere I have worked in anyway practices what I would describe as "Agile" as it is described. Whether it's SAFe, Scrum, or any of these terrible frameworks; None of them provide the supposed self-organizing flexibility Agile calls for.

The Agile Tenants

I think a good amount of people reading this are familiar with the core tenants of the Agile software practice:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan 

And I think plenty of people will also understand why I want to make sure these tenants are laid out before I get into any criticism. I think the Agile tenants are perfectly logical, strong foundations to build a self-organized and worker managed software team. But there in lies the first issue with how it's applied: Managers.

What Does an Agility Lead Actually Do?

Not much. They exist to enforce the processes(!) surrounding an agile team, whether that be Scrum or any other form of framework. So already we've failed a tenant of Agile, the first one in fact! We now have a manager whose job is to maintain processes over individuals.

But they're not a manager, you decry! While technically true, and they usually don't have executive power over the team, they are usually far more friendly with the people who do. And with that soft power comes the same caveats as any normal manager.

At Least There's No Technical Manager... Right?

If you're lucky! But many times, there is. They claim it's to "empower" the team but all they truly provide is more processes, more structure, and less flexibility.

A technical manager existing in an agile structure is a failure of the structure as a whole. While an agility lead could theoretically act as as an overseeing body with no executive power over the team, the purpose of a technical manager is explicitly to hold executive power over the team. If you're lucky, they won't act on it, but it's there nonetheless.

But You Have to Have Hierarchy!

No! You don't!

But You Have to Have Processes!

Yes! For the team, and defined by the team. Prescribing a framework onto a team removes their flexibility by forcing processes (there's that word again) onto them. Sure, it's more covert than a waterfall structure where the processes are well established, rigid, and (ideally) requires contracts between teams.

Part of the flexibility aspect of agile, and "individuals and interactions", is the ability for the agile team to adjust to pressures and adjust their processes quickly and without friction. Enforcing a framework defeats the entire purpose of that flexibility, with no way of recouping it.

And with that quick ramble, we reach the true villain of this ramble:

Scrum: A Very Fast Waterfall

Scrum is a comical farce that claims to improve on waterfall, but all it truly does is speed it up. In the process you end up with software teams with the same lack of flexibility, with their power of pushback largely removed due to lack of contracts between business and technical teams, and with added responsibility as now your technical teams are given the extra responsibility of product requirements.

To be clear, this is not a defense of waterfall. I understand that many times waterfall also lacks contracts between teams, and is just an unrelenting torrent. But so is scrum, by explicit design.

The fact scrum took off in companies so drastically is proof enough of it's lack of ascribing to the agile philosophy. Hierarchy is embedded in the structure of capitalist societies, and by extension a vast, vast majority of companies. As such, the only form of agile to exist in that vast, vast majority must be a bastardization of the original.

So What's The Alternative?

The alternative is exactly what agile describes: Worker ran and maintained software teams, that take in business requirements from business teams and rapidly adjust their processes to account for the new requirements. Anything on top of that is just dilution of the concept itself.