Large Scale Agile and Scrum vs. Waterfall: Agile is 6X More Successful, 1/4 the Cost, and 10X Faster Payback!

A pair of recent findings from the Standish Group confirm the astonishing success and cost savings of Agile approaches over waterfall.

In the “Chaos Report 2015“, Standish found that large Agile projects are 6X more successful than waterfall projects.  While Standish doesn’t get specific on what is a “large” project, it’s worth noting that “Large” is the biggest size category for projects and their data encompasses over 10,000 software projects.

In a new report called  The Money Pit, The Standish Group studied two very similar large software projects, done at two very similarly sized, mature companies.  One project was done with Agile, and one with Waterfall.  The astounding results they found:

• The Agile project was 4X cheaper than the cost of the equivalent waterfall project, AND
• The Agile project was “delivered with high user satisfaction,” while the waterfall project “had a watered-down critical function and the high-value feature was not part of the delivered application.”, AND
• The Agile Project’s payback was “At the end of two years the application costs were fully paid back and the users were highly proficient” while the waterfall organization estimated the system payback would “break even in 20 years”

 

* Note that the activities depicted on the graph were done sequentially via waterfall, but iteratively via Agile.

It should also be noted that a survey from Forrester Research showed that of all companies attempting Agile, some 90% are using Scrum.

Just to re-iterate — 6X more successful, cost payback 10X faster, and 4X cheaper.  How is that for Better, Faster, Cheaper?

At AgileSoftwareTraining.com, we provide coaching, consulting, and training solutions to help your company achieve the astounding success of Agile and Scrum approaches.  Contact us today for a free consultation.

So, if you’re an organization that is doing waterfall or struggling with Agile, what are you waiting for?  The research is overwhelmingly in favor of Agile and Scrum approaches.  Get on the road to millions more in profit and cost savings.  No seriously, what are you waiting for?

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 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!

User Stories – Focusing on Conversations instead of Writing – Gojko Adzic’s New User Story Book

In my recent article on telling user stories instead of writing user stories, I mentioned that many Scrum Teams focus way too much on documentation and way too little on good collaborations.

More support for this concept comes from the first chapter in Gojko Adzic’s new User Story book, Fifty Quick Ideas to Improve your User Stories.

User stories imply a completely different model: requirements by collaboration. Hand-overs are replaced by frequent involvement and discussions…. If requirements are just written down and handed over, this discussion does not happen. Even when such documents are called stories, by the time a team receives them, all the important decisions have already been made…. Try telling stories instead of writing down details. Use physical story cards, electronic ticketing systems and backlog management tools just as reminders for conversations…Engage business stakeholders and delivery team members in a discussion, look at a story from different perspectives and explore options. That’s the way to unlock the real benefits of working with user stories.

Gojko has been nice enough to publish the “Tell stories, don’t write them” chapter available completely free here!  It is also important to note, that this chapter is tip #1 in his book, as it really sets the stage for the best use of the User Story practice.

The User Story practice was always intended as a very close, verbal collaboration between the Dev Team and the PO/Customer. In modern times, you can achieve this very easily with good Product Backlog Refinement practices.

Anyway, it’s totally worth another five minutes of your time to read Gojko’s free chapter, and be sure to share it with your teams and organizations too!

To maximize your Scrum and User Stories practice, bring us into your company to deliver coaching or our User Stories Class.

Terminology: Definition of Done vs. Acceptance Criteria

I’ve seen many folks imply that

• The Definition of Done(DoD) is defined per story(or per Product Baklog Item(PBI), if you will)

or said another way:

• The Definition of Done is different for each story.

I don’t agree with this.

There is a subtle but important difference between the Definition of Done and Acceptance Criteria.  It is summarized as follows:

Definition of Done:

• The term applies more to the product increment as a whole
• In most cases, the term implies that the product increment is shippable
• The term is defined in the Scrum Guide
• Used as a way to communicate the following to the PO
  • Overall Software Quality
  • Whether the increment is shippable or not

Acceptance Criteria
(aka Acceptance Tests, Conditions of Satisfaction, in some cases “Test Cases,” etc)

• The term applies to an individual PBI/Story
• The Acceptance Criteria are different for each PBI/Story
• Term is not defined in the Scrum Guide
• Used as a way to communicate to all involved that the requirements for a particular PBI/story have been met

If you wanted to, I guess you could say that part of the Definition of Done for any Sprint is that each PBI/Story in the product increment meets that PBI’s specific acceptance criteria.

However, I don’t know if you could definitely say that the converse is also always true:  “Each PBI must also meet the Definition of Done.”  For instance, one could decide that these things be part of the Definition of Done, but not be part of the acceptance criteria for each individual PBI:

• Performance Testing on the integrated product increment
• Exploratory testing on the integrated product increment in a test environment
• Exploratory testing in a Staging/Pre-production environment

My concern is with people using “Done” and “Definition of Done” like terminology to describe when a Story meets its acceptance criteria, or that somehow the DoD is different for every Story.  The DoD needs to be broadly applied to the increment as a whole, and should stay relatively constant.  Of course, as teams update their DoD(hopefully improving it!), things will change, but it shouldn’t be different for each Story.  Also, when the DoD changes, it is imperative that it be well communicated to all on the Scrum Team, and especially the PO.

If you want a term to describe when a Story meets its acceptance criteria, maybe “complete” or “accepted” are better terms than “done.”