In my executive presentations I spend a fair amount of time on the topic of Do Less, talking about how we waste an incredible amount of time and money building features that are rarely or never used. Published studies put this number at far greater than 50%. I see audience members agreeing, but I can also see the little thought bubble floating slightly above their heads, “but not in MY organization.” Organizations worry about improving development productivity by 10% when what they should be worried about is improving customer demand effectiveness by 25%. I’ve always said that one of the biggest potential productivity improvements from Agile lies in all the features that we don’t do because of the constant attention to simplicity and highest value to the customer.

However, in most organizations, software development efficiencies are subjected to infinite analysis while customer demand effectiveness isn’t mentioned at all. We neither measure nor calculate feature value in the beginning nor do we measure whether or not value was actually captured as the customer or product manager had predicted. In many large companies project ROI might be calculated as part of the portfolio management process, but rarely does anyone follow up to see if that ROI was in fact attained. So development teams have feedback mechanisms while customer/product teams have few except possibly at a macro level (product sales for example). Product managers are left with gut feel for most of their feature-level decisions. No wonder 50%+ of developed features are rarely or never used. Product management teams aren’t the culprit here however, lack of adequate feedback mechanisms are.

If we look at a typical Agile project team, there is the development sub-team and the product/customer sub-team. Roles, responsibilities and feedback mechanisms have been defined, so for example, the product team identifies stories, writes stories, prioritizes them, and develops acceptance criteria (both automated acceptance tests and feature showcase evaluations). So there are micro-level (feature and story) feedback mechanisms to steer the development effort. But what about feedback from product management to the business? These are often much more tenuous, such as overall sales that tell how a product is doing at a macro level, but say nothing about individual features. Internal IT products have even less feedback in most cases. Lack of feedback leads to feature bloat since it’s always easy to succumb to customer requests and internal demands to improve the product.

At the Agile Brazil 2011 conference I was listening to Josh Keriesvky’s talk on his Lean Startup experience, and gravitated to thinking about this problem. Here’s a starter list of ideas about potential solutions:

  • Develop Customer Demand Effectiveness measures for every product management organization and team.
  • Calculate relative or monetary value for every feature.
  • Use relative benefit dials such as increasing customer happiness, reducing customer risk, improving our internal collaboration culture, to evaluate feature value.
  • Build feature usage information into software to provide feedback to product management. Product manages could thereby gain insight into what was actually used and what wasn’t.
  • Develop feature evaluation experiments into your feature identification and prioritization process. For example do A/B testing on features.
  • False feature analysis. Give users access to a feature, that when selected pops up a message something like “this feature is under development. When completed are you ‘very likely’, ‘somewhat likely,’ or ‘not likely,’ to use it. Josh talked about an expensive feature that his company decided not to implement because of the results from this type of test.
  • Use short, focused surveys to take a measure of customer happiness. For example, “What was your experience using capability Y (capability being several features)? Awesome, OK, Not so Hot.

While there has been a lot alluded to in the Agile and Lean communities about value-based development, the actual practices to support this objective are not yet sufficient. There aren’t sufficient feedback mechanisms at the feature level to help mitigate the constant push towards feature bloat. Maybe taking a look at some of the ideas from Lean Startup and other sources can help.

These are some of my preliminary ideas. What are your ideas about this issue?

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn

Leave a Reply

Your email address will not be published. Required fields are marked *

Recent Posts

In The Zone with Marcin Zasepa

Welcome to the second in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Marcin Zasepa, CTO at Homegate AG in Switzerland. Every episode will be approximately 30 minutes

Read More »

In The Zone with Sasha Bilton

Welcome to the first in our new series, ‘in the zone’, a collection of conversations with CTO’s within the CTO Zone community. Each week we’ll be discussing the latest trends, insights gained from there experiences, and future predictions for their industry. This week we’d like to welcome Sasha Bilton. Every episode will be approximately 30 minutes long, and we aim

Read More »

Case Study: DAZN Data Engineering

Find out how 101 Ways helped DAZN improve their existing data warehouse as well as planning and setting the foundations of the new cloud-based data platform. Click here to download the full case study. Get in touch with a member of the 101 Ways team if you would like to discuss ways in which we can help you and your company

Read More »

Search the Blog

Agile Management Made Easy!

All About Agile

By Kelly Waters

“’Agile’ is one of the biggest buzzwords of the last decade. Agile methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. Allaboutagile.com is one of the most popular blogs about agile on the web. ”

Kelly Waters

Agile 101 is available to purchase. GAME ON!

Agile 101

Emma Hopkinson-Spark

“Whilst there are lots of ways you can vary the game depending on the teams you have and the learning outcomes you want, the basic flow of the game play is common to all.”
Emma Hopkinson-Spark

Why did we make the game?

How to play the game?

London

101 Ways Limited
41 Corsham Street
London
N1 6DR
United Kingdom

Manchester

101 Ways Limited
No.1 Spinningfields
Quay Street
Manchester
M3 3JE
United Kingdom

Amsterdam

101 Ways BV
Weesperstraat 61-105
1018 VN Amsterdam
Netherlands

Contact Us

If you would like to get in touch with one of the team at 101 Ways, then please fill out the form below or email us at contact-us@101ways.com.