A Response to Mike Cohns Comments on 64% of Software Features Rarely or Never Used


I have a saying.  “Scrum Trainers usually agree on 99% of Scrum, but they spend a lot of time debating the other 1%.”

Let me say this first.  I’m a huge fan of Mike Cohn.  I teach Scrum and Agile classes all over the country at Fortune 50 companies, and it is very rare for a class to go by that I won’t mention at least one of his awesome books on Scrum.  I also recommend him on my list of favorite Agile resources on one of our web sites.  In addition to all of this, I’ve had numerous personal interactions with Mike one on one, and he’s always been extremely nice to me, traded professional practice opinions/advice, and he even offered to let me attend one of his classes at a “trainer courtesy” discount one time.  Great guy!  In summary, I like the guy a lot personally, and I highly respect him professionally.  He’s done a ton for the software and Agile industry, and no one should forget that.

So, with that said, let’s get back to that 1% debate. 🙂

In his recent blog post, Mike reveals some little known details about the oft cited 64% of features that are rarely or never used in software systems.  His information is factual and likely true.  I’m ok with all of that.

What I don’t understand is, why bother broadcasting this?

This is the most credible study available on the subject.  If you think hard about this data for a minute, you’ll realize why it is incredibly difficult to obtain… No company wants to admit that there is a TON of bloat in their software!  But, what percentage of Microsoft Excel/PowerPoint/Word features do you use and benefit from?  What percentage of Rally features do you actually use and benefit from?  Bloat bloat bloat, negative value, negative value, negative value.   In my recent articles on the New New Product Owner, I’ve talked about the need for the New New Product Owner to be a marketplace expert, so that they can maximize the value and profits from software development for their company.

Now, the value equation is way more complicated than “rarely or never used”, but still, I think we all know that there is a TON of negative ROI functionality in any non trivially sized application, and there is a TON of software teams with far too little focus on value and profits.  Anyone who has worked on the front lines of software development knows that.  The oft cited study just helps confirm some of our suspicions.  One of our Agile Metrics consulting services at AgileSoftwareTraining.com is helping to give company leaders even more transparency into how to extract more profits and cost savings out of all of their software development efforts, whether they be internal or external systems.  Give us a call if you’re interested.

What makes that limited study useful as a teaching tool is it gets people to think about value, and think about low value, low ROI features, and realize that value delivery is important, far too important to ignore.

There are other “studies” cited in our industry that are totally bogus, software leprechauns if you will, and I’m totally against relying on those.  Things like the “Cone of Uncertainty” and the so-called “Weinberg study” on task switching have shown to be totally made up.  However, the Standish Group study is real, with real data, and it is highly credible, even if somewhat limited in its scope.

So, Mike wants us to stop citing the study, or for us to caveat it with “in the weeds” details.  Of course, that will just confuse those new to Scrum and the teaching value would be lost.  And people would focus less on software value and profits.  I don’t think that’s good.  I’m totally open to hearing about a more credible public study, but I’m unaware of one. 

With all due respect to a friendly colleague, and one of the best Scrum trainers on the planet, I think ignoring or caveating the 64% study is bad for the industry.  Let’s just put this in the 1% bucket that we as Scrum trainers will agree to disagree on. 🙂

If you’d like to disagree with my contrarian view, feel free to sound off in the comments below!

4 Responses

  1. I agree that the study is still useful data. However, one of the challenges with the idea that rarely/never used is a bad thing in commercial software is that rarely used might still be high ROI, depending on who’s using it. I was teaching a class with the Photoshop team, and this study came up in a discussion. The Product Manager said something like “No one uses most of the features in Photoshop, but Photoshop wouldn’t be the success it is without all of those features. Maybe only 100 people use some of the advanced stuff, but those 100 people influence the rest of the market.”

    No doubt there is opportunity to improve, even for a market gorilla like Photoshop, but rarely used might be still highly positive ROI depending on who rarely uses the feature. If it is a tiny slice of a target market who is highly influential, it is probably still worth it.

    Similarly, if you can sell a huge contract with a B2B product by adding a feature that only one company will use, and that sale will float your company for the next quarter or two, should we caution against building it?

    Anyway, it is a complex situation, and I don’t think any single rule will apply generally. It is certainly true in my experience that we end up building a ton of stuff that we probably shouldn’t.

    • Peter, I agree. The ROI picture is not as simple as “rarely or never used”, but I really think the 64% is an indicator that much of what is in our systems is waste. For that reason alone, I believe that this real life, real data study, is still very valuable, and should provoke thought around ROI, profits, and value.

  2. A couple points here that I’d like to add:

    First off, I should note that I’m not a programmer, I’m a trainer. I have provided training on content ranging from Photoshop to Lightroom, SaaS products, and most recently, have moved into the telecom world to ramp up and teach B2B classes on network hardware and software troubleshooting tools.

    I should also note that I came cross the blog post here, and the website as a whole, after meeting Mr. Bradley on a flight from Denver to Dallas recently. So, I may be biased toward his point of view as his is the only view I’ve seen articulated (especially since I am not a programmer myself…)

    All that said, I am familiar enough with programming conceptually, and have several friends who have helped me develop an understanding of programming at least at a superficial level.

    My contribution here is that the bloat we are seeing in software these days is ultimately the inclusion of that one feature that is “rarely or never used”. The simple fact is that features are included not because it’s rarely or never used but because SOMEONE uses it. This is where the SaaS world becomes an interesting one.

    If you don’t want a feature, or don’t need a feature, the fundamental principle of SaaS is that features can be controlled through back end configuration. While this may not apply to the Scrum world, and I may be talking out of turn here, I would submit that program development has a multitude of factors to consider, and inflicting bloat on 99% of a user base because 1% of the user base sees the need seems unfair.

    Speaking to Photoshop specifically…Adobe has seen fit (as have many software developers), to move to a subscription model for their software. That being the case, isn’t it time to explore not only subscription licensing, but subscription based features in the development world?

    • Great to meet you on the Plane Jason. All good points. In the traditional software world, we create “business feature toggles” to hide some functionality when the rest of the user base should not be subjected to it. We also use “smart defaults” and “feature configuration settings” to allow a customer to config only the features that they want to see. The real trick is figuring out which features have a positive ROI, and which features do NOT have an ROI, and should be removed from the code base.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: