If you ask the question, "What is Agile?" you are likely to get lots of different answers. That's because there is no universally accepted formal definition for Agile. To make matters worse, there are ongoing debates over what Agile software development SHOULD mean. That being the case, when answering the question, "What is Agile?" the safest bet is to stick to what people can agree on, and people generally agree on three key elements of Agile. Taken together, these describe the Agile software development method, as well as the software development approach. In this post--the first in a series on Agile--I will explain the foundations of Agile and its use by developers.

Three key elements of Agile include

1. The Agile Manifesto
2. The 12 Agile Principles
3. Agile Methods, e.g., Scrum, Extreme Programming (XP), etc.

The Agile Manifesto is effectively the charter for the Agile community. It was created during the course of a weekend in 2001 by 17 software thought leaders who got together to discuss their frustration over the prevailing software development approaches. In a nutshell, they felt there was too much focus on software process and documentation, and too little focus on developing working software. The outcome of the meeting was the Agile Manifesto, which was signed by all in attendance and posted on the web as a guiding charter for the fledgling Agile community. The key themes in the Agile Manifesto are individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, and responding to change over following a plan. The 12 Agile Principles were created after the manifesto and further elaborate its ideals. The principles cover a fairly wide range of topics and explain how Agile developers should respond in a variety of circumstances. Here are the first few principles to give you a flavor for them

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.

The first and second elements are intentionally general and vague (what you would expect of principles?). The third element, Agile Methods, is where things get a little more concrete. There are many agile methods and each emphasizes different aspects of Agile. For example, the Agile Scrum method has a heavy software management emphasis (e.g. daily team meetings and a sprint-based lifecycle). The idea is to pick the methods that most closely align with your goals, e.g., effective small team leadership practices, increase efficiency and reduce waste, and conduct continuous integration and test strategies. An overview of common methodologies can be found at www.versionone.com/Agile101/Methodologies.asp.

That concludes my brief summary of some key Agile elements. I will close this posting by sharing an informal definition for Agile from the Agile Modeling website. I like this definition because it concisely embodies the spirit of Agile software development:

Agile is an iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner by self-organizing teams within an effective governance framework, with "just enough" ceremony, that produces high quality solutions, in a cost effective and timely manner which meets the changing needs of its stakeholders

The next post in this series will explore some of the foundational processes that are necessary for successful Agile software projects.

Please check out some of the great articles listed below. I particularly like the Crosstalk article Enabling Agility Through Architecture by the SEI's Research, Technology Systems and Solutions Program. Agile advocates quick and dirty solutions and refactoring later. This article discusses the importance of understanding when a quick and dirty solution is adequate versus when a more robust architectural solution is required (this balancing act is referred to as technical debt analysis in the article). The article also talks about the need for architectural dependency analysis when planning sprints.

Relevant links and articles:
SEI Report: Considerations for Using Agile in DoD Acquisition
www.sei.cmu.edu/library/abstracts/reports/10tn002.cfm

SEI Report: Integrating Software-Architecture-Centric Methods into Extreme Programming(XP)
www.sei.cmu.edu/library/abstracts/reports/04tn036.cfm?DCSext.abstractsource=SearchResults
Enabling Agility Through Architecture, Crosstalk December 2010
www.crosstalkonline.org/issues/novemberdecember-2010.html

The Agile Modeling website www.agilemodeling.com/essays/agileSoftwareDevelopment.htm

The Agile Manifesto
http://agilemanisto.org
The Agile Manifesto, Principles
http://agilemanifesto.org/principles.html