Head First Agile: Any potential antipatterns in Agile?

[meenakshi sundar]

I am just wondering, are there any potential antipatterns in running sprints?

I could think of one,

Somewhere i read that the Technical debt sprints also referred to as hardening sprints are essentially an anti-pattern
Not sure I agree, but having a separate list of debt is very much an anti-pattern, i believe.
Whats you take on that?

Thanks
Sundar

[Andrew Stellman]

Yes, definitely. I actually give a talk called "agile antipatterns" every now and then about exactly this topic.

Rather than write a lengthy response, I can just share the slides from the last time I did the talk: https://www.scribd.com/document/362772908/Agile-Antipatterns

[meenakshi sundar]

I had a typical day at office some months back where we were still learning the ropes of Agile in our project
But there was this project that was touted to be the best case example of how should an agile project be run
we were often advised to take advise from them .....Sounds familiar???
And i saw many of the traces of the hangover from Traditional Model.

Which is best explained in the below article.

An antipattern is a pattern that you think will improve things

Command and Control

When starting out with Agile or Scrum for the first time, it is not unusual for the Product Owner or Scrum Master to be a manager, be it the team leader or higher. When this happens, the old habits of command and control kick in. The manager assigns tasks to individuals in the development team. Tasks are broken down based on hours of work, not story points. In this case, the manager is taking ownership of the tasks away from the team. By assigning tasks, and worse, breaking them down themselves, the manager has kept ownership, and the development team is just a cog in the engine.

This can lead to failure as the team is no longer empowered. They have no say in the solution and thus mindlessly do the work as required. Yes, it is the Scrum Master's role to protect the team from this sort of thing, but if the Scrum Master has no power and all the power is in the Product Owner, the role becomes moot.

[Junilu Lacar]

You left out a very important part of the text that you cited: An antipattern is a pattern that you think will improve things, but it doesn't.

A few things that can turn a good pattern into an anti-pattern:

1. Used in the wrong context
2. Used with a different motivation
3. Used with a faulty implementation/execution

I think it's prudent to consider the possibility that any or all of the above apply before faulting the pattern itself. The more a pattern has been applied successfully elsewhere, the more likely it is that the failure to improve things is due to one or more of the above.

[Junilu Lacar]

Let's take an example from software design patterns: The Singleton Pattern.

The Gang Of Four included Singleton in their book, so they obviously thought it was useful at some point. However, as people tried to use Singleton, more and more people wound up abusing and misusing it in ways the GoF probably didn't intend or anticipate. If memory serves me right, I think one of the GoF even went so far as to express regret over including Singleton in their book at all. Hence, the Singleton Pattern is probably the single most derided GoF pattern out there today and  the general advice you'll get about it is likely to be "avoid it if you can." Yet it still is one of the patterns most people who start learning design patterns will try out.

Sound familiar?

Now let's relate that to Agile and consider story points. Story points are still standard fare for people learning Agile/Scrum. However, there is a #NoEstimates movement that is gaining a strong following within the Agile community recently. In fact, Ron Jeffries, an original signatory of the Manifesto in Snowbird UT, wrote an article in support of the movement. Among other things, the #NoEstimates eschews the use of story points. So while one section of the community is learning about story points and how to improve estimates, other people in the same community are saying that you shouldn't use them. Given this apparent self-contradiction within the community, how is a novice team supposed to decide or recognize if they are following a useful pattern or a detrimental anti-pattern?
-
Again, I think you have to look at your own specific context, motivations, and execution. It's not prudent to say that you're going to side with one or the other camp "just because it sounds right," without objectively considering your own circumstances.