In the beginning, there was darkness the waterfall, and it was bad, terribly bad. For some reason, we thought building software was the same as building an actual building, so we ended up with a pile of papers, endless meetings, stiff processes, and no software delivered.

In that dark times, the fear of change was constant; whenever a change was introduced in the software development cycle, it meant going back to square one, restarting long meetings, rewriting documentation, and getting approvals.

Later, IBM started pushing RUP (Rational Unified Process), a sort of iterative waterfall, which replaces the long cycles of the waterfall with shorter ones, a step in the right direction some would say, even though many companies just ignored the iterative part.

But corporate had metrics and a false sense of control, so they were happy, or they thought so. In the first years of the ’00s, a new hope joined the game; the Agile Manifesto was published, a simple, concise manifesto with clear sentences showing what software development should focus on:

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

It embraced the nature of software development as a process in constant evolution instead of requiring a rigid plan.

It was music to our ears, and I couldn’t wait to put into practice what they proposed, along with some techniques from Extreme Programming (TDD, pair programming). So, I decided to pitch it to the management of my company at that time, and their response was something along the lines of “We have built software for fifteen years; we know how to do it, and this Agile thing is only for small companies.”

A bummer, but only for a short time; Agile soon started to proliferate like fire, but something was off; it came in the form of Scrum. Now, 20 years later, Scrum is almost synonymous with Agile, but not that Agile from the Manifest, a new form of Agile hijacked by corporate that barely has any semblance with the old one.

To be able to sell the Agile idea to businessmen, they had to adapt it until the point it was not what it was proposed anymore. In order to keep managers happy, metrics and processes were introduced so they could regain their false sense of control. Processes and tools slowly replaced individuals and interactions. More and more, Scrum was becoming a monster of meetings and documents.

So instead of cultivating a team where everyone feels free to speak at any time about anything, valueing individuals. We now have Sprint Retrospective, Team Health Check, and many other useless meetings with predefined processes, going exactly against the Agile Manifesto.

I won’t even talk about the abomination of Scrum Poker; I’m sure some heartless sadist created it. But wait, with all these, the managers can print nice graphs of velocity or some other useless graph that give them this false feeling of control, which again goes against the Agile Manifesto, but who cares about it at this point, right?

To be honest, I met so many “Scrum Masters” who didn’t even know the existence of the Agile Manifesto, as if it is erased from software development history.

But don’t take my word for it; listen to what people like Allen Holub and Uncle Bob have to say.

All in all, we are moving in the wrong direction, we let business people decide how software engineering should work for so long that now what we call Agile is not much different than the RUP, and we are all witnesses of the slow death of Agile, killed by Scrum.