Agile Development Embraces Business Agility

In my post, What is Better About Agile Development? (a reprint of the article Top 10 Reasons to Use Agile Development that I wrote for DevX.com), my second reason for using Agile development is that Business agility is embraced. This post will expand on the topic.

Wikipedia defines business agility as: “The ability of a business to adapt rapidly and cost efficiently in response to changes in the business environment.”

Given today’s global, competitive economy, the ability for the business to respond to change is critical. Does it feel that change is continuing to accelerate to you? If so, at what rate?

If you want an extreme take on the subject, Ray Kurzweil states in an article, Understanding the Accelerating Rate of Change that, “The whole 20th century, because we’ve been speeding up to this point, is equivalent to 20 years of progress at today’s rate of progress.”

Sometimes, the consequences of failing to adapt is failure of the business. Faisal Hoque makes the case for business Agility in an article, The Speed of Business Today, asserting, “Constant change is the new dynamic of the global economy, and makes agility even more necessary than at any point in business history.” Faisal then states:

• Only 74 of the original 500 companies in the S&P Index are still on the list 40 years later―a mortality rate of more than 10 per year. 
• The average life span of an S&P 500 company has steadily decreased from more than 50 years to fewer than 25. 
• Projecting forward, it’s likely that only about one-third of today’s major corporations will survive as significant businesses for the next quarter century. 

I think that it is safe to assume that technological progress is due to slow at some point in time, but none of us really know when. Relating business agility back to software development, the observation that I made in my article was simple: “Software development practices shouldn't run counter to business needs by forcing the business to choose and adhere to a set of pre-determined features that will be delivered months, if not years, into the future.”

This is contrasting Agile development against a traditional, plan-driven software development approach. As the rate of business change continues to increase, if only seems prudent to utilize a software development approach that mirrors the needs of the business, particularly since the purpose of software development is to support the business. Agile development welcomes and adapts to change, which means that Agile software teams can adapt in accordance with continually changing business conditions.

My brother Brian made an interesting observation about software projects at his company (he works for a large company that I won’t name here). They struggle with containing costs and overall project throughput because they still use a plan-driven approach and they want everything “done right.” The problem is, doing things right in their context means adding features up front so that they “don’t have to come back to the project later.”

In an effort to nail every project and then move on, my brother’s company is costing themselves time and money. The notion of getting in and out quickly – failing fast in some cases – is not present. They COULD be introducing another problem for themselves as well. (If they aren't, others do have this problem.) In their attempts to be thorough, could be spending some of their valuable time building out features that they don’t really need.

Does this sound like your situation? If so, take a look at a widely-quoted study by the Standish Group, a typical system has a variety of features/functions that are rarely or never used:

The message here is simple: What you think you need at the outset of a project may not always be what you really need. Large, plan-driven projects with a large feature count will increasingly be at odds with the need for adaptability on the business side. A smaller project with a well-defined scope and feature set where you “get in and get out quickly” certainly helps, as does a methodology that supports adaptability.

Using an Agile development approach, the most valuable, prioritized features will be delivered in short periods of time with continuous involvement from the business. The business gets to use the software and provide feedback, both in terms of the actual features delivered and about what the future priorities should be. Agile development projects are thus able to easily adapt in accordance with changing business conditions.

In my own company, we frequently review priorities as a management team, and we’ve certainly seen our priorities change throughout the year. As time marches on, information becomes available, information that you did not or simply could not have at the beginning of the year. Did those prospects purchase our software? Did some new competitive threat emerge? In addition, getting software into the hands of the users as early as possible yields valuable feedback and can help identify new, valuable requirements, something that we’ve experienced.

Other companies value this capability as well. In the 2009 State of Agile Development Survey sponsored by VersionOne, the number one benefit obtained from implementing Agile development was the ability to manage changing priorities. 90% of respondents said implementing Agile either improved or significantly improved their ability to manage changing priorities. (The survey data included 2,570 participants in 88 countries.)

An older survey, the Shine Technologies 2003 Survey, was another global survey of actual experiences using Agile development. The highest ranked positive feature reported in the survey was the ability to “Respond to change over plan,” which came in a 47.3%.

Another great, real-world example of improving business agility is the story of Salesforce.com. Salesforce.com was growing rapidly, but it was becoming increasingly difficult for them to deliver. Salesforce.com experienced problems that most plan-driven projects experience, such as late feedback on features at the end of the release cycle, and long, unpredictable release schedules. The frequency of Salesforce.com’s releases went from 4 per year to 1, meaning that customers were waiting longer to get less from the company. This is far from embracing business agility!

Salesforce.com undertook an all-in, major transformation to Agile development. Within one year, Salesforce.com delivered 94% more features, and Salesforce.com calculates that it delivered 500% more value to its customers compared to the previous year. And within 2 years, Salesforce.com’s revenue had doubled. (These specific numbers are reported in Mike Cohn’s book, Succeeding with Agile: Software Development Using Scrum.)

I’ve embedded the complete Salesforce.com presentation by Steve Greene and Chris Fry that talks about Salesforce’s Agile transformation given at the 2007 Agile Conference so that you can view Salesoforce.com's story for yourself.

Salesforce.com Agile Transformation - Agile 2007 Conference

View more presentations from Steve Greene.

While traditional, plan-driven projects have certainly succeeded (and I’ve been a part of them), what are your thoughts on meeting the competitive demands of today’s world? Is software development adaptive and response enough? Is Agile development the right solution to this problem?