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

We’re Fast, We’re Not Cheap, But Are We Good?

Using the software term Sprint Velocity, I’ve mistaken Velocity for Speed for several years. Truth is, when I think of a treadmill, I might be confused about Speed too.

Speed and direction define Velocity. On the dashboards the software community is so enamored with, at best, we depict speed. Direction is mysteriously absent without leave (AWOL).

With Direction AWOL…

If you don’t know where you are going, it’s easy to iteratively not get there.
       ~David Hussman, 5:40 PM Nov 3rd, 2009 from TweetDeck

Good at Delivery, But Not-So-Good at Discovery

I have programmed with development teams that range from pretty good to pretty stellar vis-à-vis rapid incremental product delivery. But the products we built could have been better – particularly if we had been better discovering what our user community valued about our software.

The consensus at Code Freeze 2010 and DevJam’s developer Jam Session last night is that few of us have much of a clue about the people trying to accomplish things with our software.

Many projects cling to monitoring speed, but that’s not good enough. It reminds me of lyrics from the Steely Dan tune Babylon Sisters.

Well I should know by now
That it’s just a spasm
Like a Sunday in T.J.
That it’s cheap, but it’s not free

It doesn’t matter how fast we deliver if we deliver junk. Are there ways to measure quality? The Interaction Design community says so.

My Pet Product

I am laser focussed on a pet product. I want to experiment with giving my future user community a place at the table in iteration planning. I want my future user community to help us prioritize the product backlog.

I want to be abundantly transparent to them that their suggestions are acted upon and not ignored.

The cheapest and most direct measures of quality I have considered for this particular product are

  • How many community members can we enroll? 
  • How active are they? 
  • How long can we retain them?

Enrollment, Activity, and Retainment are the legs of this product’s stool.

Averting Usability Calamity Software

Can Usability Calamity Software – you know who you are – be averted by paying better attention to users?

What would the measures of quality be for your pet product?

Credit Due

Most of the observations I make about software these days –

the notable exception being giving the user community a hand in prioritizing incremental improvements

have been adapted, or stolen verbatim, from the folks on my software luminaries list. The gist of this post is derived from things David Hussman has said (and I probably mis-understood).