This week's book giveaway is in the OCMJEA forum. We're giving away four copies of OCM Java EE 6 Enterprise Architect Exam Guide and have Paul Allen & Joseph Bambara on-line! See this thread for details.
Most agile methods share iterative development's emphasis on building releasable software in short time periods. Agile methods differ from iterative methods in that their time period is measured in weeks rather than months. Most agile methods also differ by treating their time period as a strict timebox.
Iterations are a necessary part of agile ways, but not sufficient to call yourself agile based on iterations alone. I like iterative defined as Frequent Delivery of Running Tested Features. My own paraphrasing of the breakdown:
Frequent - daily to bi-weekly, plus or minus
Delivery - hand-off to customers or testers
Running Tested - production quality, ready to approve and use not ready to debug
Features - things the user recognizes as useful
I used to do iterative by this definition with mainframe COBOL even when the project teams were not agile. I think this is the most profound change you can bring to a customer / developer relationship. Some of the other agile stuff will follow naturally, some of it has to be there (whether you see it or not) to make this work.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jan 23, 2002
...and what Stan above calls "Frequent Delivery of Running Tested Features" also hints at incremental development. Agile methods are both iterative and incremental, meaning that each iteration results in a fully working product--and each iteration improves on what was built in prior iterations as necessary.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Joined: Jan 29, 2003
Absolutely agree. Been there, or maybe I'm permanently stuck there.
I think getting to short iterations would either mean getting rid of those documentation and process roadblocks or would expose ways to work without them. I keep hoping this, anyhow.
Joined: Apr 08, 2004
Lasse, i got this doubt after reading these same lines in Wikipedia. Is this the only difference? "Agile methods differ from iterative methods in that their time period is measured in weeks rather than months"
Joined: Jul 11, 2001
I'd rather say that all Agile projects are a special kind of iterative projects.
I like to define agile software development as: Agile is an iterative and incremental (evolutionary) approach to software development which is performed in a highly collaborative manner with "just enough" ceremony that produces high quality software which meets the changing needs of its stakeholders.
Also, as far as the Wikipedia goes, you need to remember that just because it's posted there doesn't make it correct.
Joined: Jan 29, 2003
I think you have to be careful with "incremental" as some people think that means it's ok to deliver half-baked mostly-working stuff and finish it up in the a later iteration. They may associate incremental with build a beautiful non-functional prototype and gradually implement one feature at a time in a way that doesn't have a truly working and deliverable system until the last day. Just be sure that everyone shares the "good" definition.
Remember "Agile" is a label, a name, like a brand. It represents a set of principles, methods, attitudes, etc. for delivering a new system. But many of those methods and attitudes existed before they were packaged into something called Agile. There were and still are other methodologies which have been practising similar attitudes, methods and principles. It's good to have a distinct name, but it doesn't mean that nothing like exists. In a way, it is a fork of other methodologies.
To say that one deals in months and the other in weeks is wrong. A period of activity in one project may be very different from that of a different kind of project, even within the same methodology. Also, having the right tools (and methods) is very important to being able to do things in a rapid and highly responsive way. Evolutionary methods are not very concerned with heaps of documents, they use functional prototyping as part of the analysis and design deliverables and so the documentation effort tends to shift more towards documenting how to use and maintain the delivered solution. And remember the 'system' is not just the software. It is the whole System. In the case of a business it is the whole business-system, the way they carry out the business functions; the automated parts as well as the manual parts. In other systems such as algorithmic trading it may be a fully automated trading-system or the algorithm (process) may be partly manual.
My over-simplified way of looking at Agile vs. what is known as RAD, Iterative or Evolutionary (with functional prototyping) is that Agile makes use of more methods in the area of teamwork facilitation.