Is Working Software Enough?

For the past few weeks, maybe even months, I have started to feel like the dynamics between the Scrum team and myself, the product owner, were not working in the best interest of the product overall. The team seemed very concerned about achieving a high velocity. They showed reluctance to slow down and spend more time in “grooming” and planning. Previously, in an effort to optimize velocity and reach “hyper-productivity” the team had capped the amount of time the product owner could use for grooming at 5% of the sprint. However, I was starting to think that really wasn’t enough time. It was forcing a lot of important design decisions off onto myself and the UX designer without getting the opportunity to explore different options and get feedback from the development team. There may be situations where this setup works well, however I have a very smart and talented development team and I felt that spending more time grooming and brainstorming potential solutions to the problems on the backlog with the team prior to designing the solution would, in the end, result in a much better product. Not only that, but that additional grooming time would help increase the shared vision among the team which also seems to have been suffering. So I began to think about what the root of this problem was and why this reluctance might exist.

What about value?
One of the core values of the Agile Manifesto is…

Working Software over Comprehensive Documentation

Don’t get me wrong, I definitely agree that working software is much more valuable than comprehensive documentation. However, is working software really enough? What about valuable software? What about software that delights the customer?

If you go past the manifesto and dig into the Principles behind the Agile Manifesto, you see that the very first principle gets at this point as well…

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

So there we have it, the highest priority is to satisfy the customer with valuable software. I wonder, if this really is the highest priority, why didn’t it earn a spot on the actual manifesto? The fact that it has been left off the manifesto itself seems to have driven some potentially suboptimal practices. If you look at most of the mainstream materials out there on Scrum, for example, there are lots of resources talking about how to track and calculate velocity. But what is velocity? It is simply a measure of how fast the team can deliver working software. It helps the product owner determine how long it will take to get through the backlog. This is definitely important and useful information…but where in the manifesto or the principles do we value development speed? I can’t find it mentioned anywhere. So if we don’t value speed, why is it the primary thing we are measuring?

If our highest priority is “to satisfy the customer through early and continuous delivery of valuable software” shouldn’t we be measuring that? Shouldn’t we be measuring the amount of value delivered per sprint, or the effect of a sprint on customer satisfaction? Granted, these are much more difficult things to measure and track, but I have never even encountered the idea of attempting to track this mentioned in any mainstream agile materials. If we aren’t measuring and tracking it, how can we hope to optimize it? Instead, we are measuring and tracking velocity, so that is what we will naturally optimize. Scrum says it is the product owner’s responsibility to maximize the value of the product, but I have found few resources with suggestions on how to do that. I also haven’t found any mainstream materials that even recommend tracking value in a measurable way or pay attention to a metric such as value delivered per sprint or release. Instead we plaster velocity everywhere. We externalize the tracking of value and assume it is being optimized while we focus on optimizing velocity when in reality, we should all be focusing on optimizing value.

Thoughts from Agile2011
I was pleasantly surprised at how well many of the presentations I attended at Agile2011 tied into the value concept. I sat in on a few Lean Startup sessions and that movement seems to be much more in tune with this idea. Typically, they will complete one thing at a time, release it into production, and measure the results in order to validate their prior assumptions, then take the knowledge they have gained and make some more adjustments. So they definitely seem to put more value on the outcome (increased signup, conversion, or whatever they are trying to improve) than the output of working software. There was a great example of this recently on 37signal’s blog where they walk you through how they set out to increase the signup rate on their Highrise homepage in a three part post (Part 1, Part 2, Part 3). They had a goal of increasing the signup rate, so they would make a change, push it to production and do A/B testing to see the result. They would then take what they learned and make further tweaks, measure again, and keep repeating until they were satisfied with the results. This is definitely much more focused on delivering value than the typical agile project I have seen.

The Design Thinking camp also seems to be on the right track. I missed Mary Poppendieck’s presentation on this, but was able to attend a separate session on Design Thinking and reviewed Mary’s slides afterward. She is definitely in agreement that “the only valid measure of our success is their [product owner] success” implying that if the product owner is not tracking and prioritizing for optimal value, it really doesn’t matter what your velocity is. She also has a lot of good information on her blog like Don’t Separate Design from Implementation that talks about some of the problems with pushing the focus of design and value off the Scrum team.

I also sat in on a great presentation by Steve Denning about Creating Customer Delight that is summed up very well in his posts on entitled Agility is not Enough. He makes a very good argument that satisfying the customer with valuable software is not enough. We should be focused on delighting the customer. In fact, not only should the agile development team focus on delighting the customer, it should be a strategic objective for the entire company.

Next Steps?
Hearing all these great ideas at the conference helped me see the bigger picture and see what may really be at the root of the problem. Velocity is being measured and plastered all over the place so the team is very focused on optimizing velocity instead of optimizing value. Also, with many of the comments I heard from other attendees at Agile2011, it seems that this problem is much more widespread than just my team. I can definitely understand how this is a problem with the fact that what is claimed to be the “highest priority” principle associated with the Agile Manifesto is constantly glossed over and not emphasized in much, if any, of the mainstream materials. Not only that, but there is almost always pressure from above to “go faster” and now, with agile, we have this nice easy metric of velocity to measure how fast we are going.

So how do we get this intense focus off of speed and shifted onto value? I definitely don’t have the answers and am still working on ways to measure value and increase the visibility of that measure so it can be optimized. I’m also working to communicate that increased velocity is not the ultimate goal. Sometimes you have to slow down to speed up. However, I fear that communication can only go so far. Until there are measurements around value that are given as much visibility as velocity, the desire to optimize what we are measuring may just be too much. How does your team measure value and work on optimizing value?

Comments on this entry are closed.

  • Well said sir.  At my new gig, working software delivered on a predictable pattern is my sole goal.

  • Not sure why that last post was anonymous.  It was me… 🙂

Previous Post:

Next Post:

%d bloggers like this: