This title of a 2013 keynote presentation by Gojko Adjic, author of “Specification by Example” and “Impact Mapping,” obviously doesn’t mean you should stop building software, but it does speak to a fundamental misunderstanding about Agile software development. Many organizations turn to Agile in a quest to create more software faster, which makes sense if you consider that in many cases the main reason for starting the difficult road to Agile Transformation is that “it takes forever to get anything delivered around here.” However, while reduced time to delivery should certainly be one of the results of Agile (“good Agile,” that is), “more and faster” is usually still not enough to reach the finish line. After all, as Jeff Patton puts it: “There’s always more to build than you have people, time, or money for. Always.”
Wait, what now? As Agilists, we’re supposed to focus on outputting working software – the more the better, right?
Let’s take a step back for a moment and take a different perspective – what exactly is the value of a software feature per se? To use that most dreaded, yet often most accurate answer – it very much depends! In the software community, we have long talked about how 50% or more of software features are rarely if ever used (even though the most commonly used source for this assertion is not necessarily as solid as we would like it to be). What, then, is the value of those features? Zero? Considering that feature bloat makes software complexity go up more than proportionally and extraneous features eventually make an application more difficult to use, run, maintain, and extend – is the value of some features actually negative, even if they get used occasionally?
Perhaps what matters more is what users do with the feature – the outcome of making the feature available, as expressed by the resulting change in behavior. Do users make fewer errors in our financial planning application, now that we have added data entry validation? Do customers check out more frequently, now that we have overhauled our shopping cart?
Yet again, though – is that what really matters? It depends on what you are trying to achieve. If your company offers free shipping and sells mainly low margin items, then it would probably be much better if customers added more or higher-margin items to the cart before checking out. On the other hand, if your business model is all about market share and profit is a secondary consideration, then getting customers to order more easily and frequently is a big win. So what really matters is the impact of your new feature on the organization’s goals!
From Cost to ROI
Focusing on value instead of how many features have been built allows you to change your understanding of a project’s status (and eventual success) from tracking scope to evaluating whether enough value and impact on your project goals has been achieved. If so, you can refocus further investment towards the next goal rather than blindly following a plan that no longer produces significant ROI. Of course, this works much better if the project goals are not only clearly identified up front, but also clarified by measurable success criteria.
So how could it be possible for a project to achieve the desired impact before the entire scope is completed? Well, assuming that the goal is not to achieve perfection (which is the safest way to ensure you’ll never be successful – just ask your local Zen practitioner), it is helpful to keep in mind the Pareto principle, aka the 80/20 rule, which in this context means that 80% of your value comes from only 20% of the features (or some similarly weighted distribution). This is why for Agile projects the value curve looks like this:
In many cases, reaching 80% of a (projected) target is good enough, especially if we got there relatively quickly and cost effectively. If not, throw in another 30% of features or so and most of the time you’ll have achieved around 90% of the application’s theoretically possible value. If that is enough to reach your stated goal – in terms of increased revenue, reduced cost, improved speed, you name it – you have 50% (or more) of your budgeted resources left to invest in the next most important goal!
Finding the High-Value Features
Ok, great – but how do we know which features are the most valuable? The answer to this one is likely a mix of user research and experimentation supporting a Lean Discovery process. However, it does help a lot to keep in mind that not all features have the same value characteristics.
What do we mean by that?
Martin Fowler suggested a few years back that investment decisions for IT projects should consider whether the product is considered strategic or utility. Strategic applications are what sets you apart from your competitors and serve as the kind of differentiators that drive market success. In that case, cost is less important than speed to market and agility in responding to market changes. On the other hand, for the vast majority of endeavors that fall into the utility category, quality and cost are crucial, so these projects need to be managed to different metrics altogether.
What product managers have known for a long time, though, is that this distinction can and should be made even within a single product or project – at the level of individual features. The Kano model, for example, has been around since the 1980’s and specifies a distinction between features that excite, contribute to performance, fulfill basic expectations or even detract from customer perception of a product. The ROI of adding or improving a specific feature will vary widely, depending on which of the Kano categories it falls into, so different feature types need to be prioritized and managed differently.
Agile indeed helps you create working software faster. But understanding the goals your application or release is supposed to achieve and the value that specific features contribute towards reaching those goals is what enables you to use your newfound agility to reap the true benefits of Agile by creating more impact with less software.
Interested in learning more? Come hear Mathias Eifert speak on “Don’t Assume You’re Creating Value… Prove It!” at AgileDC on October 24!