Now, it’s time for some specific, although simplified, examples. Imagine a clothes shop that also sells through their web site.

Stakeholder Goals

Stakeholder Goals aim at identifying who it is that needs something to be improved, and what that improvement is for them. For example:

Sales Manager Double the revenue from sales through web site within a year after release
Operations Manager Reduce the Operations and Maintenance costs related to this web site by 50 % within a month after final release
Web site editor Reduce effort spent publishing new clothing items by 50 % within a year after release

The point is – identify the major stakeholders and find out what’s valuable for them.

Product Goals

The Stakeholder Goals then need to be transformed into Product Goals – qualities that the product should have in order to fulfill the Stakeholder Goals. Examples:

Product Goal Name: FindItem.Fast
Gist: The user should spend as little time as possible finding the clothing item she wants.
Scale: The time it takes a user to find the clothing item she wants. Average, in seconds.

The important thing is to construct a scale, a way to measure the important qualities, so that the effect of design ideas and implementations can be either estimated or actually measured. Once the scale is in place, we can set a baseline and goal, as well as noting an “acceptable” level, in case we don’t get all we want on all the various Product Goals.

In this example, also note how the focus shifts from simple functionality to a more usability-ish approach, including a usability-like test. Some more examples:

Product Goal Name: Maintenance.ReduceEffort
Gist: Operations and Maintenance costs should be as low as possible
Scale: The time it takes an operator to find and fix a simple error, including stopping and starting the system. Average, in minutes.

Product Goal Name: PublishItem.ReduceEffort
Gist: Editors should spend as little time and effort as possible publishing new clothing items.
Scale: The time it takes an editor to publish a new clothing item, including verifying and possibly fixing appearance on web site. Average, in seconds.

With 10-12 goals like this, we have a really good foundation for steering the project towards creating real value for the customer. Also, keep in mind that the primary use of the goals is to set direction and help prioritize what to do next – it is not to measure success.

Benefits

Now, if we can do this, use the improved Value Process centered on quantified goals, I see at least three huge benefits compared to the standard Product Backlog-centered approach.

1. Everybody knows what is valuable – “value” is made explicit. We no longer have to look behind the Product Backlog, or ask “why” multiple times, in order to figure out what the customer finds valuable. It’s right there, in our face, giving the customer and the developers a very potent tool for evaluating ideas and implementations, prioritizing and basically steering the project in the best possible way.
2. It’s easier to manage the Product Backlog. The Product Backlog is no longer an exhaustive list of functionality to implement that has to be constantly prioritized. Instead it’s a (usually) much shorter list of ideas, all of which are not going to be implemented.
3. We utilize a much larger group of brains to find the good solutions. The customer is no longer alone in her task to find good ways to create value through the project. The developers are no longer limited to just finding good ways to implement a set of user stories. Instead, the customer invites the developers to use their impressive creativity and problem-solving skills to find good ideas for how to reach the goals. The developers go from functionality-implementers to goal-seekers, from implementing means to finding means. Besides resulting in better ways to reach the goals, there are so many positive secondary effects, especially with regards to motivation and collaboration, that one really should not underestimate this benefit.

Summary

In part 1, I looked at three problems with the Product Backlog as a tool for creating value. In part 2, I rose one level and looked at the flawed Value Process centered on the Product Backlog, and proposed an improved Value Process centered on quantified Goals. In this final part, part 3, I gave simple examples of Stakeholder Goals and Product Goals, as well as the benefits to gain from working this way.

References

I did not make up all of this myself (now, there’s a surprise!). The improved Value Process is basically Evo, created by Tom Gilb as early as the 1960′s, and first published in his book “Software Metrics” in 1976. Tom has developed Evo further, working with his son Kai for the past 20 years or so. You should check their web site, www.gilb.com – a treasury of papers, presentations and book chapters and, of course, the authorative source on Evo. The Gilbs are very open with all of their material.

Also, Ryan Shriver has a nice web site called The Agile Engineer, with several good papers and presentations on how this value focus can work with Scrum.

The value process in agile software development projects is flawed, and the Product Backlog is at the center of it. It normally goes something like this:

Flawed Value Process

The customer has some challenges, and starts a project to address them. The project’s goals are formulated – and goals are value statements, explicitly saying what the valuable results of the project should be.

Based on the goals, the customer starts working on the Product Backlog, with its user stories. The user stories, as we saw in part one, are means to reach the projects goals, or ends. In this process, the customer assumes that the user stories she writes are necessary to reach the goals. But there’s no real checking if that assumption is true, if the successful implementation of those user stories does indeed bring the customer closer to the goals.

So this step is basically a one-way process. The goals do not change as a result of creating the Product Backlog, and alternative means (e.g. a different set of user stories) are not considered in any serious way.

Now, with the first Product Backlog established and prioritized, implementation starts with early and continuous delivery of software, checking off from the top of the backlog.

We usually are very thorough in verifying that what we implemented is actually what was asked for in the user story. So this is a two-way process, with evaluation and feedback from implementation to user story.

However, there’s no real evaluation and feedback towards the goals, the value statements! And that is the most interesting part – did we actually get closer to the goals? Ok, so we have the demo where the customer can see what’s been implemented and do some matching in her head and adjust the Product Backlog accordingly. At least, that’s what we hope, but we can’t know. So this is a very weak evaluation and feedback mechanism.

We need something better.

Improved Value Process

This is how I’d like it to be.

The customer has some challenges, and starts a project to address them. Analyzing the challenges, the customer creates goals at two levels. First, she finds out who is it that needs something to be improved, and what improved means for them. These are stakeholder goals.

The customer then translates these into product goals; qualities that the product should have in order to fulfill the stakeholder goals. Both stakeholder goals and product goals are quantified.

Next, the customer and the developers brainstorm various ideas for how to reach these goals, and evaluate those ideas up against the product goals. When we have found what looks to be the best idea at this point, that is, the idea that brings us the farthest towards the goals at the least cost, we start implementing.

Once we’re done implementing, we evaluate the implementation against the goals. What we thought at the previous step is no longer important – the important thing is, did we actually get closer to the goals, and how much? Since the goals are quantified, we can get a pretty accurate picture of where we are at the moment. Also, the implementation may show that some goals should be adjusted, so there’s definitely a learning process involved.

Now, this is all theory so far. In Part 3 I’ll show some examples of what stakeholder and product goals could look like.

Ok, we all want to create value with your software projects. Using agile methodologies is a great way of accomplishing that. But as I’ve gained experience with agile methodologies, I’ve surprisingly found that the Product Backlog is actually hindering us from developing the most valuable software. It’s hugely superior to the standard requirements documents of the Dark Ages, but still – when it comes to creating maximum customer value, the Product Backlog is a hindrance.

I think there are three problems with it.

Huge pile of means

Problem # 1 is that the Product Backlog is a long list of means. It doesn’t state customer goals or customer value, but means. That is, it doesn’t say where the customer wants to be, only how the customer intends to get there. In very small steps, called user stories.

Let’s take a look at a typical user story:

As a repeat user
I can personalise my start page
So that I can get quick access to stuff I care about

That last line hints at a need for a type of user. However, it says nothing at all about why the customer would want to spend money, time and energy on developing, testing and deploying this functionality. Fortunately, good agilists habitually use this important question:

Why?

So, when discussing a user story with the team and the customer, we ask “why” – often multiple times – to work our way backward from the user story itself to the reason for it – the customers’s goal with it, why the customer values it. In this case it might be that the customer has a problem with users not returning, and it would be valuable to the customer to get the users to come back (and possibly spend more money there) - and this user story is one of several means to accomplish that.

Now, when the goal is found, we then ask “Now, is there a better way to reach this goal?”, possibly resulting in a different set of user stories.

But this is quite a backwards way of discovering the customer’s goals. If we want to create maximum value, there must be a better, more direct way.

Huge pile of means

Problem #2 with the Product Backlog is that not only is it a pile of means; it’s a huge pile of means. Imagine a Product Backlog with 500, 200 or even just 100 user stories. It’s quite difficult to look at a Product Backlog that size and figure out where the value is. Also, it gets increasingly difficult to apply the “why” question as the Product Backlog increases in size.

Focuses on functionality

The third problem with the Product Backlog is that it focuses on functionality. A Product Backlog consists of user stories, and the user stories describe what somebody can do with the system, the system’s functionality. But

It’s not about the functionality!

Let me repeat that, just to make sure it’s not misunderstood:

It’s not about the functionality!

Think Twitter, or Google Docs. They didn’t succeed because of loads of functionality. Or let’s use a replacement project as an example. The reason for the replacement project is not that the customer wants more or better functionality. (Even though we sometimes add that as a goal, probably to make it more likely the project will fail.) The reason is usually something like

“This system is running on crap software and crap hardware. We need something better, or else…”

And if we analyze that, we find that the reason for the project is that

Something needs to be improved for somebody.

I believe that’s true not only for replacement projects, but for all projects, including those we software people are often involved in – product development or product improvement. And then we better start by figuring out who these somebodies are, and what this something is, and what improved means.

We’ll explore the value process further in Part 2.

Norway has embraced agile methodologies. Now we need to stop only evangelizing the positive effects, and start discussing – and solving – real challenges encountered in agile projects.

I think agile software development is a huge step in the right direction compared to traditional software development methodologies. However, agile development in its current form is not the end station. We can – and must – get even better. Anyone who has run an agile project has experienced problems and setbacks that aren’t normally addressed in a standard presentation of agile.

There are real challenges tied to agile methodologies, and all of us who preach agile, must dare to acknowledge and discuss that. That is important if we really want agile development to be a success, live up to its potential, and not become just another hype in history’s graveyard.

So, to get started, here are three of the challenges I’m contemplating nowadays.

Value, not Functionality

The first one is to deliver value. The first of the twelve principles of the Agile Manifesto relates to delivering valuable software early and continuously.  We also like to say we deliver the most valuable parts first. This gives better cash flow and ROI, and is a great principle.

In practice, though, agile projects deliver functionality, not value. Most of the time we have no idea how much value this functionality has to the organization, or even if it would be economically smart not to develop it. We just leave it to the Product Owner or Customer to prioritize the functionality, and then we hope that it leads to us delivering the highest value first and maximize ROI. We may be right, we may be wrong – we don’t know, we just hope.

So, we need better methods of defining and measuring value. This is, by the way, the subject of my talk at this year’s JavaZone – the talk is entitled “How much value have you delivered lately?”.

Goals, not Requirements

The second challenge I’d like to mention, is that agile projects steer towards the Customer’s requirements, not the Customer’s goals. The well-known Product Backlog from Scrum is an example of this. We describe requirements as User Stories, put them into the Product Backlog, and then we measure progress as we finish off the Stories. We are willing to change the requirements and re-prioritize, much more than in serial projects, and that definitely helps the project succeed.

But – finishing off requirements is not the important thing. Reaching goals is. The requirements simply constitute a set of hypotheses for how one can reach the goals.

So, we need more focus on defining goals and steer towards them. I’d like to mention that Evo, created by Norway’s own Tom Gilb, is a well-tested alternative focusing on goal fulfillment.

Support the Customer

The third challenge I’d like to mention is that most of the difficult stuff is, especially in Scrum projects, pushed onto the Customer – the Product Owner. Not only is the stuff difficult, it’s coincidentally the stuff that, to a large degree, determines if the project is a success or not. Stuff like organizational buy-in, balancing different stakeholders and interests, determining when to release, prioritizing and determining what goes in and what doesn’t, etc. And yet we don’t say too much about how the Product Owner should manage all this stuff. A Product Owner is usually very competent in his domain – but that domain is usually not project management.

So while the development team is happily working their way through the sprint, protected from disturbance from the outside world, the Product Owner has to prioritize requirements, create buy-in, negotiate agreement, do all sorts of internal politics – while simultaneously providing the development team with all and any clarifications needed.

We’ve done significant progress in the way the development team works. Now we have to look up from the design, development and test processes. We have to start focusing on the Product Owner and the organization around her, and provide real support to the important role the Product Owner posesses.

The Point: Take Experience Seriously

Ok, so we need better ways of measuring value, stronger focus on goals and how to reach them, and improved support to the Product Owner and the organization surrounding her. Still, these are simply three challenges that I find important nowadays. Other people will have different priorities, based on their context and experience. My main point, however, is that we start discussing these real challenges that real people meet in real projects.

Until now, capable peoples specific challenges have too often been met with any variant of “But you’re not doing it right.” Especially if they’re not viewed as agile-savvy. But this kind of answer simply doesn’t help. And if agile software development is to be a real success, people need to find help also when they’re struggling, also when they’re “doing it wrong”. And, equally important: If we brush off the challenges people experience, we deprive ourselves of the opportunity to learn, to enhance and improve the agile methodologies – because we’re not taking feedback from actual experience seriously.

As one of the enthusiast who have worked to spread agile methodologies for nearly a decade, I’m very pleased that agile software development eventually has become accepted and embraced in mainstream Norwegian business. The marketing has done its job well; now we have to stop evangelizing and rather start working on the challenges.

Agile software development in its current form is a large step forwards, but it’s not the end of the journey. We have to keep improving, based on feedback.

That is the agile core in all its beautiful simplicity.