Big Agile: Enterprise Savior or Oxymoron?


More interesting, perhaps, is what we see when plotting productivity against the proportion of time spent on design and story writing. Agile projects, it seems, become noticeably more productive as they spend a larger proportion of their time on requirements and design versus coding, testing, and packaging for delivery. This is consonant with findings in the agile community in general that taking extra time “getting to ready” and ensuring that user stories are well thought out and communicated is critical to the success of agile methods.

Bottom line: If process productivity is your primary consideration, large agile projects benefit from increased time spent on requirements setting and high-level design. 

Wait, That’s a Paradox, Isn’t It?
Not necessarily. It’s true that one of the hallmarks of the agile method is spending less time up front on requirements and design. But “less” is a relative term. Although the time spent on requirements is more spread out throughout the project with agile methods, our data show that spending more time pays off in higher overall productivity.

Smaller projects are a more natural fit for “pure” agile—after all, most small projects were using small teams and lighter processes even before agile revolutionized software development. What we see from our data, however, is that as larger teams apply agile methods to larger projects, they are wisely adapting those “pure” agile precepts to the needs of larger, more complex systems, resulting in a tempered version of agile.

What’s most remarkable about this productivity chart, however, is that for nonagile projects, spending additional time in the design phase does not appear to boost productivity at all.

Agile methods, it seems, help teams apply that additional time and effort more effectively—working smarter, not harder. 

Hence, big companies can benefit from constructing their software in an “agile-like,” iterative fashion with frequent reprioritization of features and functionality, as long as their requirements and design work is sufficiently robust. In fact, this is precisely what a growing number of industry experts such as Dean Leffingwell, Steve McConnell, and Scott Ambler are recommending.

Perhaps “big agile” is neither a savior nor an oxymoron; it’s simply a compromise using the best of new methods and tried-and-true techniques. After all, one of the agile tenets is allowing human judgment to trump rigid process guidelines. 

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.