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

Disappointment, Focus, and Solutions for All Problems ;-)

Introduction

Many of us dream of a situation where we can work at a sustainable pace, having enough time for everything and being able to comfortably do our job. But it doesn’t work. I’ll tell you why.

Read More

Natural Order of Refactoring Explored Part 2: Compose Method

Compose Method

Analyzing methods, such as the one presented in Part 1, often leads us to understand the main points of the algorithm contained in them. This insight paves the way for the next step: try to split a large method into smaller steps by extracting them into separate methods (refactoring using the Extract Method). Thus, the original method will consist of a sequence of calls to these new methods. With the right naming conventions, you can achieve code that reads like a book.

Read More