Agile development means using feedback to prevent waste and optimize development.
Software development follows an inner cycle of writing code for new features, and an outer cycle of delivering versions to users.
Feedback" means you set up a cycle so your project can tell you about its current status, early and often.
- The inner cycle risks waste when we debug too much, or write too many lines. Larger teams also cause waste when one person must wait for another to upgrade their modules.
- The outer cycle risks waste simply because when customers wait a long time for new features, the odds increase that they will request changes to existing code.
Put together, these processes allow teams to move rapidly to new territory, and to not trip or make mistakes getting there. The dictionary's word for such fleet and sure-footed behavior is "agile".
- The most important feedback for the inner cycle is automated tests. They prevent wasting time debugging, and they help you remove lines of code that are not needed. And they make your code safe for others to change, so they don't need to wait for you.
- The most important feedback for the outer cycle is frequent releases to end users. If you give them the high value features first, then the odds they will request rework are low. (High value features tend to have obvious specifications.) Then, the odds they will request new features are high, so you repeat. Each new release will reinforce and fine-tune the high value features.
John Roth wrote:
Agile is a style of project management which lets the project respond quickly to changing requirements. It also usually incorporates frequent releases, or at least the possibility of frequent releases without undue extra project management overhead.
Ease of handling changing requirements naturally leads to leaving the definition of detail to the last responsible moment, rather than having to have all details completely specified up front.
Most named agile methodologies don't specify much outside of project management. Scrum, for example, specifies a lot of project management, a small amount of team practice (put the developers in a room and do daily standups) and gives essentially no guidance about how to actually construct the software.
XP is the only one I know of that specifies all three (project management, team practice and software construction practice) in detail.
C. Keith Ray wrote:
Agile methods react well to changing requirements, permit delivery of working, tested, software at frequent intervals, and generally require less "overhead" than older document-driven formal methods. To enable this reduction of overhead, Agile methods rely on "social" tools and practices (such as shared-workspace, "information radiators", and retrospectives) as well as technical tools and practices like automated builds and automated tests.
Someone referred to James Bach's definition of an agile methodology:
agile methodology: a system of methods designed to minimize the cost of change, especially in a context where important facts emerge late in a project, or where we are obliged to adapt to important uncontrolled factors.
A non-agile methodology, by comparison, is one that seeks to achieve efficiency by anticipating, controlling, or eliminating variables so as to eliminate the need for changes and associated costs of changing.
Steven Gordon wrote:
What makes this question so vexing to so many is that being agile is contextual rather than definitive.
Being lean and principled is not necessarily sufficient to be agile - one must garner feedback from the context (from customers and management as well as ourselves) and adapt appropriately to that feedback to remain agile. Doing the exact same things could be agile in one context and not particularly agile in another.