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

Technical Leader Worries: I Have Too Many Things to Do

Technical Leader Worries: I Have Too Many Things to Do

Those wonderful days when the only thing you did was writing code are gone. Now you are a leader. You are doing everything: attending or conducting meetings, removing impediments, mediating between team members and the rest of the organization, reading or writing some kind of reports (and you deceive yourself that spending two hours in Excel counts as programming because of some smartly used formulas) and so on. You are in a hurry all the time, and it never ends.

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

The Key to Time Management

There are several topics that constantly come to my mind and, with each new discovery, I reach a new level of understanding. One such topic is “time management.”

Read More