AgileDevelopment

Whats your definition of AgileDevelopment?

Refers to the speed of operations within an organization and speed in responding to customers (reduced cycle times). In contrast, "Adaptable" refers to the ability to respond to macro changes, such as a change in legislation, entrance of a strong competitor, etc. (Result)

For an email discussion on the subject use the Community Forums. Also see: AgileSCM, ContinuousIntegration, Extreme Programming

AgileDevelopment Methods

AgileDevelopment Methods and Extreme Programming XP have disrupted our view of software development, leading the industry towards lean, adaptable development methodologies. XP and AgileDevelopment Processes will change the way software is developed for some time to come.

An "agile" methodology or process is one that adheres to the tenets of the AgileManifesto. Some examples of agile software development methods are: SCRUM, Jim Highsmith's Adaptive Software Development^?, Feature Driven Development^?, the Crystal series, DSDM, Agile Modeling^?, and, of course, XP.

Also see the AgileAlliance and AgileManifesto

-- PatrickEgan^?

Agile software development methodologies are based on short cycles of iterative development. By developing software in an iterative and rapid fashion, a development team can put working software in the hands of the customer quickly to solicit feedback and refine the requirements for the software system under development.

What is the role of SCM for Agile Software Development Projects^?? Add your comments to Agile SCM

-- MichaelSayko^? - 20 Dec 2002

What comes around goes around - agile has been around for more years than people know - and it got its start in the hardware world. My first encounter with agile methods occured in the summer of 1969. It was between my junior and senior years working towards a BS Aeronautics and Astronautics. My focus at the time was low speed aerodynamics and structural analysis. I recieved a National Science Foundation summer grant to determine the range of validity of a linearization of a non-linear stability theory. I needed to solve the non-linear problem which of course began my love affair with computers. I learned Fortran, numerical methods, and of course how to entice the operator to let me into the computer room at 2 am in the morning so I could get rapid turn around on my program. OK, how is that agile? Well the numerical method I used, Predictor, Corrector, had been established and used to solve hardware problems many years before I or computers came along. The basic thing I remember about the method is that rewrote the equation in form f(x) - x = 0. You guessed a solution, calculated a result, based on how far off from zero the result was you calculated a new value of x and did it again. You continued this until the remaining error was acceptable (e.g. you got an error of say .00001). When I got into industry I saw and used similar methods within "heavy weight" approaches. They were most often applied to high risk areas and involved, build a little, test a little, correct a little, do it again until you get it right situtations.

That said, I didn't write this to disparage the Agile community. My experiance helps explain why I feel comfortable with it and why I have a hard time understanding many of the objections to it. The fact is, its an extension for software of what the overall Engineering community has been doing for years. In fact (new thought for me) maybe its one of the necessary steps in creation of a true Software Engineering profession!

-- BobVentimiglia^? - 21 Feb 2003

Excerpt from Martin Fowler's paper "The New Methodology"

Agile methods have some significant changes in emphasis from heavyweight methods. The most immediate difference is that they are less document-oriented, usually emphasizing a smaller amount of documentation for a given task. In many ways they are rather code-oriented: following a route that says that the key part of documentation is source code.

However I don't think this is the key point about agile methods. Lack of documentation is a symptom of two much deeper differences:

• Agile methods are adaptive rather than predictive. Heavy methods tend to try to plan out a large part of the software process in great detail for a long span of time, this works well until things change. So their nature is to resist change. The agile methods, however, welcome change. They try to be processes that adapt and thrive on change, even to the point of changing themselves.
• Agile methods are people-oriented rather than process-oriented. They explicitly make a point of trying to work with peoples' nature rather than against them and to emphasize that software development should be an enjoyable activity.

[End Excerpt]

So what's the point of emphasizing the heavy documentation then, why do organizations insist on doing it?

The way I see it, the reason might have something to do with responsibility. Maybe producing something is not enough to those organizations. Maybe they make the effort for the sake of being accountable for the product, not just for the developers who created it.

In my understanding, these organizations believe that there is some valuable knowledge that needs to be shared, and make an attempt to capture and maintain that shared knowledge in the form of documentation. After all, we have to admit that in many respects, we are still living Gutenberg's era, we still believe that writing down words on readable media is the numero uno method of knowledge sharing.

Anyhow, let's not put too much notice on the format, as Fowler points out in the paper "The New Methodology", there is a deeper difference here. Do the apostles of AgileManifesto promote the process of turning private knowledge into shared knowledge? I do not see that, at least not on the surface level. This is where I see the main difference between the "heavy-weight", "document-oriented" "process-savvy" approaches versus the "agile" and the like.

-- TerryMiramax^? - 17 Jan 2003

[Note: Some WikiPageRefactoring was done on the above. See HeavyDocumentation to expand on that term.]

From the various agile mailing-lists, books, and face-to-face conversations with noted "agilists", I know that AgileDevelopment "apostles" believe that knowledge is valuable and should be shared. They suggest that documentation is not necessarily the best means of sharing it. According to the field of KnowledgeManagement^?, documentation is a form of static, passive knowledge. It is a good way to record knowledge for posterity (or posterior but is not necessarily the best form of knowledge transfer. For that, human interaction is what the "agilists" say they prefer. They say they aren't against creating documentation per se, but prefer face-to-face interaction (and perhaps "lite" docs) where some heavier-weight methods instead overrely upon more documentation.

-- BradAppleton^? - 21 Jan 2003

From the Community Forums:

It sounds like agile CM is similar to what I call RAPID CM - as in Rapid development. Just a new word for an old idea. Oh well, we all have to repackage from time to time. (a mild attempt at humor).

-- StevenKershaw^? - 14 Jan 2003

Use of the name "agile" is fairly recent for describing a category of software development methods. The term lightweight was previously being used, but some felt that wasn't quite an accurate word, and since the term "organizational agility" was (and is) fairly popular, they felt it fit in this case as well. But that is neither here nor there ....

I feel it is important to note that "agile" isn't simply repacking of 100% old ideas. There are a few new elements thrown into the mix with all that older and more familiar stuff. Some of the methods classified as "agile" are old methods that have been around for awhile (like DSDM). And there is a big intersection of RAD and Agile, such as DSDM and Highsmith's 1994 RAD article

It is very true that many of the ideas that go into it have been around a VERY long time such as iterative development and a spiral-like lifecycle (heck, wasn't Tom Gilb's "evolutionary delivery" at the beginning of the 70s?) One fundamental characteristic of agile methods is that not only are they iterative, but (as MichaelSayko^? says above) the iterations are typically very short: as little as one week, to possibly 14 weeks (but with a more typical range of 1-4 weeks).

I think probably the key differentiating factor of "agile" methods has to do with the so-called "cost of change" curve. The usual thinking is that, the more lifecycle phases that pass between the introduction and correction of a fault, the cost of rework to fix it is about an order of magnitude more expensive for every phase it escaped. Agile methods turn this on its ear and challenge this thinking, and suggest that under certain circumstances, this "cost of change" need not be exponentially increasing, and in fact could be flattened somehow.

The best "succinct" description of it I can recommend would be the article Retiring Lifecycle Dinosaurs from STQE magazine (Software Testing and Quality Engineering, July/Aug. 2000). Another good, short intro would be Martin Fowler's The New Methodology as noted above. Martin also has a short article on the Agile Manifesto that does a good job of explaining its ideas and principles.

Another element of Agility (not just for software, but organizationally as well) is the concept of "emergence" and "self-organization" from the science of complex adaptive systems and complexity theory. Some of these elements are present in something like RAD, but it's not an intentional part of it the way it is for so called "Agile" methods (see http://rockfish-cs.cs.unc.edu/COMP290-s02/CoHiInnov-01.pdf)

Another element related to the complexity theory is the premise that software development should not be considered to be like Manufacturing in its models and processes (which is what CMM and others are premised upon - Crosby's writings and the Manufacturing Maturity Model (MMM)). The agile premise is instead that software is more like the scientific method of new discovery, due to rapid and volatile change, and a model of hypothesize-experiment-adapt/adjust is more appropriate.

This leads to a different mind-set that relies more heavily on feedback that is more frequent. Instead of focusing more on end-of-phase reviews to try and catch faults before going to the next phase, it's almost as if the mind-set is one of embracing constant change/adjustment rather than trying to prevent it.

Rather than laboring so hard during a phase or lifecycle to get spend a lot more time making sure I get it right after every phase, accept that I won't get it right the first time (or the second time), and instead, simply fail much sooner, more frequently, and learn from it and make corrective action much earlier and more frequently. Elements of this are also present in Boehm's risk-based spiral model, but its not quite so blatant there as it seems to be in the most popular agile methods.

Some of the agile methods are more blatant about this than others (e.g., Extreme Programming, SCRUM, Crystal, ASD) and tend to be the newer ones. Some of them are more moderate and its harder to see the difference between them versus highly iterative spiral model (FDD, Agile Modeling, DSDM).

I personally think some of the more "flagrant" or "extreme" agile methods are that way in part due to a violent counter-response to the Software CMM and similar frameworks (which I can understand, but I don't think it's quite necessary. Running all the way to the other end of the spectrum is just as imbalanced as the (mis)application of CMM that is being rejected)

So while there is certainly a lot of "old stuff" and existing best-practices in "Agile" software methodologies - there are one or two (maybe even three) very different things which flagrantly challenge some of the prevailing wisdom that gave us Formal Inspections, SQC, and the CMM.

If any of the articles mentioned above whet your appetite, then I'd recommend going to the "articles" index at the agile-alliance and do a subject search.

Or if you decide you're ready for an overview book, either Agile Software Development by Alistair Cockburn (pronounced "Coh-burn" or the more recent Agile Software Development Ecosystem's by James Highsmith). If you're really interested in the complexity-theory angle, look at Highsmith's book Adaptive Software Development (but it might be easier to just get the gist of it from the aforementioned articles if you don't want to get quite so buried in it).

I hope that helps! I think Agile is an important thing to understand, and not simply write-off as "what's old is new again". I think a lot of its current popularity is from the classic vicious cycle of bouncing back and forth between extremes. Before CMM, there was not enough emphasis on process. Then many started taking it too far in the other direction as people clamored for CMM-ratings (passing the test and having the appropriate docs & bureaucracy became more important than the process and its effectiveness for many shops that misapplied the CMM).

Now the swing is going back in the other direction, and "agile" is a big part of that. But there is something new underlying a lot of the old stuff making a "comeback".

-- BradAppleton^? - 06 Feb 2003

Note that much of the above has since been summarized and reorganized into the CMBoK under the section on CM's Contributions to Development