Big Agile: Enterprise Savior or Oxymoron?

[article]
Summary:

Lawrence Putnam explains whether or not big agile is an enterprise savior or an oxymoron. What if agile only works when teams and projects stay relatively small? That’s the question most CIOs want answered before investing scarce time, energy, or resources chasing the big agile paradigm.

Something strange is happening in enterprise software development—eager CIOs are launching “agile” projects with teams of thirty people or more devoted to a single product release. And why not? We know agile works well for small teams and small projects, and monster enterprise projects (like rolling out a new SAP financial solution to replace all your legacy systems worldwide) often require greater capabilities than a small team can provide. So why not scale up agile teams to maintain the cost and efficiency benefits of the agile process while accessing the necessary manpower to pursue complex global projects?

If it works, we’ll be enterprise heroes—ready to have our portraits enshrined in the corporate IT hall of fame. But what if agile only works when teams and projects stay relatively small? That’s the question most CIOs want answered before investing scarce time, energy, or resources chasing the “big agile” paradigm.

To get that answer, we turned to the only source we truly trust—cold, hard data from the QSM software projects database.

The Ground Rules
To find out whether agile delivers the same benefits when applied to larger endeavors, we analyzed roughly three hundred recently completed IT projects, half of which reported using agile methods and half of which did not.

Agile projects in the QSM database are those that were reported as such by the teams that developed and delivered them. The results of the study may be influenced by variability in how agile methods were applied, but that seems only fitting for a methodology that espouses the freedom to “adapt as you adopt.” We are actively collecting more agile projects. However, at this point, the sample size is still relatively small—approximately one hundred fifty agile projects. We’ll be interested to see how our initial observations hold up over time.

To measure the relative size of software projects, we looked at the number of source lines of code delivered when the system was put into production. Though agile projects frequently estimate using story points, ideal hours, or counts of stories instead of code, we can empirically determine the average code volume per story point from completed project data by dividing the delivered code by the number of story points. This works well for our purposes because we need a “ruler” for measuring the volume of work to be performed that’s independent of how the project is staffed.

In addition, we looked at time, effort, activity overlap, and productivity data for two high-level phases of each software project:

  • The story writing, or requirements and design phase, encompasses requirements setting and high-level design and architecture. This includes the work in agile projects that is sometimes referred to as “getting to ready” and grooming the backlog.
  • The code, test, and deliver phase includes low-level design, coding, unit testing, integration, and system testing that leads to deployment.

In the traditional waterfall method of development, a large proportion of the requirements and design work precedes coding, testing, and release packaging. Overlap between the two phases is minimal. Conversely, agile’s iterative design cycles and just-in-time story detailing typically result in a great deal more overlap.

Hence, we were curious to study the proportion of time spent on requirements and design relative to the time spent on coding, testing, and packaging for delivery. In other words, how does time and effort spent on design work and story writing affect productivity? 

Is Big Agile Effective or Not?
Enough process talk. Do agile methods translate well to large-scale software projects? You didn’t really expect a simple yes or no answer, did you?

Any measure of effectiveness must first define what “success” looks like. Software effectiveness measures typically include one or more of these high-level management goals:

  • Cost efficiency
  • Schedule efficiency
  • High productivity

An organization’s definition of project success should align with its top priorities. Hence, organizations with significant cost and resource constraints should focus on completing projects inexpensively. Others may prioritize time-to-market or optimal productivity (finding the right balance between resources, schedule, and quality).

Let’s examine each of these goals individually.

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