Feature Folly

This content is syndicated from Jim Highsmith by Jim Highsmith. To view the original post in full, click here.

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?

Leave a Reply

What is 2 + 4 ?
Please leave these two fields as-is:
Please do this simple sum so I know you are human:)

There are 101 ways to approach anything.
To find the best way, sometimes you need expert help

What People Say

“Kelly revolutionised the way our digital department operated. A true advocate of agile principles, he quickly improved internal communication within our teams and our internal clients by aligning our business and creating a much enhanced sense of transparency in the decisions the business was making. Kelly also introduced a higher sense of empowerment to the development teams...”


“Kelly’s a leading program director with the ability to take charge from day one and keep strong momentum at both a program and project level driving prioritisation, resourcing and budgeting agendas. Kelly operates with an easy-going style and possesses a strong facilitation skill set. From my 5 months experience working with Kelly, I would recommend Kelly to program manage large scale, complex, cross company change programs both from a business and IT perspective.”


“Kelly is an extremely talented and visionary leader. As such he manages to inspire all around him to achieve their best. He is passionate about agile and has a wealth of experience to bring to bear in this area. If you're 'lucky' he might even tell you all about his agile blog. Above all this, Kelly is great fun to work with. He is always relaxed and never gets stressed - and trust me, he had plenty of opportunity here! If you get the chance to work with Kelly, don't pass it up.”


“Kelly is an Agile heavy-weight. He came in to assess my multi-million $ Agile development program which wasn’t delivering the right throughput. He interviewed most of the team and made some key recommendations that, when implemented, showed immediate results. I couldn’t ask for more than that except he’s a really nice guy as well.”


“Kelly and I worked together on a very large project trying to secure a new Insurer client. Kelly had fantastic commercial awareness as well as his technical expertise. Without him I would never had secured this client so I owe a lot to him. He is also a really great guy!”


“Kelly came to the department and has really made a huge impact on how the department communicates, collaborates and generally gets things done. We were already developing in an agile way, but Kelly has brought us even more into alignment with agile and scrum best practices, being eager to share information and willing to work with us to change our processes rather than dictate how things must be done. He is highly knowledgable about agile development (as his active blog proves) but his blog won't show what a friendly and knowledgeable guy he is. I highly recommend Kelly to anyone looking for a CTO or a seminar on agile/scrum practices - you won't be disappointed!”


“Kelly was a great colleague to work with - highly competent, trustworthy and generally a nice bloke.”


“Kelly was engaged as a Program Director on a complex business and technology transformation program for Suncorp Commercial Insurance. Kelly drew on his key capabilities and depth of experience to bring together disparate parties in a harmonised way, ensuring the initiate and concept phases of the program were understood and well formulated. Excellent outcome in a very short time frame. ”


“I worked with Kelly on many projects at IPC and I was always impressed with his approach to all of them, always ensuring the most commercially viable route was taken. He is great at managing relationships and it was always a pleasure working with him.”


“I worked with Kelly whilst at Thoughtworks and found him to be a most inspiring individual, his common-sense approach coupled with a deep understanding of Agile and business makes him an invaluable asset to any organisation. I can't recommend Kelly enough.”


“Kelly was a brilliant CTO and a great support to me in the time we worked together. I owe Kelly a great deal in terms of direction and how to get things done under sometimes difficult circumstances. Thanks Kelly.”