Monday, July 25, 2011

Scrum: Helpful or Harmful?


I've noticed an interesting side effect of agile "mainstreaming". I spend less time convincing folks that certain processes and practices aren't crazy. The downside of this is that often times only the processes and practices are in place.

I've recently written a couple of blogs with regard to "commitment" and "estimates". Both are two words I hear quite frequently at places that have "adopted" the Scrum framework, and are also frequently abused. Many of these places haven't taken the time to read the original scrum book, or usually any scrum book, or sometimes any book at all, or blogs, or even just the Agile Manifesto!

This leads to problems such as "sprint commitments" being in conflict with "sustainable pace" for a development team and many other general contradictions of the underlying values and principles of agile that were originally behind Scrum.

The basic problem I see with Scrum is also its benefit: it's very easy to adopt. Change some titles around, rename some meetings and *poof* we're an agile organization now! And some places operate under this assumption for a long time. Because of this, some members of the organization get a bad taste for agile, while others see some initial benefit but then are surprised when things slow down or relapse.

There are two reasons for this slowdown or relapse:

One is the missing technical practices. For the most part XP has taken care of this, but how well understood or implemented the XP practices are in places such as these is questionable.

The second, more insidious problem, is that no underlying culture change ever took place. No spirit of inspect and adapt or continuous learning was ever instilled. The 'why' behind the 'what' was never explored and understood.

So in the end, has Scrum helped or harmed? I find this still a tough question to answer. I do feel that Scrum did a great job of getting many of the ideas spread around. On the other hand, I find a lot of need to un-Scrum, or rather work to instill the missing values and practices now, with the added baggage of over coming the fact folks thought they already made a big change.

3 comments:

  1. I think the culture change is the #1 problem. It's easy to teach Scrum (at least, the exterior PM framework of Scrum). It's not hard to teach XP practices, tho some, like TDD & automated tests, have a steep "hump of pain" (to quote Brian Marick). But IME it is very hard to teach cultural change, or to influence culture.

    I agree, the ease of implementing scrum is both a blessing and a curse. I wish people would stop looking to some "methodology" for the answer, and start with "how can we improve the quality of both our software product and our work lives?"

    ReplyDelete
  2. Lisa: I agree that culture change is the core problem. Matt, you've highlighted the interesting problem: when we focus on describing agile/scrum/etc., the words we use fall into that organization's existing context, and so there is real risk that what we say and what they hear may be very different. I'd bet this happens more often than not.

    I like to accentuate the positive whenever possible, but because of the problem you've described, I feel it is important to also talk about what agile/scrum culture is _not_. This involves contrasting the underlying values of the manifesto with the values in evidence within the organization, as well as providing a game plan or a set of practices for improving. A group of people have to come to realize that A) change is needed, and B) specifically what needs to be changed.

    ReplyDelete
  3. I like the phrase "''why' behind the 'what' was never explored and understood" I think that's where most project fail these days. Not enough thinking about the 'why'.

    ReplyDelete