Big Agile: Enterprise Savior or Oxymoron?


Success Case #1: Cost Efficiency


Figure 1. Cost Efficiency

To compare the cost efficiencies of numerous projects, we need to minimize the effects of varying labor rates. To that end, we viewed cost through the lens of effort hours expended (i.e., cost = effort * labor rate). Using this method, we can see that agile projects with fewer than thirty thousand source lines of code, or SLOC, are less costly than similarly sized nonagile projects. The trend seems to reverse itself in projects above the thirty thousand SLOC threshold, but in a subtle way.

The larger agile projects are fairly closely clustered; that is, for a particular size, there is not much variation in effort and cost. The larger nonagile projects, however, are either much less costly than their agile counterparts or quite a bit more costly. On average, large agile projects are a bit more costly, and this disparity seems to increase with size.

In fact, what seems most apparent in this analysis is that both agile and nonagile projects realize the greatest cost and resource efficiency benefits when packaging up delivered features into small releases with fewer than thirty thousand SLOC.

Bottom line: The agile cost advantage phases out at around thirty thousand SLOC. Above that threshold, agile projects may actually be more costly than traditional waterfall projects. If cost efficiency is your primary concern, both agile and nonagile projects should keep release sizes small.

Success Case #2: Schedule Efficiency


Figure 2. Schedule Efficiency

Our schedule analysis shows that time to market is consistently shorter for agile IT projects, but that agile schedule edge diminishes as the volume of delivered features increases.

Bottom line: If schedule is your primary concern, large agile projects are consistently more time-efficient than similarly sized nonagile projects, but the agile schedule advantage diminishes as project size grows.

Success Case #3: Balanced Productivity


Figure 3. Balanced Productivity

To evaluate balanced schedule and cost productivity, we looked at a metric called the productivity index, or PI, which—unlike traditional productivity measures that examine resource or schedule efficiency, but not both—takes both time and cost into account.

According to the data, larger agile projects enjoy a modest productivity edge over nonagile projects, but again, the effect is quite subtle.

User Comments

Paul Jarmul's picture

Sorry, equating lines of code produced to 'productivity' is not a good metric to use for any process improvement activity. We use Scrum on small and large projects to get early and frequent user feedback with the metric/goal of quickly maximizing customer value / increasing our Net Promoter Score (NPS).

March 27, 2014 - 11:32am
Ed Kelly's picture

Larry, Based on the effectiveness criteria layed out in the article, your conclusion is based on solid data and methods.  However, I would challange that you've missed the primary purpose of Agile, which is not one of your criteria.

Agile focuses on value delivered.  It doesn't matter much if you can deliver 30K or 100K SLOC in 1 month or a year, if what is delivered misses the market need.  A fantastic book by Donald Reinertsen explains, with much supporting data, the reason to focus on value above all other criteria.  I am convinced that market / consumer value is the primary measure effectiveness or success.

March 27, 2014 - 11:40am
Larry Putnam, Jr's picture

Ed, I agree that value is important and that would be something interesting to look at. The purpose of this particular article is to look at the impact on cost and productivity. Thank you for your comment.

April 3, 2014 - 1:42pm
Mary Poppendieck's picture


If CIO's want to survive, figuring out how to do large projects faster or more efficiently is hardly the thing to focus on. Ask the CIO of any financial enterprise and you will find that figuring out how to deliver real value in the face of fierce competition from startups is the essence of the job. These CIO's must fundamentally rethink how they keep their organizations relevant in an increasingly digital world. One of the first things to go is large projects. CIO's need to understand that the first step to successful scaling is learning how to do Continuous Delivery.

January 29, 2016 - 12:51pm

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.