Big Agile: Enterprise Savior or Oxymoron?

[article]

Success Case #1: Cost Efficiency

1  

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

2

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

3 

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

3 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

About the author

Larry Putnam, Jr's picture Larry Putnam, Jr

Lawrence H Putnam, Jr is co-CEO of QSM, a leader in software process improvement and systems development estimation. Larry's primary area of responsibility is to oversee the strategic direction of QSM’s products business. This includes meeting revenue goals, strategic product direction, customer care and research. Larry has over 25 years of experience in software measurement, estimating and project control. He joined QSM in 1987 and has worked in every aspect of the business, including business development, customer support, professional services and now executive management.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!

Upcoming Events

Sep 22
Sep 24
Oct 12
Nov 09