Broken Agile

Published on 19 June 2019

❗❗ I invite you to sign up for my DevNews newsletter 💌. DevNews is issued weekly and consist of carefully selected digest of tech-news from last week. Don't wait❗❗ Sign up today

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!

Proposal

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

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

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

comments powered by Disqus