The Real Definition Of Agile

In AgileSoftwareDevelopment, AlistairCockburn describes an agile process as being both light and sufficient, where lightness means maneuverability, and sufficiency means facilitating future development. He then identifies five "sweet spots" that characterize agilility, having to do with team size and composition, frequency of feedback on the product and process, etc. I've found his conception more helpful, in gauging whether a project is "agile", than a checklist of practices from a particular agile method.

That sentiment was echoed by a group of participants in the "Executive Summit" of the 2003 AgileDevelopmentConference, who concluded that they have come to value the principles of agile development over the practices of agile development (that is, while there is value in the item on the right, they value the item on the left more).

de-paraphrased by PhlIp:

While developing software, the time between test runs matters.

The most difficult but important increments to test are the end-users? productivity gains.

At one scale, some projects manually test every few weeks, or less often. That impedes improving end users? productivity; inner cycle delays compound outer cycles? delays.

AgileSoftwareDevelopment exploits the other end of the scale. We automatically test everything relevant to a module after the fewest possible edits; say 10 at the most. So we only perform the kinds of edits that immediately return the project to a testable state.

Make testing, including manual testing in the hands of real end-users, as cheap as possible. Bugs delay feedback, so write simple code and lots of tests. Time spent ?perfecting? the object model delays getting to that feedback, so use a ?good enough? object model. Harness feedback to defeat process waste.

Testing the act of changing code fundamentally shifts how our industry specifies good design. Books like DesignPatterns show good solution instances, frozen in time. Books about Agility describe dynamically seeking good designs.

Test coverage makes inspiration and intuition safe. Tight & automated feedback increases the odds we catch errors as soon as we make them, not weeks or months later when memories are stale. Unnoticed errors lead, later on, to long bug hunts in code that may since have grown more complex.

Incremental changes and relentless testing permit Agile projects to reach for these goals:

accept feature requests in any order, at any time
release any Integration to QualityControl and beyond
minimize the time between specifying a feature and using it (SoftwareInProcess, LeanDevelopment?)

A project?s client steers with feature requests, getting the most important ones first. The sooner these features help end-users add value, the sooner our project lifts off the runway and sustains itself.

note that while PhlIp formerly inspired others to write a page called "TheRealDefinitionOfAgile", PhlIp himself knows better than to present goals as definitions or diagnoses.

So what if you were to define what it meant to be Agile and you didn't have to worry about satisfying the hopes and fears of all the 17 founding members of the AgileAlliance? I think you'd come up with something like the above.

It's simple and it's got the same HardCore? and honest feel as:

Listening, Testing, Coding, Designing. That's all there is to software. Anyone who tells you different is selling something.

I can do those things and release poodles, not software.

If you did, then I don't think you understand what Listening means

To me the essence of Agile is expressed in a Zen poem I read some time ago: "With but rod and sandals I traverse the ten thousand worlds"

I would guess that only one guy actually got through the ten thousand world with just a rod and sandals, and I'm thinking he may have had a towel he's not telling us about.

I can do those things and release poodles, not software.

If you did, then I don't think you understand what Listening means

Why would a process working for making good software not work for "manufacturing" good poodles?

Because software is not hardware, nor a living thing. Not everything that applies to manufacturing or biological processes applies directly to software development, and vice-versa. To think otherwise is naive - there is no "one process to rule them all." -- JamesTwine

What do you mean he wouldn't understand what Listening means? Maybe I don't understand either? To me, listening is requirements gathering. If the requirements are that they need poodles, and I produce poodles, where have I misunderstood what is meant by listening?