Burn🔥the Agile Manifesto RIGHT NOW!

Image: https://www.comicagile.net/

The Agile Manifesto declared we should prioritize “individuals and interactions over processes and tools”, so how did, we end up in a place where ceremonies feel closer to hostage situations that something to help us create effective software.

I might just be that Agile has devolved into dogma, and ensemble programming might just be its ugliest side effect — or its only redeeming feature, depending on how much you’ve given up on your team.

The Agile Disaster

It’s difficult to remember that Agile is supposed to fix software development.

It might have some good ideas. Some of those good ideas might even have made certain aspects of software development easier.

Yet other aspects of Agile resemble medicine that makes you sicker than the illness you had ever did. Here are the parts of Agile software development that resemble Oasis’s fourth album, the Apple Mac clones and the Sega Pico.

Stand-Up Meetings That Nobody Stands For

A ritual where everyone mumbles their updates, nobody listens, and you’re left wondering why you woke up early for this.

I call it “wasting 15 minutes every morning for no return”

Sprint Planning That Feels Like Olympic Gymnastics

Estimate your story points, they said. Deliver in two weeks, they said. But what happens when your sprint plan is thrown out the window by day three because the requirements changed again?

Then they try to hold you to the original estimate.

Retrospectives That Solve Nothing

“What went well?” might be met with complete silence.

If you do raise your head above the parapet and suggest something nothing will happen. Because saying “Agile sux” isn’t constructive (apparently).

Agile’s Frankenstein Monster

Agile isn’t fixing your team, but it’s created a market for quick fixes and sticking plasters for the problems Agile brings. Case in point: ensemble programming. It’s a desperate attempt to enforce teamwork in a world where Agile has obliterated team cohesion.

Here’s how it works:

Everyone codes together

Having one coder is problematic and error-prone. Summing these errors will cut down the errors, because that makes sense to those pushing ensemble programming.

You rotate roles

Sometimes you might be able to use a keyboard. Brilliant, right?

You avoid silos

Except the real silos are management vs. developers, and no amount of mobbing will fix that.

Sorry, Ensemble Programming Won’t Save Agile

Even if you think ensemble programming is a good idea (which it isn’t), it’s not enough to save Agile.

It’s Exhausting

Nobody wants to spend eight hours a day arguing over variable names with their entire team. Effectively working in the mob removes all independence and ownership from the programmers. 

It’s Inefficient

When everyone’s working on one task, you’re burning through payroll like there’s no tomorrow. If you’re using mob programming for simple tasks as well as more complex tasks you might as well just burn money.

It’s Unsustainable

Agile loves to sell “self-organizing teams,” but ensemble programming needs strong facilitation — or it descends into chaos.

Ensemble programming is what happens when Agile has failed so badly that your team doesn’t even trust each other to work independently. It’s like group therapy for developers, except nobody’s getting better.

The Issue

Ensemble programming only came about because of Agile’s flaws. Developing a programming technique that resembles group therapy for developers (but improves nobody) is a problem all of its own.

What Should We Do Instead?

Throw the Agile Manifesto into either a fire or a dumpster. 

Or don’t do that, and actually admit that its principles are only as good as the people implementing them. Then if you want to go down the path of something like ensemble programming accept it’s not a cure for all that is wrong with Agile.

I’ll say the issue with Agile is that it seems to target process over people — the very thing it claimed to oppose. Let us start there and think about what actually needs to be done to improve software development.

Conclusion

I’m starting to believe Agile is like an interview candidate for a job who says all the right things, but when they get the position, they end up doing something else entirely.

Ensemble programming is the kind of sticking-plaster onboarding program that does just about enough to ensure the employee passes probation but doesn’t fix the underlying issue of employing the wrong candidate.

Maybe it’s time we stop trying to salvage Agile and start focusing on what software development really needs: clear communication, realistic goals, and fewer meetings.

Until then, enjoy your ensemble sessions. At least they’re more fun than a sprint planning meeting.