Summary
In a recent series of conversations, Dan North, Martin Fowler, and Marc McNeill explore what is possibly the fifth Agile principle: valuing outcomes over features. They also discuss the differences between use-cases, user journeys, and features.
Whilst there is value in delivering a list of features, I value achieving the outcomes of the project higher.
North takes issue with the practice of eliciting use-cases, or user stories, at the outset of a project that then lead to the creation feature lists. Those feature lists, in turn, become the yardstick by which a project's success is judged, often losing sight of a bigger, more important, picture—the project's desired outcome:
An agile project ... should focus on a set of outcomes. How we get there is less important than actually getting there. A CIO or business sponsor wants to solve a specific problem, by a specific date, and has an idea of how much money they are prepared to spend achieving that.
By driving out a comprehensive list of stories, estimating them, and then rolling it all up into a Big Release Plan, you run the risk of focusing attention on the features (stories) and defining success as the delivery of all these stories. This is exacerbated when the release plan is shown to people who weren’t part of the original exercise. They see the release plan and naturally assume that it is the primary "output" of the process.
North's comments come on the heels of a missive by Marc McNeill on customer journeys, Ditch the feature shopping list. Think customer journeys. McNeill's contribution to the debate of meeting a project's true goals is to point out a subtle, but important, distinction between user stories, or use-cases, and what he calls "customer journeys:"
Rather than thinking about vertical functional silos, we should think about horizontal slices through the functionality. Slices that support customer journeys. We can start with simple journeys to start and build complexity as we prove our process and new platform, mitigating technical risk as we progress.
Frequent use-case in online applications, for instance, is "account creation." This traditionally describes a new user creating a user account by entering a user name, a password, and possibly some optional demographic data. A use case-based approach would try to enumerate all the issues, or features, of account creation and management, such as providing a way to retrieve lost passwords, reclaiming inactive user names, and so forth.
By contrast, a user journey would start with, say a user wanting to reply to a forum post, such as this one. Clicking on a reply button, the system would prompt the user to either log in or to provide the information required in order to enable that forum post. While the latter may well result in the creation of a new user account, the user is seldom interested in creating a new account per se, but is more keen on just finishing her "journey"—post her reply to the forum.
The difference is subtle but important, according to McNeill:
Because we are building around customer journeys, just enough to realise customer intentions that support those journeys[,] we build only what is required. We are not building by feature list. We don’t over promise and under-deliver. We are building trust with all stakeholders.
Surely this is the better way to build software, thinking about customer intentions and incrementally delivering to support more complex customer goals. Sadly, people all too often get fixated by feature lists. Because that is what they are used to. Because that is how products are sold. But isn’t there a marketing 2.0 where we sell experiences and go beyond the product?
In FeatureDevotion, Martin Fowler summarizes the weaknesses of both use cases and features. Fowler agrees with McNeill's assessment of the dangers of letting use-cases flow into features list, which then define project scope:
The feature list is a valuable tool, but it's a means not an end. What really matters is the overall outcome, which I think of as value to the customers... Feature lists have another problem—you easily lose sight of the context that makes the feature valuable...
Use cases ... concentrate on a narrative of how someone uses a system... The weakness of use cases in planning is that they don't give you clear units to tick off so you can assess progress and project consequences of choices into the future. That makes them less useful as a planning tool, but that doesn't negate their value as tool for imagining what a good outcome would be.
A benefit of preferring to focus on outcomes over features is that an outcome may be satisfied by cutting scope on features, according McNeill:
Does “cutting scope” really mean failing to meet objectives? Or were those features not really core after all? A project has to have a goal, otherwise you can’t know when you’re done. This causes you to define “done” in terms of execution of the story list. Similarly, it has to have a feature list, or you don’t know what you’re going to do to get there. So it is just as big a risk to have no clearly defined outcome (i.e., no vision or purpose for a project) as defining a fine-grained feature list up front.
Next time you engage on a new project, make sure the entire team—and especially the sponsor—has a clearly articulated outcome for the project. And make sure you regularly review your direction to ensure you are still working towards those outcomes.
How do you figure out what to implement in your software project? How do you figure
out how to divide that into iterations?
A project has to have a goal, otherwise you can’t know when you’re done.
I think that most of the time, on most projects, the concept of "done with the project" just doesn't make much sense. Software is worked on (at varying degrees of intensity, to be sure) until it's abandoned or replaced. In the case of software that ships, the equivalent concept is "until the final release".
Until that moment comes, there is always a backlog of items to work on, and a process needs to be in place to work on that backlog. That being so, favoring outcomes over features really means "favoring features you find out about early over features you find out about later." It's arbitrary.
> ...principles of agile development:... > >Customer collaboration over contract negotiation > >While there is value in the items on the right, we value the items on the left more. >: >: > Next time you engage on a new project, make sure the > entire team—and especially the sponsor—has a clearly > articulated outcome for the project. And make sure you > regularly review your direction to ensure you are still > working towards those outcomes.
That sounds to me like you need a contract with the customer and you need to ensure that you are sticking to it.
One of the troubles with agile talk is the unsubtle use of language to make existing systems look bad and 'agile' systems look different, e.g. contracts need to be "negotiated" (sounds negative - bad) but we should "collaborate" with customers (sounds positive - good). Why not "collaborate" with the customer in drawing up a contract? Don't we ever "negotiate" with the customers over which features can be dropped? In fact, aren't they just two ways of saying the same thing? I can't see what new is being brought to the table.
> A project has to have a goal, otherwise you can’t > know when you’re done. > > I think that most of the time, on most projects, the > concept of "done with the project" just doesn't make much > sense. Software is worked on (at varying degrees of > intensity, to be sure) until it's abandoned or replaced. > In the case of software that ships, the equivalent > t concept is "until the final release".
I'm pretty sure that in this context 'done' means a single release.
> Until that moment comes, there is always a backlog > of items to work on, and a process needs to be in place to > work on that backlog. That being so, favoring outcomes > over features really means "favoring features you find out > about early over features you find out about later." It's > arbitrary.
And this actually bolsters the case for what is being proposed here. There will always be more time to add any number of features. If I have to choose between delivering a piece of shit with tons of features and a solid piece of software with a (possibly much) reduced feature set, I'll choose the latter. As you say, the software will definitely be modified it's much easier to build on a solid foundation of well made code.
Does “cutting scope” really mean failing to meet objectives? Or were those features not really core after all? Why wouldn't we know which features are really core? It seems like we're talking about wish-lists rather than requirements. It seems like the wish-list isn't prioritised.
Let's look at one of Dan North's anecdotes: "On one project it became apparent that we were unlikely to meet a particular hard deadline given the current story backlog. The team worked with the client to find a way that they could still meet the project’s outcomes and deadline, by dropping or deferring around a third of the features. The client was delighted!"
Huh? Why were we ever working on "features" which were less important to the Customer than other "features"? What's agile about that?
How do you figure out what to implement in your software project? How do you figure out how to divide that into iterations? If we're walking the agile talk it seems like the answers should be straightforward - Ask the Customer & Ask the Customer.
Is this stuff for real? I've never had my BS detector go off so often. If you want better results in software development, there are two things that'll really make life easier.
1. Language barrier. When a client or manager asks how long, make sure you understand what they mean. Usually, they mean when the product can be used in production. Many programmers consider "done" as when they're done typing. Even if it goes to other people for testing and bug fixing and the programmer's done in his role, both the programmer and client need to be "on the same page".
2. Changes. You need to set up front rules for changes. Too many clients don't understand that small changes are the ones that take the longest and will likely be insulted if you charge them. It doesn't mean you don't do these changes or are rude. It means that small changes should be bundled together with a system in place that is agreeable to both the programmer and the client or manager BEFORE the project starts. Yes, managers often don't have any system in place in small shops.
There are more, but these two are the real killers. The rest just comes down to your work habits.
Oh, this is a small 3:
3. Friggin'! If you start friggin' with stuff, you're doing it wrong. Don't waste time with getting stuff to work because of small details. Put your pride aside and get someone who's done it before.
Expanding on "individuals and interactions over processes and tools" of the agile manifesto and its effect on valuing outcomes over features:
Flexibility of switching roles to contribute to outcomes during development is important. What I mean by this is that the involvement in outcome development around customer journeys should be such that the outcome is evolved with the seamless participation of the team members (similar to extreme programming concepts).
There is no individual during the process - focus is only on the outcome. And the team could comprise of customer and development representatives.
Previous Topic
