On Thursday, Agile died.

Last Thursday, the Agile in our project died. For most people around the world the day was unremarkable, but for us, on this particular Thursday, Agile was — finally — put out of its misery. For the…

Last Thursday, the Agile in our project died. For most people around the world the day was unremarkable, but for us, on this particular Thursday, Agile was — finally — put out of its misery.

A dramatic reconstruction of Thursday.

For the project’s dev team, Thursday was a day like any other. There was a little trepidation among those who knew a little of what was being discussed behind the scenes, but for the rest it was business as usual.

It was only on the next day that the news reached everyone; we’re going back to Waterfall.

My reaction was measured and calm.

(╯’□’)╯︵ ┻━┻

Waterfall. I’m not a fan of it. Waterfall is the antithesis of Agile. In my mind, it’s a laborious, inflexible, process-driven method of development, requiring specifications, agreements of work, Gantt charts and a plethora of other paperwork seemingly invented to give management something to do for weeks on end.

I ❤ Agile.

In contrast I believe that Agile is synonymous with innovation. At its core is the difference between someone dictating exactly what a team of developers should build and how long they should build it in, and getting a multi-talented team together and giving them a challenge to solve. The final result could still be the same, but it’s more likely it will be a better solution to the original problem and delivered earlier.

Agile projects can certainly be… innovative.

Agile may not be perfect — and it has its own risks and pitfalls — but it’s a lot more appealing for a developer to be working with than a Waterfall project.

“It’s only a failure if you don’t learn from your mistakes.”

Agile Postmortem.

The optimist in me demands that we at least try to learn some lessons for the future. If something fails, you have to know why, so you can improve upon that in future. Here’s what I think are the problematic parts of using Agile for your projects:

Businesses don’t care about Agile.

Only the development team cares about whether you do things with an Agile mindset. Everyone else just wants you to deliver on time and on budget. Unless you’re in some cutthroat startup world, nobody cares about your innovative, exciting features, your continuous delivery or how much your team believes in the product they’re creating. Agile serves to empower developers, but let’s face it: they’d still deliver code with or without Agile.

Agile is quite tough with large teams.

What works for a team of two developers doesn’t work the same for a team of twenty. And this was a big project. It’s obvious when you look at it, but you can’t scale daily standups with a 1:1 time ratio and involve everyone in every meeting before you start losing that small team feel.

Agile doesn’t help when you have absolute requirements.

If the powers-that-be want specific features in a specific way, then flexible and lean acceptance criteria and feature sets aren’t helping you deliver a releasable product. If something is not making things better, in true lean principles, you should get rid of it.

Most developers aren’t very client friendly.

Most of us aren’t even developer friendly, either. Maybe it’s just as case of confirmation bias, but developers are either quiet and submissive or brutally honest — neither of which is particularly ideal for unmediated contact with clients, and makes for a bit of a loose cannon when you’re trying to keep everyone happy at once.

In conclusion: Agile wasn’t right.

Using Agile as a cure-all for our project management didn’t work out, it wasn’t the right tool for the job, and as such it’s been replaced by a hybrid of Agile and Waterfall processes.

We haven’t completely abandoned Agile and it’s principles but equally a lot has changed. Only time will tell how it’s going to work out.

We call it… ‘Water-scrum-fall’… or something like that.