Scrum Anti-Patterns

#1

An anti-pattern is a common response to a recurring problem that is usually ineffective and risks being highly counterproductive. I love this topic and think it’d be cool for us to fire away on anti-patterns we’ve witnessed.

I’ll kick the conversation off and would love some great debates in here:

Sprint 0 - There is no such thing as a Sprint 0 in Scrum. So often I witness companies delaying getting started by doing a ton of upfront analysis and requirements gathering and calling it a Sprint 0. Smells like waterfall to me.

To get Scrum rolling you need a Scrum Team (PO, SM, Dev) and a Product Backlog (not all encompassing). By delaying, they are wasting precious opportunities to be empirical. Get the bare minimum and get rolling.

Agile antipatterns
#2

Function based scrum teams. I loathe them.

Having a UI team. A services team. A backend team. A testing team. Dear god, please make it stop.

And hyper prescriptive functional specs.

#3

Hate the desire most orgs have around heavy process around architecture review and info sec reviews! Just slows down the teams and creates waste!

#4

The one that irks me the most is the ignorance towards the PO Role. It is not a BA who writes stories!

#5

You got me started:

  1. Team Member allocations
  2. Project, instead of Product oriented teams
  3. Cross Functional means testers and developers on the same team regardless of skillset
  4. Not having a potentially shippable product at the end of a sprint
#6

The obsession with metrics (and I am a manger :stuck_out_tongue_closed_eyes:)

#8

I use Sprint 0 different than the way you describe. Typically my Sprint 0’s have always been where a new team has formed and the company just assembled them to to start work. Many people have little or no real experience with Scrum, so I teach by doing. I have the team act as POs and write their business needs and prioritize. I call it First Contact like in a real rugby scrum. I wrote a blog piece on this at http://www.gregmester.com/first-contact-in-a-scrum-sprint-zero/

As far as doing a bunch of upfront analysis, I hope they did that before they hired the team to work a business problem. Otherwise, that business just spent a lot of money to get a scrum team together to wait for the project.

#9

Having a time boxed Sprint 0 is not something we usually do and is not part of scrum. Instead we just do whatever prep work we can and then start as soon as possible. Better to start as soon as possible on sprint 1 then spend too much time planning as the plans will change anyway. Just enough to get started mainly.

If this works for you then that’s great, but what if you get enough done in 2 days of planning to start sprint 1 and your sprint 0 is scheduled for a week. Do you cancel it? I think this is why “sprint 0” is not a thing in the framework.

At the end of the day though, it’s whatever works! I’m just thinking about eliminating waste and focusing on value.

#10

The activities typically accomplished in “Sprint 0” can be very valuable to a team if done properly. I’ve also heard it called “inception,” which I believe is a RUP term (please don’t gag). The things that I believe add value are things like:

  • training on Scrum
  • team building activities like team working agreements and team charter
  • creating shared understanding of vision of the thing that is being built (typically this might be in the form of a vision and epics)
  • development of an initial backlog (with ative participation from the team). I usually shoot for a few sprints worth.

The reason I include the last one (initial backlog) is that I see MANY teams struggle with a poor backlog. Too often there is a rush to figure out what the team is going to work on the day before planning…or day of. Putting a little thought into an initial backlog gets the team thinking about how to break down the work into appropriate sized stories, gives the team a buffer of things to work on, and provides experience with the story writing process. Developing a shared understanding of the big picture can be a very empowering thing for teams.

#11

But is Sprint 0 delivering an increment of “potentially shippable” product? The increment is at the core of Scrum and is one of the three artifacts. I’d rather abandon the Sprint 0 terminology and call it “inception” because, to me, it’s not a Sprint.

#13

I agree on the no sprint 0… But it does get a bit grimmy when the bean counter us it hide cap vs expense. Inception at the current client is all expense and not capitalizable. Through sprint in front of it and cap meter starts!

#14

Interesting point @Scrummando

#15

@Scrummando I have witnessed the same. By definition, it is an expense which as you implied companies grimace at. I believe it’s up to us to ensure the Scrum Team understands the importance of an Increment.

However, can’t those activities happen while we’re striving to build an Increment in Sprint 1? Shouldn’t we have just enough of a Product Backlog by the time we get to that point? I suppose it’s contextual but I am all about starting as soon as possible so there is no delay in starting self-organization and beginning the empirical process.

#16

Ideally this is the case but some of the organizations organization i work with a slow and monolithic. The Intimation on some of these initiation go on for weeks or months. Even if the product or project will not kick off for months.

#17

@Scrummando true story. It’s the life we live in these big corporations.

#18

I am not such a fan of the term “anti-pattern”. Firstly Scrum is not a pattern but instead a framework which allows add-on practices. Being a framework; it is minimal and when you really,really, really get to understand Scrum you will notice that it is actually ridiculously minimal and simple. With such minimalist, it then becomes a matter of you are doing Scrum or you are not. For the rest, well the framework is designed to be flexible; so it is not really an anti-pattern. Instead a pattern that either is working for you or is not. This leads to changing what is not working, so it becomes a moot point.

#19

@BrettM would you agree there are some prototypical behaviors that orgs exhibit that detract from following the scrum framework? Calling them anti patterns may be misrepresentative, but we’ve all seen them at some point I imagine.

#20

This sometimes frustrates me about Scrum and Agile in general. Every thing seems to always be broken down to a very binary level - the answer is either black or white. However, more so when working in a large corporation there are politics and general business rules that put some situations in a grey area. It’s at these times I get frustrated the most - I reach out for help only getting a cliche black and white response that isn’t very helpful.

One programmer I work with once compared Agile to High School Physics - all of the problems are solved in a vacuum and the solutions don’t work when you get to the real world. I get his point - often large corporations aren’t perfectly aligned to be agile and you need to make do. (I have a draft topic with real quotes from programmer about agile

I also agree with @BrettM on the fact that everyone seems to frequently get caught up in the details. Isn’t the goal of all of this to adapt to change and deliver incremental value? If the team is accomplishing that, who cares if they called their first Sprint 0 or 1? (most programmers start with 0 anyway :wink:)

I used a Sprint 0 in June with a new client and it worked out great! We did nothing different - the only difference was we were trying to get a baseline on velocity and I was teaching the team the different ceremonies as we went. Once we finished it, we had a handful of tickets completed (setup the GitHub repo, work on the first set of UI mock ups), a base velocity to roll into Sprint 1 with, and the team was comfortable jumping in and committing to a real batch of work for Sprint 1. We also bill by the Sprint - so this was kind of a freebie for them to see how things went and what to expect.

Since then we’ve done about 5 or 6 Sprints, all ending with a incremental piece of software that could have shipped to production.

#21

During Daily Scrum is it Anti-Scrum to talk about the stories or the tasks as a status report vs. Asking everyone on the team the 3 questions? My vote is that it is anti-scrum. I think it takes away from everyone being involved as a Team. Thoughts.

#22

Yes the daily scrum is supposed to be a planning meeting for the team. Lot of teams use this as a status report for the scrum master which is def an anti pattern