Agile development surprises - growth modest, but large enterprises buy in

As a big advocate of agile development, I curb my enthusiasm with reality checks. Despite my distaste for "waterfall" management styles, agile is not the only way to a good project outcome. A new Computer Economics report, Agile Development Use Increases, but Barriers Remain, challenged my thinking about agile. (the full report is available for purchase a la carte or by subscription - but you can get a summary via the link above).

Backchannel chats with authors Frank Scavo, Tom Dunlap and Dave Wagner gave me insight into the surprising findings - such as large organizations doing agile at scale.

Report findings - large enterprises lead in agile adoption

The report themes:

1. Despite modest adoption levels, agile development methodologies have reached a maturation point, with the potential to deliver new systems faster while improving user satisfaction.
2. Agile continues to spread and win converts, as companies look for ways to continually shift and adapt.
3. Resistance to agile adoption is indicated by low practice levels in some industries and companies. Adoption can also be hindered by lack of formal training programs, and/or  agile proponents attempting to steamroll the business into agile with unrealistic claims.

The most surprising findings (to me):

• Large enterprises were most likely to adopt agile approaches.
• The assumption that agile is ideal for "edge" projects but not for large, mission-critical projects is no longer true.
• Agile's limitations for teams spread across disparate time zones - a criticism I've heard often from "scrum" practitioners - can potentially be addressed by different agile methods.

The report examines how widely agile development is being embraced, including slice-and-dice by industry and company size. It concludes with recommendations on the best uses of agile - and pitfalls to avoid.

Computer Economics defines agile development as an umbrella concept for software development methods that focus on "collaboration within tightly knit teams, iterative development, early delivery, continuous improvement, and the ability to respond rapidly to changing requirements."  The main agile branches include extreme programming, lean software, scrum, and crystal. Each has nuances spelled out in the report. Often they are combined in some fashion.

The report found agile adoption was highest in large companies:

From the Computer Economics report, Agile Development Use Increases, but Barriers Remain

For industry breakdowns, the leading agile adopters were:

• High tech - 74 percent
• Discrete manufacturing - 74 percent
• Banking and finance - 65 percent
• Retail - 63 percent

Agile adoption in large enterprises - what barriers remain?

I asked the Computer Economics team about agile adoption in large enterprises. They told me it wasn't just a case of nibbling on edge projects:

We did not specifically ask about the size projects where respondents were applying Agile, but it is obvious that any new approach will first gain a foothold in smaller projects. On the other hand, Agile has been and is being used in many large scale government software development contracts.

In fact, as we point out, the U.S. Department of Defense mandates today that all software development contracts be delivered with some sort of iterative development methodology. So, Agile does not need to be limited to small projects. But if applied to larger, more mission-critical projects, it needs a lot more formalization, training, and experience than many small IT organizations have today

Scavo, President of Computer Economics, acknowledged that big ERP and/or packaged software projects are less amenable to agile - but even that is changing:

Most ERP implementations are fundamentally different than projects where you are developing an entire system from scratch.  Still, if you think of Agile as primarily an iterative development approach, it could be, and is, successfully applied in ERP implementations where you can roll out modules or features in small increments. Not all ERP implementations lend themselves to an iterative approach, but some do.

When I asked Scavo about barriers to agile adoption, he pointed to the limits of bottom-up adoption, and the problem of ideologically-rigid agile enthusiasts:

My big takeaway is that Agile may start bottom-up, but at some point, IT management needs to embrace and formalize Agile processes within the development organization.  Developers may push for Agile, but in their zeal they may depreciate other software development best practices as “not agile.” For example, there is a small but vocal group of Agile advocates that go by the hashtag, #NoEstimates. They don’t think estimating of cost or schedule has any place in Agile development. Clearly, this attitude is harmful in anything but small, non-critical development projects.

Agile isn't about packaged software, it's about software as a differentiator

If there's a reason to pay attention to agile, it's the need to differentiate through software. With packaged software handling core functions, smart companies develop software that touches customers/suppliers and changes their model. Computer Economics says that's exactly why agile matters:

We say that over the past 20 years, packaged software has taken over many standard business processes. No one is writing financial systems, or payroll, or inventory management any more.  The good thing is that leaves corporate IT developers to work on the really strategic stuff. But that stuff needs the organization to be more agile.

When you are developing a system to give you a competitive advantage, you may not have a clear vision of what the system should do. The business may not be able to tell you.  So you need to be more agile, to be more flexible, and be able to quickly change direction.  That’s what Agile helps you do, if properly applied, and not misapplied, as we say.

Responding to agile's limitations

That explains why large enterprises lead the Computer Economics adoption stats: they are heavier into custom development:

We think Agile is adopted to a greater extent in large companies because, as our research shows, large companies tend to do more custom development than small companies do. We have one client at Strativa that is over a billion in revenue, and they do a lot of custom development.  They do all of it with Agile/Scrum.

As for the problem of agile development across time zones, Scavo conceded that scrum can be an issue. But other approaches can work:

Scrum places a strong emphasis on developers being physically located with one another. On the other hand, other Agile methodologies such as Distributed System Development (DSD) is designed specifically to address situations where developers are separated geographically.

My take - agile is maturing, but many companies aren't ready

This report blasts through misconceptions about agile as an "edge" technology not yet proven for core projects. Smart organizations are using agile at scale for differentiation they can't get from packaged software alone. One example: Applying the 12 Agile Principles in the Department of Defense.

Agile is really about iterative cycles. When you combine agile with a minimum viable product approach, you have a huge edge building relevant software that customers/users actually feel like using. And as I've written, today adoption is the bellwether.  It's hard to argue against the logic of involving your stakeholders in development early and often - no matter your company size.

Alas, many companies are not culturally prepared for such a ruthless cycle of revision. It's not the agile methodology that lets them down, but the unwillingness to uproot stale processes. One classic mistake: claiming there are diverse groups at the table when a key constituent - like sales users on the business side - is missing. Poor use/exclusion of external stakeholders is another.

I asked Scavo if my views on agile are naive, or if they hold up:

The fundamental problem addressed by any iterative development methodology is that for anything other than a simple system, business users simply do not fully understand their requirements up front. It is not that they are stupid, or lazy, or don’t want to provide requirements. It is that they very often cannot envision everything that they want the new system to do, or how it should do it.  It is only by seeing the system evolve that they can picture what they need.

Exactly. That's nothing new; smart peeps have been sharing prototypes as long as there were pads to sketch on. "Agile" just means we're building a coherent body of knowledge on what works and what doesn't - and a bigger pile of use cases. It would be ridiculous for me to imply, however, that simply plopping users and developers in the same room is enough. Scavo agrees:

By the way, I have seen cases even with Agile/Scrum, where the development team STILL complains that users do not give them a clear picture of their requirements. So, Agile may help, but it is not a panacea.

End note: For those who want more context, Computer Economics also issues an annual IT Management Best Practices report. 30+  practices are considered; agile is included. Scavo also told me that next year, they'll look harder at the industry breakdowns for agile. I could see the benefits of grouping some industries together, for example. This would compensate for the relatively small sample size of the report (149 companies, evenly divided between large/midsize/small), which makes a drill-down of too many industries difficult.