Agile antipatterns


An anti pattern is a frequently used, but largely ineffective solution to a problem. The term was originally used to refer to a pattern gone wrong. As Scrum practitioners, we all know that Scrum has events, artifacts, roles and rules. If the core principles, foundation ideas or the agile manifesto is ‘tweaked’ hoping they would provide benefits because teams are not seeing immediate results, this may result in an anti pattern. This in turn may become an ineffective solution to a problem.

Have you encountered an anti pattern in your experience that you want to share here?


This is a great topic of conversation, thanks for bringing to the message boards. We did some podcasts a while back on this topic, although I’m not sure we worded it as “anti-patterns”.

One reservation I have on the topic could be related to a personal struggle I have with the phrase, and would like to share. Antipattern has become a buzzword in the industry the past couple years and is used more and more every day. Often, its used to describe real struggles teams have that conflict with the manifesto and principles. However, it’s not always the case.

If an agilist doesn’t prefer a particular practice or behavior on a team, they may describe something they personally oppose as an antipattern. And since they are the supposedly most knowledgable on the topic it’s taken as gospel.

When we speak of antipatterns, my strongest desire is for us as a community to look inwards first and ask why we think something is an antipattern and challenge ourselves to see the other side. In many instances, it may be one for sure. But what if we’re wrong?

Hope that makes sense. Again, I’m biased but I wanted to share for feedback.


@chrismurman thanks for your comments. You are right that as agilists, we need to look inwards to ask why we think is an antipattern. Antipattern seems to be a fairly new word but has become a buzzword quickly in the industry.

In my opinion, the Japanese martial art concept Shu Ha Ri fits well in this situation.

Shu - Students follow the teacher/teachings of a master during the learning stage.
Ha - Student branches out and working the practice, follows other teachers/teachings and incorporates in to his practice.
Ri - Student is not learning from others at this stage but from his own practices. Creates his own approaches and adapts.

So, it’s important that as agilists, if we are in the ‘Shu’ stage, follow the teacher/teachings of a master so we gain the experience for practice. During this phase or the next phase of ‘Ha’, if we try to tweak something, we are probably creating antipatterns or may be use the word bad habits (idk).


Antipattern was coined from software development and is defined as an ineffective solution to a common problem. It’s a subset of the larger design patterns group.

The benefits of patterns and antipatterns is to facilitate communication and conversation with a common vocabulary. For example, in conversation, when we refer to gold plating, it’s understood that we’re doing work beyond the point where marginal value is gained without having to go into depth about the definition.

I agree with @chrismurman that using it as anything more than to facilite conversation can be dangerous and approached with caution. Context is important when considering something an antipattern (or even a good design pattern).

This has been covered several times in the past. If you search for Scrum Smells or Agile smells, you’ll also hit on some antipatterns others have listed that may suggest a larger issue with your processes and team.


The original AntiPatterns book came out just a few years after Design Patterns, and it’s an amusing and useful counterpoint. But I also found that it was a bit too flippant and passive-aggressive in places, so I wouldn’t be comfortable actually referring to it in practice (especially the ones about people, such as “Corncob”, a person whose behavior is deemed destructive or purely career-motivated). I think that’s related to the concerns that Chris mentioned above.

Searching for the book just now, I discovered that Wikipedia actually has quite an extensive list:


By the way, there was also an earlier conversation here: Scrum Anti-Patterns