Why Agile? (And What is Agile, Anyway?)

[originally posted on 7/18 on "Dev Blog"]

I'm hoping that by now everyone on our team has heard mention of agile software development, whether from someone else on the team or from a web site or a conference or another developer. Agile is a strategy for software development that favors frequent iterations, quick response to ever-changing requirements, and highly empowered cross-functional teams. There are a handful of popular agile methodologies, including Scrum, Extreme Programming and the Microsoft Solutions Framework for Agile Software Development.

Agile vs. Waterfall
Agile contrasts heavily with the more traditional waterfall strategy for software development. In a waterfall approach, the team follows a strict serial process through requirements gathering, analysis, design, construction, testing, and deployment. Each of these steps has a set of outputs, and no step can begin until the deliverables are received from the previous step. In a waterfall approach, the entire software product must be well documented before work on it begins. For this reason, waterfall is often referred to as a predictive approach.

Agile, on the other hand, is an adaptive approach. Agile methodologies acknowledge right up front that no amount of effort in requirements gathering will result in an accurate prediction of what the eventual released software product will be like. Because business needs change over the course of time (even during development!) the development process needs to be able to keep pace with these changes. In fact, agile methodologies treat requirements change as the normal state of affairs. Agile methodologies adapt to that change constantly, and in fact embrace constant change as the best approach to creating a healthy software product.

Elements of Agile
The most important strategic element of agile methodologies is iterative development. Agile developers create frequent releases of their product. The different specific methodologies prescribe anywhere from two to six weeks as the preferred iteration length. That's right: some agile developers are releasing their product every two weeks. It turns out that some of those releases will only be released internally, but each release must be fully prepared to be put into production: tested, debugged, and compiled for release.

During and between releases, product owners can work with team management to prioritize and document the functionality that will go into upcoming releases. At any time in a product's lifecycle, product owners can add requirements to the project. The way to keep that under control: new requirements are prioritized when they come in, and are not added to a release until they are deemed the most important functionality candidate before an upcoming release is defined and scheduled. In other words, any requirement can get in line for development, but only the highest priority requirements go into any given release.

During the development of a release, the team works together to design, construct, and test all of the functionality for that release. Teams manage themselves, defining the tasks needed to fulfill the requirements for a release, and working closely with each other to make sure everything gets done. The team does its own estimates, and decides what can and can't be done within the allotted time for a release. The team commits to "chewing what it has bitten off," and the team is responsible for its own management and delivery on its commitment.

The Big Difference
The greatest advantage to an agile approach to software development is one simple thing: agile gives product owners feedback early and often. Think about it this way: If you were starting out on a waterfall project, and you estimated that the project might take a year to develop, you would break the project down into sections: maybe two months for requirements gathering, another two for design and architecture, six months for construction, two months for testing and debugging. In that plan, the first time the product owner sees a release-worthy candidate is after ten months (after construction is finished). At that point, the business is ten months further down the road, the requirements are eight months old, and there's approximately a 100% chance that the product owner (or some other stakeholder) will look at what you've produced and say "Oh, wait. That's not what I need. Can we change it?"

In contrast, an agile project would get underway immediately, building the highest priority requirements. The foundation of the system would be laid early on, so there's a good chance that after the first release -- one month into the project -- you'd have a release, but it wouldn't have much to show. In the second iteration, though, you'd be showing important functionality. At the end of months two, three, and four, you'd be demonstrating the basic functionality of the product, in a releasable form -- looking polished, tested and debugged, ready for prime time (sans the lower priority requirements). That's when the product owner says the same thing: "Oh, wait. That's not what I needed." So now you have the chance to change what goes into the next iteration, without any sort of cataclysmic failure implied. The product owner updates the list of prioritized requirements -- just like they would before any release -- and you proceed with the new priorities.

Agile provides the opportunity to roll with the punches -- the punches we know are coming -- and to be successful in a realistic business environment. And in this example, you find out eight months earlier that something needs to change. Nice!

Successful business strategies require agility: the ability to change when necessary, and to adapt to a changing business environment. Agile development allows a dev team to keep up with the ever-changing needs of the business we support.

Ss.