You are here

Close
Do you like what you are reading? Do you want to receive more content like this, in your inbox?
I send out articles just like this to my newsletter about once per week. Subscribe now:
* indicates required
Close
Do you like what you are reading? Do you know people who might be interested too?

Share This Page:

Agile Anti-Patterns

Suddenly, in a large company that has been around for a very long time, the C-Level executives realize that something must change. Smaller, younger companies are out-competing them.

"Everyone else is doing this Agile thing. So we have to become agile too. From now on, we will all do Scrum!" (Or Kanban. Or SAFe. Whatever.)

They start a huge "Agile Trainsitioning" project. They hire expensive consultants. They re-name all roles. Everyone in the company gets two days of training.

And then they declare success: "We are agile now!"

But often, things did not work out exaclty how they would have liked. Here are some "Agile Antipatterns" that I saw at previous clients (expecially big companies), after they started to introduce "Agile" into their company.

This article is based on my keynote at the "Lean, Agile, Scrum 2017" conference in Zürich. In that keynote, I also talked about root causes and possible solutions. In this article, I'll only describe the patterns.

Agile Theater

"We are agile now!" All the teams are doing their stand-ups and retrospectives and all the other little rituals. We celebrated our success. All the managers got their bonus for finishing the transition on time and within budget.

But if you look closely... Nothing has really changed. The company, as a whole, works like it did before. The rituals are just rituals, nothing more. There are no visible benefits from working in a new way.

And the employees just play along. They know that the next re-org will happen in one or two years.

Feature Factory

Every two weeks, the team delivers new features. Delivering is success. We are keeping the velocity up.

Nobody knows if the new features really give any benefit to the customer. And the dev team does not care. They are paid for turning user stories into production code, not for measuring if they actually do something valuable. This is someone elses' job.

No developer or tester has ever talked to a real user. It's more like chinese whispers: The users talk to their boss, who talks to the business analysts, who talks to the PO, who talks to the developers, who talk to the testers.

Product Backlog Bankruptcy

The product backlog is big. I mean, it's huge.

Yes, we know, it should be a sorted list with one top priority item, one second place, one third place, ... and one last place. But we really don't care about the order of items #100 to #600. All of them are not important. Who knows if we will ever start them.

We observed, though, that we have very long lead times. And our estimates are very often wrong.

Architecture Madness

Oh my god, everything takes a long time nowadays. Three years ago, we would have implemented this feature in two days. Now we're two weeks into the implementation, and there is no end in sight.

You want to work on that user story? Pleas wait until Jane is back from holiday. She is the only one who really knows the desing of that part of the system.

Wait, what? You changed that class? We don't do that. Things will break.

The last time we changed the design of the software in a meaningful way? Can't remember. Must have been years ago...

Refactoring Backlog

This one is related to the previous point. There is a backlog of things the team would like to do. Introduce Spring Data. Automate our production deployment. Improve the architecture. Move the messaging code to it's own process.

But the product owner has to allow large refactorings. They might interfere with the sprint goal, after all. And she often does not do it. Thigs are stressful right now.

Then, suddenly, the PO allows us to work on a big refactoring. But it goes horribly wrong. Things break - Even in production.

Now we are reluctant to try again, because of the big mess we left the last time.

Burnout by 1000 Baby Steps

Management sees agile just as a way to improve efficience.

The daily scrum becomes a management report. Failing a sprint goal is a catastrophe - The team has to report to the PO when it happens.

No the team is under immense pressure all the time - In tiny, daily cycles. They burn out. In the end, one of them writes a blog post titled "Scrum: A Micro Manager's Dream".

OPS? What do *we* have to do with OPS?

Yes, I wrote operations here. But it could be any other department of the company. Like Testing, Product Management, HR, ...

One or more teams started to implement agile software development. The rest of the company lags behind - Or maybe it never even plans to change.

Now working together with these other departments has become much harder. It does not work anymore. It impedes the agility of the teams. In the best case, something like "Water-Scrum-Fall" is happening. But it might be worse.

Survey

Did you ever experience one or more of those anti patterns in real life? What is your company doing well, where do you still have problems? Please tell me:

Erstellen Sie Ihre Umfrage mit SurveyMonkey

My name is David Tanzer and I have been working as an independent software consultant since 2006. I help my clients to develop software right and to develop the right software by providing training, coaching and consultanting for teams and individuals.

Learn more...