Scrum success stories

Scrum isn’t the only agile method (see my article Scrum and XP work well together), but seems to be one of the best ways to get started. As I mentioned in Failing with Scrum, Scrum is no silver bullet. It doesn’t guarantee success, but it improves the odds.

Over the past few years I’ve been involved in dozens of Scrum projects, directly or indirectly. Interestingly enough, every single case that I can remember has been successful (maybe I just have selective memory…)! The client has been happy with the process and wants to continue using Scrum in future projects.

In most cases Scrum has resulted in immense improvements. Based on interviews, most improvements are within the following areas:

  • business focus
  • productivity
  • product quality
  • team motivation
  • transparancy & knowledge spread

In some cases Scrum has resulted in only minor improvements, i.e. the client is only slightly better off than before.

In one case a client aborted a project shortly after introducing Scrum, but they considered it a success since Scrum helped them discover early that the project was doomed to fail (described in more detail in Failing with Scrum).

No clients so far have gone back to their previous process. On the contrary, every company that I’ve worked with has decided to ramp up and use Scrum on other projects as well. Several have decided to go "company wide" and introduce Scrum, lean and agile techniques throughout all layers in the company.

Here’s a quote from an email I received today (from one of my readers, not a client):

At this point I can already proudly mention, that the project has been just like in a fairy tale. We were able to finish the implementation well ahead of schedule and with a quality that has surprised many. One good indicator of successful first-ever-Scrum-project is that today all of our project managers have either completed or signed up for a Certified Scrum Master course. I bet we’ll soon have a few more Scrum projects running ūüėČ

Best part any way is, that the developers seem to love Scrum (just as you mentioned).

Thanks again for writing the book, it helped us a lot!

My book Scrum and XP from the trenches describes concrete agile techniques used in a handful of different projects within a single company. Some of the techniques failed, but we inspected and adapted and each project was a success, even those that seemed very bleak and uncertain at the outset.

After publishing the book I’ve received literally hundreds of emails from people using Scrum and/or XP, including many companies that were inspired to give agile software development a shot after reading the book. Very good to hear!

The book was not intended to be a "manual" or "cook book" for Scrum and XP – it was intended to be a case study with detailed examples. Although I stated that quite clearly in my disclaimer, many companies have nevertheless used it as a cook book and implemented Scrum exactly as described in the book. To my surprise, they have done well! Even in totally different contexts. The context of the book is a gaming software company, but I’ve received reports from companies building things such as flight control software and embedded software using the same process and techniques, and it has worked well!

I still don’t recommend using my book as a manual. I’m still dreading the email "Hi Henrik, we found your book and have implemented everything as described. And now the project went to hell and we’re going to sue you! Our software caused the nuclear plant to explode. See you in court!". But it hasn’t happened yet…

After all this positive feedback, and a complete lack of negative feedback, I’ve made some new conclusions:

  • Scrum appears to work very well in a very broad range of contexts
  • Some implementation patterns (= concrete techniques) are quite universal and can be applied in almost any context. I used to think they were more context dependent. For example:
    • Physical taskboards
    • Planning poker
    • Combining Scrum and XP
    • … and many more
  • Copying another company’s implementation is a good idea. But it should be seen as a starting point only. A code example. A template from which to evolve.
  • Make sure you have a coach. Doesn’t necessarily need to be an external coach, just  make sure you have somebody in the building who’s done this stuff before.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.