In a little Twitter exchange, Ron Quartel suggested that Scrum teams fall away from Scrum more often than XP teams fall away from XP. He suggested that this is because Scrum is owned by managers, while XP is owned by the team. Let’s explore that subject.

Do scrum teams fall away more often?

I don’t think we know that. It would be really interesting to know. It would also be interesting to know, for any method, how often, and why, that method’s adherents fall away.

Why might teams fall away?

My guess is that there is a single summary reason why teams, organizations, or individuals fall away from any process or practice:

The perceived benefits of the thing do not seem to justify the perceived costs of doing the process.

It seems to me that this is a gimme: we keep doing things that we believe pay off and we stop doing things that we believe do not pay off. We need more detail on who stopped it, and why. Here are a few possibilities:

  • The organization’s culture does not support encouraging responsibility and trust downward in the organization. Accordingly, they sabotage or terminate processes that rely on that sort of thing.
  • An organizational change is followed by a new broom, imposing the broom’s favorite approach over that which has gone before.
  • The larger organization doesn’t see good product coming out, so withdraws support for the process, or actively stops it. “Larger organization” could mean the product organization that provides product owners, or some larger containing corporate entity. It could mean the development organization, as well.
  • A Product Owner finds attending team meetings to be unproductive, and stops going.
  • The team does not use good technical practices, and delivers few, or not very interesting product increments. The organization concludes that the process is not working. Not using good practices could be a result of not knowing them, or being somehow discouraged from using them.

For a process to be dropped, it seems that either the people actually doing it have to decide to stop, and to be permitted to stop, or someone outside, and probably “above” the team has to remove support or decide to stop.

How do Scrum and XP differ here?

Let’s look at Ron Quartel’s suggestion, that XP is more owned by the team, and Scrum more owned by management. My guess is that this is true: it’s management who sends people to CSM classes, and management who expects that the result will be improved “productivity”, for some value of productivity. In contrast, XP, in my experience, is rarely imposed. Instead, some leaders on the team know XP, or hear about it, and the team adopts the parts of XP that they can adopt.

Now there’s another angle that comes in immediately. XP’s business-focused container is almost the same as Scrum’s. The big difference between the two is that XP includes technical practices. These practices are interesting to developers, and the developers often find the practices to be both enjoyable and productive. XP teams are likely to find things in XP that they actually enjoy doing!

Scrum, on the other hand, has little or nothing in it that developers enjoy as developers. Scrum has roles that are not about development, and meetings that are not about development. Scrum does call for “self organization”, which developers might enjoy. It’s not clear just how much self organization is permitted in the average Scrum team. The operative word is very likely “permitted”.

From this angle, it seems quite likely that developers will enjoy XP more than they enjoy Scrum. Developer things are explicitly valued in XP, and they are at best tolerated in Scrum, or very rarely, encouraged but optional. To the extent that this is true, it might mean that an XP development team is less likely to fall away on its own than a Scrum development team.

When an XP team does fall away, in essence it devolves to Scrum. It keeps the outer practices of product ownership and planning, without the development team behavior that makes it click. And it devolves to “flaccid Scrum”, because it will be less able to get done, it will slow down, it will produce more and more defects.

This suggests that when an XP team gives up XP, the larger organization, either the business side or the development management side, will see fewer and fewer benefits from the process, and will become more and more likely to let the process die.

Isn’t that vanilla Scrum?

Since XP is almost exactly “Scrum with technical practices”, whatever forces at to cause an XP process to be dropped by the business people or by development management must apply almost exactly to Scrum, in its vanilla form without development practices.

Scrum teams without development practices are able to get less done; they create more and more defects; they slow down more and more as their design deteriorates without test-supported refactoring.

Scrum, without development practices, becomes boring to management. It doesn’t deliver enough value to justify continuing it. Sooner or later, support for Scrum will drop below the critical value to keep it alive, and Scrum will die.

A tentative conclusion

It would be useful to collect some data, if that’s possible, since the following argument is only theoretical, although I find it credible:

  • XP without doing technical practices is nearly indistinguishable from Scrum;
  • Doing Scrum, or XP, without technical practices, inevitably leads to poor progress;
  • Poor progress results in decreasing support for the process;
  • When support gets sufficiently low, someone kills the process.

Any attempted incremental process without solid technical practices is on a slide toward death.

  • By the book, Scrum does not include technical practices;
  • By the book, XP does include technical practices;
  • XP by the book is less fragile than Scrum by the book.

XP, once in place, is less likely to die than is Scrum.