The 90% problem of Agile

This article in Bank Systems & Technology states that Capital One is now using Agile methods for 85% of software development projects.  The indications seem to be that it has been quite successful for them, as the article states:

 

When Capital One started to roll out agile development in 2011, Wolfs said it amounted to just 1% of software that was delivered. Today, 85% of software is delivered by the agile method. With agile, Capital One now also releases approximately 400 products a month, has cut delivery times to three to six months while "cutting costs significantly," and finds 95% of products meet expectations on the first release, according to Wolfs.

 

This is all good, but one thing these kinds of articles do not talk about is what to do when a newly implemented method or process like Agile becomes routine and the initial gains taper off.  I witnessed a similar phenomenon at a prior employer where there was an initially high performance increase and waste reduction after implementing Six Sigma and Lean, but once they started to taper off, it became harder and harder to maintain those gains.

 

At one point, people were spending more time trying to optimize processes that were already optimized as much as they should be where the gains were hitting the point of diminishing returns.  I call this the “90% problem” since once you hit that milestone to where ninety percent or more of a method or process becomes the de facto standard in any organization, the costs to get the remaining 10% outweigh the profit of trying to achieve it.  But because people are so close, they spend way more time than is necessary trying to achieve 100% which is impossible.

 

This is where it becomes more of a liability and when people or organizations start giving up looking for a “new solution”.  It’s an ever recurring cycle.  My feeling is that Agile itself has hit this productivity wall.  Now the question is what is the “next new thing”?