• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Bear Bibeault
  • Liutauras Vilda
Sheriffs:
  • Jeanne Boyarsky
  • Junilu Lacar
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Jj Roberts
  • Tim Holloway
  • Piet Souris
Bartenders:
  • Himai Minh
  • Carey Brown
  • salvin francis

Agile Vs Iterative

 
Ranch Hand
Posts: 1491
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
How Agile methodology differ from Iterative ?
 
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Wikipedia has a decent summary of the difference:

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.

 
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Lasse Koskela
author
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
...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.
 
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
A team doing iterative software development could still value

processes and tools over people and interactions,
comprehensive documentation over working software,
contract negotiation over customer collaboration, and
following a plan over responding to change

- and therefore not be Agile at all: http://agilemanifesto.org/
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
kri shan
Ranch Hand
Posts: 1491
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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"
 
Ilja Preuss
author
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd rather say that all Agile projects are a special kind of iterative projects.
 
author
Posts: 608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

- Scott
 
Scott Ambler
author
Posts: 608
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also, as far as the Wikipedia goes, you need to remember that just because it's posted there doesn't make it correct.

- Scott
 
Stan James
(instanceof Sidekick)
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Ranch Hand
Posts: 2187
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
"Binary thinking" will usually stifle an individual's natural ability when attempting to understand complex concepts.

"Agile" in terms of software development is used to describe a prescribed version of an "iterative" and "incremental" software development process as defined in the Unified Process.

Aside, the "Rational" Unified Process (RUP) is a customized and commercialized version of the Unified Process.
 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Luc Chase - excellent response
 
Don't get me started about those stupid light bulbs.
reply
    Bookmark Topic Watch Topic
  • New Topic