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, 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?

The New New Product Owner: The Product Visionary

In my previous post, I discussed the New New Product Owner as The Product Marketplace expert.  In this post, we explore the “Product Visionary” focus area.

The Product Owner is the chief product visionary. The PO should be able to clearly articulate the product vision to the Scrum Team and key stakeholders, and how that vision aims to maximize the value of the product and of the work the Scrum Team performs.
POFocusAreas_NewNewPOThe PO should communicate and re-iterate this vision early and often, reminding all involved of how to help maximize value.

For a high quality class that focuses exclusively on the Product Owner role(the course is also great for key stakeholders!), see our Professional Scrum Product Owner class and contact us if you’re interested in one.

Utilizing the underlying empirical product planning features of Scrum, the PO should also be ready to make strategic pivots for the product vision whenever there are significant changes in how value can or likely be captured. This vision is brought to life in a more tactical way, via the Product Backlog and iterating towards that vision every Sprint.

In my next post, we’ll discuss the New New Product Owner as the Release Decision Maker.

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

Scaling Agile and Scrum to multiple teams: Great Overview of LeSS and Large Scale Scrum

If you’re like many companies out there, you’re trying to figure out a way to effectively get multiple Agile teams to work together to deliver more with less.  Well… Let me introduce you to LeSS — Large Scale Scrum.  Large Scale Scrum has been in practice since 2005.  The co-creators of LeSS, Certified Scrum Trainers in their own right, have just released a kick arse chapter from their new book on LeSS.  Their chapter, in my opinion, is the best introduction to LeSS for those who are not familiar with it.  I highly recommend you give it a read!

If you’re interested in learning more about Large Scale Scrum (LeSS), check out the LeSS class being held in Denver in late September. (Includes certification, SEU’s, etc)

Here is the link for the chapter introducing LeSS:

The New New Scrum Master: Two Main Focus Areas

I’m going to take a break from talking about the New New Product Owner to talk about the New New Scrum Master now.

Preface:  In the last 4 years, the Scrum Guide has had two very significant updates, including updates to the Scrum Master Role. In this article and the series that follows, I attempt to describe “The New New Scrum Master” role in Scrum.

The Scrum Master role has not changed as much in recent Scrum Guide updates as much as the Product Owner.  In many ways, however, what has changed, is the number and higher frequency of misconceptions about the Scrum Master role.  This is, in my opinion, due to late adopters to Scrum who don’t take the time or money to attend proper and professional Scrum training.  Yes, this appears to be a completely self serving statement since I’m a Scrum Trainer.  However, the bigger, and more important reason this statement is true, is because Scrum is a much deeper topic than people think.  We often use the metaphor of the difference between a Chess player who knows how the different chess pieces move, and a Chess player that has extensive experience and knowledge about how to be excellent at the strategy and techniques of Chess.  There is a vast difference between those two ends of the spectrum, between knowing the rules and being able to excel at winning.  With Scrum, people and organizations vastly underestimate just how long that spectrum is.  All you have to do to confirm this is to witness or hear about a Scrum adoption that is horribly painful or not working.    So, my hope is that we can clear up some misconceptions for the New New Scrum Master and help reduce some pain and increase some profits!

The two main focus areas for the New New Scrum Master are:

  • Teaching and coaching the organization on how to achieve the benefits of Scrum, and
  • Removing impediments that are beyond the reach of the Development Team.

For brevity’s sake, we will shorten these to “teach/coach” and “remove impediments.”

All of the other Scrum Master focus and duties derive from the above two focus areas.

For a high quality class that focuses exclusively on the Scrum Master role(the course is also great for management), see our Professional Scrum Master class and contact us if you’re interested in one.


One of the main focus areas for the New New Scrum Master is teaching and coaching the organization on how to achieve the benefits of Scrum.  Let’s talk about how this might be done.

The New New Scrum Master knows the “Why’s” behind Scrum.
In my experience, Scrum Masters would do well to understand the benefits of Scrum on several levels, before worrying about specific teaching or coaching techniques.

First and probably foremost, the Scrum Master should understand and *be able to succinctly communicate* the *business* benefits of Scrum to the organization. It is important to to be able to communicate these benefits succinctly because, in the wider organization, the Scrum Master will very often be given 5 minutes or less to convey them.

Each Scrum Master should have their own such list of benefits memorized, but certainly some of them should be:

  • Faster time to market
  • Quicker ability to pivot to market opportunities and competitor threats.
  • Higher Customer Satisfaction
  • Higher Productivity
  • Higher Transparency
  • Better Predictability
  • Better alignment between the business and software teams
  • And the list goes on…

A good study of the 11 key metrics in “Evidence Based Management” will help you to be aware of some of the business benefits, but come up with some of your own.  Make it yours!

Being able to rattle a good handful of these off, and then being able to *explain succinctly* how different sub parts of Scrum support these goals should certainly be in the New New Scrum Master’s toolbox.  When facing an organization that has not been to proper Scrum Training, be sure not to use too much Scrum speak — keep it very simple and mostly devoid of Scrum terminology.  Also, definitely focus on the business benefits of Scrum that align with organizational desires and goals.  The more you can point to those higher organizational desires the more buy-in you’ll likely get from those higher in the organization!

The New New Scrum Master should also be able to communicate the benefits that will appeal more to those on and around the team, such as:

  • Benefits to Development Team members
  • Benefits to Business Stakeholders
  • Benefits to Product Owners

Again, the same advice as above, be ready to rattle off a list, be ready to explain how different parts of Scrum support each of the list items, and be ready to avoid Scrum terminology for those who haven’t had proper training.

Knowing the “Why’s” behind Scrum will help convince others of “why” to pay attention to your teaching and coaching.  Notice I said “help convince” — it will likely take much more than that, but knowing these benefits is a “must have” for those conversations.

Knowing the “Why’s” behind Scrum is just one aspect of “teach/coach.”  Don’t misunderstand me, teaching and coaching is actually more than just teaching and coaching — using those two terms is simply a way to oversimplify this focus area.  You might also want to mentor, advise, and facilitate at times.  But even those things can fall under “teach/coach.”  We’ll explore this more in future posts.

Removing Impediments

The second New New Scrum Master focus area is removing impediments that are beyond the reach of the Development Team.

There is a common misconception that the Scrum Master is responsible for removing *all* impediments for the Development Team.  While the Scrum Guide is a little vague on this subject, it is somewhat hard to articulate the fine balance between the Scrum Master’s duty to remove impediments, and the Development Team’s responsibility to self-organize. This misconception drives a lot of failure in Scrum implementations.  We’ll explore this more in future posts.

The metaphor I like to use here is “Give a man a fish and you feed him for a day; teach a man to fish and you feed him for a lifetime.”  When respecting and coaching on the Development Team’s obligation to self organize, it is important for the New New Scrum Master to realize when is the right to time to give the fish, and when is the right time to teach to fish.  The answer is usually the latter, but sometimes the former.

Remember:  Teach/Coach, and Remove Impediments

I have thought about this a lot, and have even conferred with my fellow Scrum coaches on this.  Pretty much all of the responsibilities of the New New Scrum Master boil down to the two focus areas of “teach/coach” and “remove impediments.”

In future articles, I will go deeper on each of these two focus areas.

In the meantime, do you think any Scrum Master duties cannot effectively fall under those two focus areas?  If so, what are they?  Sound off in the comments below!

The New New Product Owner: The Product Marketplace Expert

In my previous post, I discussed the 7 focus areas for the New New Product Owner, as well as the “Product Value Maximizer” focus area.  In this post, we explore the “Product Marketplace Expert” focus area.

The New New Product Owner should be expertly aware of the marketplace for the product. They should constantly be gathering and re-gathering information and data regarding the marketplace, so that the product value is maximized. Getting out of touch with the marketplace can be a recipe for product disaster. Note here that the New New Product Owner may or may not be the one doing the legwork of gathering the marketplace data(they might delegate), but they should certainly be aware of the market research.  Often times the New New Product Owner will delegate to others or to automation to aid them in obtaining the market data.
POFocusAreas_NewNewPONote that your market might be internal (IT software) or external (Saas, Consumer software).  Either way, it’s important to gather the marketplace data.

With IT software, the market data will often include how the LOB(Line of Business) uses the software, as well as understanding the business function that the LOB executes on.  Heavy interaction with those in the LOB will usually yield this data, or again, the New New Product Owner might delegate or rely on someone in the LOB to supply her with that data.  A good starting point for gathering this data is understanding who your key stakeholders are.

Additionally, the New New Product Owner should never be afraid to change the vision or tactics based on marketplace changes. Being able to strategically re-pivot and capture value in new and different ways is one of the key benefits of an Agile mindset.

For a high quality class that focuses exclusively on the Product Owner role(the course is also great for key stakeholders!), see our Professional Scrum Product Owner class and contact us if you’re interested in one.

The New New Product Owner communicates all of this marketplace knowledge to the Scrum Team through daily ad hoc interactions as well as Product Backlog Management, Product Backlog Refinement, and in Sprint Reviews.

Knowing the market for your product can help you fulfill another key focus area, being The Product Visionary.

The New New Product Owner: The Product Value Maximizer in Scrum.

Preface:  In the last 4 years, the Scrum Guide has had two very significant updates, including updates to the Product Owner role that have far reaching implications. In this article and the series that follows, I attempt to describe “The New New Product Owner” role in Scrum.

In a series of upcoming articles, I will detail the different focus areas that the modern Product Owner needs to concentrate on in order to fulfill their duties on a Scrum team.
POFocusAreas_NewNewPOThe New New Product Owner understands that she will likely need to execute these activities at different times, and that she might need to delegate to others in order to effectively produce software that maximizes ROI for the software development effort.

The first and most important focus area is for the Product Owner to be the “Product Value Maximizer.”  There are lots of way to do this, but 3 key steps are involved:

  1. Order the Product Backlog by (estimated) value.
  2. Work with the Development team to get small increments of value to market quickly, for feedback.  Release to market = in production, available to end users.
  3. Rapidly assess value delivery feedback from the market, and then start over again at step #1.

These three steps will ensure that the New New Product Owner delivers “the right thing.”

Note that your market might be internal (IT software) or external (Saas, Consumer software).  Either way, it’s important to get features into production quickly, and to assess whether we have “hit the target” with respect to value… or not.  This quick release to production, every few weeks, is a key aspect of Agile software development.

If you haven’t already signed up for our blog, be sure and sign up (upper left hand corner) so you will get the future articles on this topic!

In future articles, I will detail the remaining six focus areas for the New New Product Owner:

For a high quality class that focuses exclusively on the Product Owner role(send your business stakeholders too!), see our Professional Scrum Product Owner class and contact us if you’re interested in one.  We teach all over the USA.


Get every new post delivered to your Inbox.

Join 395 other followers

%d bloggers like this: