09 March 2010

Scrum's Achilles Heel & Where Scratch Meets Itch

Anders Storm, Head of Development and IT at Tekis AB, posted a cogent reminder of all that's good about Scrum (see Anders' post Why I Like Scrum! on his blog Product Development).

Scrumbaya (like Kumbaya)

Anders and I share many of the same likes about Scrum. Scrum was my first step into Agile (thanks Markus). I started a jaded curmudgeon (my apologies Markus), but my Scrum-mates revolutionized my thinking. I am grateful to the pioneers of Scrum.

I like Scrum for its humanity, accountability, explicit trust in programmers, and inherent fairness.

Needs Improvement

I have one criticism of Scrum, but it’s a big one…

The Achilles Heel of Scrum is the Product Owner. The Product Owner is a serious flaw in the approach. In my experience, Product Owners operate on notions about what’s most valuable (what’s a high priority), rather than on verifiable data.

The Scrum community applauds itself for its transparent burn-down charts and their inherent "velocity" when what they’re actually transparent about is speed (e.g., because the direction component is sorely missing).

It bears repeating that
It doesn't matter how fast we deliver, if we deliver junk.
Verifiable Value

Scrum must evolve beyond the concept of a limited user proxy, like Product Owner, then figure out ways to better understand, measure, and verify the user experience.


In almost all cases I can think of,
the people actually using our software is where the scratch meets the itch. 
Our goal, as always, is to produce incremental value. But in this case, it comes via verifiable value (direction) and not just speed.

I am looking for ways to get to Verifiable Value and to limit Seat-of-the-Pants Guesses.

More
Posted by at 3/09/2010 09:32:00 AM
Labels: , , , , , , , , ,

7 comments:

  1. Hi Bob,

    Very much agreed - switching to Scrum just means you'll be able to deliver some version of "junk" more quickly with high visibility.

    Just as Scrum trusts engineering to create a quality product, it also trusts product owners to define a quality product. Scrum doesn't prescribe coding guidelines or which design patterns to use, just as it doesn't lay down more specificity in how to go about populating the backlog with quality items (just what a good backlog item looks like so it can be burned through).

    The good news is that Scrum frees (or should be freeing) product owners / product managers from the pain of creating lengthy PRDs that aren't consumed, giving them more time to do what they should be good at - finding out what to put in that backlog.
    ReplyDelete
  2. Well said Rob.

    I like the usability quote in your blog post The Matrix, On Usability:

    "That’s how it is with people. Nobody cares how it works, as long as it works." ~ Councillor Hamann to Neo
    ReplyDelete
  3. Hi Bob,

    Thank you for quoting by blog post :-).
    Like all great things Scrum has it flaws as you point out. I agree that the Product Owner becomes a single point of failure and he/she could never know everything from customer requirements to usability etc. I have seen how important a very good Product Owner is in both waterfall and Scrum development. Independently what methodology you use imo you need a good Product Owner that uses all input form all stake holders to make the best possible product. However coming from the mobile industry recently being one of the person behind the first smart phones with touch screen from SE and see how bad user experience (UX) and the usability we delivered in 2002-2003 with the first smart phones. I know how hard it is to get this right, the way Apple have done with for example Iphone. So my point is independently what methodology you use you must spend more time on UX and GUI to make your products attractive and this is a problem many of us have even if we use the best process and product owners available. Then to measure the customer satisfaction is of course very important (I call it business value: quality, UX, usability, perceived quality etc..)

    Any way you have a point and I would like to know how Appel does it? :-)

    Anders Storm
    ReplyDelete
  4. Anders,

    Thanks for inspiring this post! Again, you and I are in agreement.

    I suspect Apple's usability successes are traceable to Steve Job's organizational DNA.

    Plus, Apple does a remarkable job "convincing" people Apple products are superior by paying attention to all the details of the customer's experience from projecting an Apple product persona & image to packaging.

    Cheers,
    Bob.
    ReplyDelete
  5. Getting business requirements right is always an issue. I don't think the issue changes because we give the title of "Product Owner" to the person responsible. So I don't see this as a Scrum weakness, but a problem area for companies in general.

    Kevin Thompson, Ph.D., PMP, CSP
    Senior Instructor and Consultant, cPrime
    http://www.cprime.com/training
    ReplyDelete
  6. Kevin,
    Yes building the right software is an ongoing issue. It's a Scrum issue in-so-much as in Scrum one person is labeled as the proxy for whatever constitutes value - an impossible position to put someone in. Thanks for chiming in.
    Cheers,
    Bob
    ReplyDelete
  7. Bob, Kevin, Rob and Anders,

    Thanks for this post, and comments.

    My perspective is that Scrum can have its strengths, but it is not a panacea. As with everything, common sense should prevail.

    Yes, it should free the Product Owner up to allow them to spend more time really understanding what the customer wants/needs (thanks Rob).

    However this does not mean that theirs is a sole responsibility (in my view) for thinking about the customer.

    It would be the same as stating that the Scrum Master has singular responsibility for making sure the scrum process works - yes, they are accountable, but everyone needs to contribute!

    Paul
    ReplyDelete

Subscribe to: Post Comments (Atom)