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 one of the most credible studies 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.
Newer Study confirms the same idea!
Further, Standish again re-iterated this point in 2014, ostensibly from wider data: https://www.standishgroup.com/sample_research_files/Exceeding%20Value_Layout.pdf — “Standish Group research shows that 80% of features and functions have low to no value.”
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!
Filed under: Agile, Bad Smells, Organizational Change, Scrum, Scrum Adoption, ScrumMaster Tips, User Stories | Tagged: Agile, Scrum, Scrum Master, Scrum Trainers, software development, user stories |
The Scrum Crazy Blog 
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.
Also I just added this bit to the article:
Further, Standish again re-iterated this point in 2014, ostensibly from wider data: https://www.standishgroup.com/sample_research_files/Exceeding%20Value_Layout.pdf — “Standish Group research shows that 80% of features and functions have low to no value.”
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.
Thank you for raising this issue. Just to be clear, Mike was saying that you shouldn’t overuse the data. He didn’t say don’t use it at all. So I think he makes a fair point. I see a lot of snakeoil out there trying to make some strong correlation between the industry and that internal study.
“We are more likely to build the right software using an Agile approach” is a fair point but the data to back it up is not this study. This study says to me this company could benefit from being more “Agile”, not that everyone will. It is a good case study of the value of Agile but it is not a stand-in for an entire industry.
What’s ironic to me is that Scrum specifically is driven by good metrics and analysis, yet so many seem to be prepared to jump on using this chart because it “feels right” instead of doing the heavy lifting of actually researching before making the claims.
So I’m glad Mike raised the alarm before I went and did something stupid with that chart because I want every piece of ammunition I can find to make the case for what I know works from personal experiences.
However I don’t ever want to claim something that isn’t backed up by inscrutable facts. I’ll use the diagram for what it is, an example of what COULD happen but I won’t extrapolate or recommend trusting anyone who does that.
Scott,
Fair points, but I do return to the idea that there is no better data out there. Wrt Mike’s point about “overusing” the data — when Mike Cohn discourages something, he might as well be saying “don’t use it” due to his status in the industry. This is another reason why I think he went wrong here.
[…] None of the Chaos Report numbers take into account all the stupid, useless, rarely used, and unused features in successful projects. (I’m looking at you, Clippy.) But seriously, look through the menus in Microsoft Word or Excel. Do you even know what half of those things do? I don’t. Can you imagine being the Microsoft developer who maintains the kerning feature in Word? It’s hard to get a good handle on the number of features that fall into this category but I feel confident saying that it is well above 25%. […]
I’m so torn on this one. Not only do we develop code that is rarely/never used, but it’s often the code that takes the most time to design/develop. Hard numbers like 64% are great, but not if they are wrong. Bottom line, I wish there were better numbers, but in the meantime, the concept holds. We just have to find a better way to communicate it.
A 2014 article showed a low number of bugs causing most the complaints.
https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm
A 2012 study showed 5 commands in Word being 32% of the features used.
https://answers.microsoft.com/en-us/office/forum/office_2010-office_install/what-is-the-percentage-of-features-of-word-excel/80e417ef-8336-49a5-9f5f-0a59c8c8fbd4
I hear ya, thx for the comments and the links.