• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Tim Cooke
  • Jeanne Boyarsky
  • Bear Bibeault
Sheriffs:
  • Knute Snortum
  • paul wheaton
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Ron McLeod
  • Piet Souris
  • Ganesh Patekar
Bartenders:
  • Tim Holloway
  • Carey Brown
  • salvin francis

Head First Agile: Any potential antipatterns in Agile?

 
Ranch Hand
Posts: 201
1
Python Ruby Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Author
Posts: 81
6
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 201
1
Python Ruby Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
Sheriff
Posts: 13716
227
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 13716
227
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Destroy anything that stands in your way. Except this tiny ad:
create, convert, edit or print DOC and DOCX in Java
https://products.aspose.com/words/java
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!