Any stories where trying to apply Scrum went wrong?

Question

Question marked as community wiki for an obvious reason.

My colleagues are betting big on Scrum, they are super-excited about it. However, when doing day-to-day programming the priority is often to "get it done" over "try to do it right the first time". Of course, time-to-market matters, but then having to hire an army of tech support and having a large backlog of old yet critical bugs does not sound right either.

I worry that with Scrum we will start following the form over really trying to understand what it is for and how to work smarter.

So, I wonder - are there well-known Scrum smells out there? Have you been using Scrum methodologies and noticed that they have not helped much or created problems of a different sort? I am sure it would take guts to admit some sort of failure at something you worked on. Perhaps it happened in the past, or a friend of a friend told you a story once while in a bar ...

let me know if you have questions about the question. Thanks.

Answer 1

When I think of SCRUM, I think of "The Homer":

Answer 2

scrummerfall and scrumbut

Common failure modes for teams trying to do Scrum are scrummerfall and scrumbut. Each is about saying/thinking you are doing Scrum but leaving out important aspects of Scrum or not discarding harmful aspects of waterfall.

Answer 3

I worked at one company that was trying to introduce Scrum to a largely custom software outfit that still used traditional cost estimation of man hours (months), etc. The lesson there was clear: your team's velocity should drive the cost estimation, not the other way around. This was particularly destructive for a while, since basically the delivery date was fixed from the start without consultation with the development team, and therefore the average velocity of the team was predetermined. As a result, we ended up working huge amounts of overtime only to be left with an unrepresentative velocity that was used for FURTHER planning.

To learn from that lesson, the development team was given the opportunity to participate in the proposal and pricing phases of projects. This exposed a new lesson: if you're spending 20+ hours per week in planning meetings (even after reaching a stable process), you're doing Scrum wrong. The issue that we had was that our business model/customer relationships still mandated line item breakdowns of cost, heavily detailed requirements, etc. We were thus required (as a team) to basically break down, plan, and estimate the cost of (via planning poker) every future sprint item at the project get-go. This made it impossible to leverage one of the intrinsic features of Scrum: to perform just-in-time planning whenever possible (since requirements are going to change anyways).

I remain unconvinced that there is a recognizable variant of Scrum that would have worked well for that business model, and the reality is that as a development team you won't have much luck implementing Scrum without higher-level buy in. Yet I've seen Scrum be hugely successful at other places I've worked. My personal suggestion is to hire a consultant to evaluate whether (and how) Scrum has something to offer your company, and what it would look like. Remember, Agile methodologies are meant to be malleable, but bend them too far and you're unlikely to be benefitting from them.

Answer 4

Toward a Catalog of Scrum Smells, from Mike Cohn:

http://www.mountaingoatsoftware.com/system/article/file/11/ScrumSmells.pdf?1267552461

To be successful with Scrum you have to respect its core principles, and not try to apply every other aspects.

I've seen dozens of development team trying to do scrum and failing because they did not take the appropriate training. In the worst case they loose the trust of their management.

Hiring an experienced scrum master or coach will increase your chances of success.

Answer 5

Martin Fowler gave a talk recently thats interesting http://martinfowler.com/snips/201007151824.html. One of the points he made was that to be agile there are process changes needed as well as different technical practices. He noted seeing companies failing doing agile as they do the process change without the corresponding changes to technical practices. He notes Scrum as being a common process change that people make without the change to technical practices.

Answer 6

Straw-man waterfall has an escalating cost of change.

Scrum assumes a low, steady cost of change in order for its velocity and estimation measurements to work. However, Scrum doesn't provide any tools or practices to make the cost of change stay low.

Scrum also assumes that a team are capable of trust and collaboration. The practices encourage this, but tend to fall apart if the culture's not right. Here's a blog post I wrote on Cargo-Cult Agile values: http://lizkeogh.com/2009/05/22/cargo-cults-and-agile-values/

I suggest focusing on collaboration and communication, and running with some of the practices from XP. TDD, refactoring, collective code ownership and pairing are good. I've seen many Scrum / XP hybrids work with good results.

It's unlikely that retrospectives will flag up lack of technical practices as useful changes to add to the process, because the feedback loops from not having them are in the order of months - unnoticable within a sprint. Any cultural issues will tend to make retrospectives less safe than they should be, so they won't get flagged up either.