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!
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 | 4 Comments »