Can the Agile Method Be Scientifically Proven?

DZone 's Guide to

Can the Agile Method Be Scientifically Proven?

Those who are waiting for the scientific verdict on Agile development run a strong risk of being left behind.

· Agile Zone ·
Free Resource

We at Purple Olive Labs, an app development company in Dallas, recently worked on this finance app that could predict stock market movements based on the news and current sentiments and present the well-analyzed data on the user dashboard. It was an Agile development method we relied on, and it delivered as expected.

In the past, I used diverse traditional development methods only to compromise with quality, performance, and ROI.

So, basically, Agile worked for me!

But the current discussion around the "scientific basis of Agile" doesn't hold water for a couple of reasons.

In this post, I will discuss the current debate around the topic and state some hard facts which will definitely help you reach a decisive point.

Can This Be Scientifically Proven?

Alistair Cockburn, a former hardware designer and researcher, was asked by IBM to write a methodology for the object-oriented project.

He, along with some software heavyweights, met to discuss so-called lightweight methodologies.

The test includes four value statements — individual and interaction over process and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan.

In software development methodology he termed the phrase, “People form process” and not the opposite. The process doesn’t matter a lot unless you have a strong team to work with. Moreover, the use of process doesn’t correlate with success or failure. Development is a cooperative game in which a move is not correct or incorrect, it is only better or worse the previous one.

So start focusing on people not the process.

I've heard Jeff Sutherland (the man behind Scrum) in a lot of talks. Once in a tech conference in Dallas, he mentions that Agile is an umbrella term. We can’t expect to see an experiment to prove anything. The studies which state its scientific prowess are too vague to be useful. Many empirical studies have been conducted, but the outcomes are inconclusive.

For more reference, read Software Creativity 2.0 by Robert Glass for insights on some interesting results.

So, it's not scientifically proven. Moreover, an analytical approach is unfeasible, since we are dealing with people here rather than a simple system. You cannot formalize the team and organization.

Let’s focus on some statistical results.

ROI of Agile Development Methodology

Little is known about the costs and benefits of Agile methods since their popularization in 1999, though 70% of projects use them and over 80 books and thousands of papers have been written about them.

Agile methods emphasize teams, working software, customer collaboration, and responding to change, while traditional methods focus on contract, plans process, documents and tools.

A study conducted by SEI identified 99 data points on cost, schedule, productivity, quality and ROI gains from 25 organization as reported by CMMI. Using this study along with the data covered from over 300 scholarly articles across the domain, both for Traditional and Agile process, the data is compiled in the table below.

In the above tables, the category represents the benefits of Agile and Traditional method. Low, medium, and high represent the range of reported benefits within each category.

On average, the study of Agile methodology reported 29% better cost, 91% better schedule, 97% better productivity, 50% better quality, 400% better satisfaction, and 470% better ROI than traditional methods, making Agile the clear winner.

Still, some parameters such as teams and customer collaboration are subjective considerations, which may vary from organization to organization. But this is the most comprehensive data analytics available so far.

The human factor is the most variable among all, making scientific objective analysis largely impossible.

Expectation of Requiring Proof Is Not Realistic

In the book Crossing the Chasm, Geoffrey Moore describe five types of profiles of technology adopters: Innovators who pursue new concept aggressively; early adopters who pursue new concepts very early in their lifecycles; the early majority who wait and see before buying into a new concept; the late majority who are concerned about their ability to handle a new concept should they adopt; and the laggards who simply don’t want anything to do with new approaches.

The figure below depicts Moore's chasm with respect to agility.

People who fit the innovator or early adopter profile are comfortable with reading a web page or book describing Agile techniques, thinking about the described concept for a bit, and then tailoring it for their environment. This is the spot in the lifecycle that most Agile techniques are currently at, and it is these types of organizations that are readily adopting these new techniques. The early majority will wait for sufficient anecdotal evidence to exist before making the jump to Agile software development, and we're starting to see adoption by some of these organizations now.

Unfortunately, the question of proof is typically asked by organizations that fit the late majority or even laggard profiles, as Figure 1 indicates. Because Agile techniques clearly aren't at that stage in their lifecycle yet, I believe that this question simply isn't a fair one at this time. Note that there's nothing wrong if your organization fits into either one of these profiles; many organizations are very successful following these business models. The important thing is that you recognize this and act accordingly.

There is currently significant anecdotal evidence that Agile software development techniques work, you merely need to spend some time with Agile practitioners to discover this for yourself.

adopting agile, analytics, education

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}