What is Agile

What Is Agile Software Development?

Never do anything that is a waste of time - and be prepared to wage long, tedious wars over this principle.

While interest in agile methodologies has blossomed in the past two years, its roots go back more than a decade. Teams using early versions of Scrum, Dynamic Systems Development Methodology (DSDM), and adaptive software development (ASD) were delivering successful projects starting from the mid-1990s.

The Agile Problem Domain: Fitting the Process to the Project

All problems are different and require different strategies. While battlefield commanders plan extensively, they realize that plans are just a beginning; probing enemy defenses (creating change) and responding to enemy actions (responding to change) are more important. Battlefield commanders succeed by defeating the enemy (the mission), not conforming to a plan.

I cannot imagine a battlefield commander saying, "We lost the battle, but by golly, we were successful because we followed our plan to the letter." Battlefields are messy, turbulent, uncertain, and full of change. No battlefield commander would say, "If we just plan this battle long and hard enough, and put repeatable processes in place, we can eliminate change early in the battle and not have to deal with it later on."

A growing number of software projects operate in the equivalent of a battle zone - they are extreme projects. This is where agile approaches shine. Project teams operating in this zone attempt to utilize leading or bleeding-edge technologies, respond to erratic requirements changes, and deliver products quickly. Projects may have a relatively clear mission, but the specific requirements can be volatile and evolving as customers and development teams alike explore the unknown. These projects, which I call high-exploration factor projects, do not succumb to rigorous, plan-driven methods.

The critical issues with high-exploration factor projects are as follows: first, identifying them; second, managing them in a different way; and third, measuring their success differently. Just as winning is the primary measure of success for a battlefield commander, delivering customer value (however the customer defines it) measures success for the agile project manager. Conformance to plan has little meaning in either case. If we want to be agile, we have to reward agility.

The concepts and assumptions behind empirical and defined processes are fundamentally different. The practices of agile software development -
- Short iterations
- Continuous testing
- Self-organizing teams
- Constant collaboration (daily integration meetings and pair programming for example)
- Frequent replanning based on current reality (rather than six-month- old plans)
are all geared to the understanding of software development as an empirical process.
On the other hand, the fundamental basis of the Capability Maturity Model® (CMM®) and CMM IntegrationSM (CMMISM) is a belief in software development as a defined process.

As such, tasks can be defined in detail, algorithms can be defined, results can be accurately measured, and measured variations can be used to refine the processes until they are repeatable within very close tolerances
For projects with any degree of exploration at all, agile developers just do not believe these assumptions are valid. This is a deep, fundamental divide - and not one that can be reconciled to some comfortable middle ground. It is part of having a chaordic (meaning a combination of chaos and order as coined by Dee Hock, founder and former CEO of Visa International) perspective on the world as described in the next section.

While agile practices - refactoring, iterative feature-driven cycles, customer focus groups - are applicable to nearly any project, I believe the agile sweet spot is this exploratory projects problem category. The more volatile the requirements and the more experimental the technology, the more agile approaches improve the odds of success.

Agile methods
Some of the well-known agile software development methods:
• Agile Modeling
• Agile Unified Process (AUP)
• Agile Data Method
• DSDM
• Essential Unified Process (EssUP)
• Extreme programming (XP)
• Feature Driven Development (FDD)
• Getting Real
• Open Unified Process
• Scrum

Agile practices
• Test Driven Development (TDD)
• Behavior Driven Development (BDD)
• Continuous Integration
• Pair Programming
• Planning poker
Note: Although these are often considered methodologies in and of themselves, they are simply practices used in different methodologies.

Agile beyond software development
Agile software development depends on some special characteristics possessed only by software, such as object technologies and the ability to automate testing. However, related techniques have been created for developing non-software products, such as semiconductors, motor vehicles, or chemicals.