Why Agile Fails

Table of Contents

Introduction

Implementing a methodology from the Agile family is not at all easy. The problem usually lies in management, who upon superficially understanding what it’s all about, perceive the new method as a promise that from now on, everything will magically work better. It doesn’t matter if we have subpar team members and adhere to the principle that “any specialist can be replaced by a finite number of students.” It doesn’t matter if there’s complete disregard for knowledge management and skill development in the team because there’s never time for that. It doesn’t matter if people working on projects are shuffled between projects—after all, it’s about interdisciplinarity, and everyone should know everything.

It doesn’t matter if deadlines are set a priori for unclear reasons or if it’s assumed to be the only way to convince clients that we’re professional, thinking we’ll somehow fit in the timeframe. It doesn’t matter if we don’t find time to maintain architecture and code because there’s no time for such unnecessary activities.

Agile promises that everything will be beautiful now. We’ll just slap a label on what we’re doing now—let’s call it “Scrum,” create a bit more chaos because it’s about managing chaos—thus, everyone does what they want, how they want, and we stop documenting anything. After all, we are using Agile; everything will self-organize.

Why Agile Often Fails

Therefore, Agile most often doesn’t work because the people blindly applying it or the management preliminarily accepting the benefits of the approach use very simplified thinking: “Ok. We’re doing Scrum. But actually, 8 out of 10 elements don’t suit us, so we’ll pick what fits (two elements), and we’ll continue doing the rest as before (as described above).”

And everything will remain as it was, or even get worse.

A Word of Caution

THUS WARNING: In such a case, one should not, and even MUST NOT, start using Agile. Agile is a change, a significant change, not a label that will solve all problems (in this case, a bottle of alcohol might probably work better).

(Text translated and moved from original old blog automatically by AI. May contain inaccuracies.)

Related Posts

Conversation with the Client

First Conversation with the Client

Today marks the beginning of a new project. As always in such cases, there is a hint of excitement in the team, as well as attempts to guess what the project will be about. We have some information, but nothing is certain yet.

Read More

Technical Leadership Book is Available

Exciting Announcement: Technical Leadership Book Release

It is a great pleasure for me to share the information that today is the premiere of my book “Technical Leadership”.

Read More

Cleaning Up Code: Not Just About Refactoring Part 2

Due to formatting problems with code on Blogspot, it is recommended to read this article in PDF format. You can download the PDF version of the article here.

Read More