Jump to content

Broken Agile

Posted on:June 19, 2019 at 02:00 AM

I was a true believer in Agile methodology. I was… Now I think Agile, in the current form, does more harm to the project than waterfall did in the past. Let me explain you why.

Why Agile is broken and needs to be reevaluated?

Agile in 2001-2005

15 years ago Agile was born. At that time Internet Explorer 6.0 was shipped (AJAX introduced) and Windows XP was on its way. It was a long time ago.

The Agile Manfesto states the following:

Back in the Windows XP times, the Agile Manifesto was something completely new. It claimed to allow us - software engineers - to produce software faster, better and in a more predictable way. It was promoted as The Pill for our suffering… and the suffering of project panagers and stakeholders too.

Agile Manifesto was created by a group of very experienced software engineers who were solving day-to-day software development problems. They wanted to provide others with a framework, so we all can deliver better software products/projects.

Now every software company is Agile, Agile in its own way…

Agile Manifesto

I will now describe each of the Agile Manifesto fundaments and comment it with what I’ve observed in reality.

Individuals and interactions over processes and tools

The concept was that developers should collaborate more. Self-organization and teamwork will make us stronger.

We ended up with a sticky tape that we can use for building prototypes. Prototypes that go straight on production

Working software over comprehensive documentation

The idea behind this rule is that developers will present something that actually compiles with no errors and can be presented to the customer. Can be used quickly.

We ended up with barely any documentation. No responsibilities. The software works only when we are present. The know-how leaves with us - engineers.

Customer collaboration over contract negotiation

Developers wanted to invite customers to a closer collaboration. If we understand what customer really wants, we can deliver exactly that. We can, of course, redesign everything in next sprint, or more sprints :)

We ended up with agreeing to deliver undeliverable. We wanted to serve the customer, t meet their needs even they didn’t exactly know what they wanted. But… actually, the customer didn’t know what he wanted and pivot the product too often - not our fault!

Responding to change over following a plan

Due to rapid changes in the world, we develop a framework for faster adaptability. The customers couldn’t wait for the updates that long as before. Their competition could very easy takeover the majority of the market if they were faster. That’s why abandoning the plan and following the chaotic market was the strategy.

We ended up with chaos all over the place. We showed our customers that we can adapt to software as fast as they think. We created more chaos.

Agile 2019

What we forgot is to teach the customers how the software is built. Agile Manifesto creators had the knowledge to create the agile framework. Now we bend it as we like to hide out sins from customer’s eyes. We are AGILE!


My proposal is simple. Just replace the world over from the manifesto with together with.

Is it a good way to fix what’s broken?