Australian Scrum Community

Some Turbulence Expected

Posted by Andrew Hallam to 18 November, 04:28 PM

Hot on the heels of yesterday’s cautiously optimistic post comes a warning from James Shore that agile is declining because a lot of agile teams are failing.

Now many people who call me already have Agile in place (they say), but they’re struggling. They’re having trouble meeting their iteration commitments, they’re experiencing a lot of technical debt, and testing takes too long.

Scrum, ScrumMaster certification and the Scrum Alliance all get a mention as part of the problem due to Scrum’s success in obtaining mindshare in the Agile world. This resulted in lots of interesting comments and additional blog posts. So far:

In the comments to his own post James Shore clarifies:

One thing I want to mention is that I don’t think Agile failures are because of Scrum. If XP was the dominant method, then we’d be seeing XP failures. (I do think, however, that XP fails quicker and more obviously, and is less likely to be introduced into situations where it can’t succeed.)

Although a lot of people have taken my essay to be a condemnation of Scrum, that wasn’t my intent. Instead, I was trying to highlight the failures that I see and the factors that contribute to those failures. The biggest problem isn’t Scrum or even CSM training, it’s people eating dessert and skipping their vegetables.

As Franck Villaume commented on the InfoQ post, parallels can be drawn from the long line of cool new things adopted by the IT industry. Once the hype cycle begins people start adopting the cool new thing just because others a doing it and, well, we all want to be working on cool stuff.

The problem is that many adopt the cool new thing without fully understanding it, or its implications on their people and their organisation at large. Some time later the results don’t meet the unrealistic expectations created by the hype, and people get disappointed. Then failures occur. Perhaps agile is in the trough of disillusionment.

However, after the reality check of a few failures some learning occurs. People start to understand where the technology is appropriate, and then adoption of that technology slowly increases.

With respect to Scrum, anyone who adopts Scrum and thinks that is all they need to “do agile” probably should take a closer look at what Scrum does not provide (a topic for another post).

Comment

    1. 19 November 2008, 08:09

      Scrum doesn’t provide a lot of stuff. Instead, it exposes a lot of stuff. Like, whether you can build a potentially usable or shippable increment of software in one iteration, or sprint. That is very hard to do and most organizations don’t have the engineering skills and infrastructure to do so. We measure what they can do, and the rest of “undone” work has to be done at the end of the project or release, or stabilization phase. This includes stuff like refactoring, integration and regression testing, performance and stability testing, etc. That the developers can’t get this done within the iteration is terrible, and certainly backloads the whole project. However, now that we know exactly how bad it is, we can quantify the benefits of improving it. This certainly tests the engineering organization – do they want to go through the hard work of attaining competence, or would they rather change Scrum so their inadequacies are no longer visible.

      Scrum will favor those who don’t change it and use its transparancy to identify and solve engineering problems. They will work to create a full, shippable increment every iteration. These will be great engineering organizations that will outcompete others every day. Think Toyota and GM.
      Ken


Commenting is closed for this article.

  :