The online community for software testing & quality assurance professionals
 
 
Calendar   Today's Topics
Sponsors:




Lost Password?

Home
BetaSoft
Blogs
Jobs
Training
News
Links
Downloads



Quality Engineering >> Quality Methodologies

Pages: 1
Cies
Member


Reged: 07/11/05
Posts: 141
Loc: Gloucestershire, UK
Iterative vs Agile
      #447416 - 01/10/08 03:34 AM

I have just joined a company using Agile (or possibly not) and am reading up on it. I have come from a Unified Process background. Prior to that I used Waterfall.

My preliminary investigations are causing me to think of Agile as the very pinnacle of iterative development. However I have seen comments that lead me to believe I'm very wrong on this! So, can people tell me:

What are the key differences between iterative and Agile, that will categorically distinguish one from the other?

What have you found, are the advantages and drawbacks of either, in comparison to the other?

This will greatly help my understanding. Many thanks!

--------------------
"Even when the experts all agree, they may well be mistaken."


Post Extras: Print Post   Remind Me!   Notify Moderator  
JakeBrake
Moderator


Reged: 12/19/00
Posts: 15290
Loc: St. Louis - Year 2025
Re: Iterative vs Agile [Re: Cies]
      #447432 - 01/10/08 04:14 AM

Agile is the "pinnacle" if people choose to believe hearsay. Other than hearsay I have seen no conclusive evidence that agile is better than any other development methodology.

I submit to you the differences are between agile and others consist largely of terminology.

Test! Find any software product and testdrive it. Can you tell which methodology was used to develop it? It probably has bugs. It probably has "service packs". Odds are it was late to market. Odds are it might perform poorly. Odds are you cannot tell which methodology was used. If the app you selected was delivered ontime or sooner, and was defect free, and performed well, and development costs were cut, and the customer is satisfied, and the entire process can be repeated to produce great stuff, and - it was developed using agile - you have found a "pinnacle" model. In other words, a "pinnacle" methodology does not exist.

UP came from Spiral which came from waterfall. In my experience and as described in related documents, waterfall is iterative.

Here is a blog entry to reflect my opinion and experiences.
http://www.sqablogs.com/JakeBrake/863/Waterfall+Myth+Busted+Plus+Bonus+Busted+Myth.html

Here is a topic with documentation that shows some rather compelling results - although rather unscientific.
http://www.sqaforums.com/showflat.php?Cat=0&Number=247591&an=&page=0&vc=1


Post Extras: Print Post   Remind Me!   Notify Moderator  
DSquared
Moderator


Reged: 04/02/03
Posts: 4546
Loc: Wisconsin, USA
Re: Iterative vs Agile [Re: JakeBrake]
      #447436 - 01/10/08 04:27 AM

Here are a couple of links for your reading pleasure:

Agile propaganda
RUP propaganda
Wikipedia article on Agile
Wikipedia article on Scrum

I was pleasantly surprised to see that the Wikipedia article is actually quite balanced and well written.

There are a few practical differences between the two approaches. It is true that both have something that we can call "iterations" - small chunks of work. The difference that I have seen are in what is accomplished in the iterations, the approach to the iterations, and the structure of the teams.

In agile, a chunk of working code is the king of deliverables for each work cycle. The goal is to elaborate the requirements, get the design approved, build the thing, test it and deliver it in a chunk of time, be it called an iteration, work cycle, sprint, or whatever. Contrast that with iterations in RUP where there isn't always a chunk of working code as a result of the iteration.

In agile, the emphasis is on a chunk of working software over documentation, whereas in RUP, the deliverable may be the documentation itself.

The team dynamic is generally different too. There is an emphasis in agile on co-located teams and people filling a role, versus being assigned a position in RUP. For example, I have skills as both a BA and a QA, as well as some coding skills. In RUP, I would be assigned a single position - BA, QA or developer. In agile, I could do work in any of those roles, depending on who is available when, and what skills I bring to the table. I can and have done work in all three areas in the same agile project, where I have done work in only my assigned area in RUP. Additionally, there is an emphasis on having a customer rep embedded in the team, so they can tell you right away if what you are developing is right.

Lastly, there is what is characterized as "rapid prototyping" - build a quick and dirty piece of code, test it, find where it is not sufficient, correct the insufficiency, build it and test it again, all in rapid fire sequence. It was not uncommon for the QA folks to get 4 to 5 builds a day. When, over the course of a 2 week sprint, you get 4 to 5 builds a day starting at about day 3, you can do some pretty rapid development and correction.

These points are all from my working experience. I'm not sure how they line up with the propaganda. The final thing I will say is that I think the process worked for us because of the team we built, not because of any magic bullet process. Process is not a religion for me. I gladly take the pieces that work from each process and melt them together to make a process that works for my situation. I don't care what label people put on it, as long as it works.


Post Extras: Print Post   Remind Me!   Notify Moderator  
michaeljfModerator
Veteran


Reged: 09/17/01
Posts: 3979
Loc: Yankee Land
Re: Iterative vs Agile [Re: DSquared]
      #447482 - 01/10/08 05:54 AM

Ok, one thing not touched upon by Jake or D^2 yet, in Agile one of the focuses, and some say strength/weakness, is in the fact you document ONLY WHAT YOU HAVE TO. Nothing more. It is not "no documentation", and I have ranted on this before, so I won't do it again. Rather than long spec review meetings, and large MRD's and ERD's and Func Specs and Design Specs you might get one document for all of that within an Agile project. It allows people to sit and discuss first hand what is being built, and how and why, so there is no miscommunication since the people involved are co-located, meet often (the daily stand-up) and are available for further questions.

One other advatnage, which I like, of Agile/Scrum is the information radiator, it allows seeing what tasks are done that are assigned. How many are left before the end of the sprint, and how much time is supposedly been allocated to the rest of the tasks. As work is completed you have an idea from that, and any other posted information, what the state of the project is, whether it is on track or not and who is doing what, all in one area and no need for fancy reports or metrics documents to be generated. Unnecessary, eh? ;-)

I blogged some about my experiences with Agile and Scrum if you want to take a look at the blog in my signature, that may give you some insight as to my experiences.

Working with a lot of processes I don't really have a preference for any one particular process, parts of each I think are worthwhile as it all depends on the project and work environment and team.

- M

--------------------
- M

Nothing learns better than experience.

"So as I struggle with this issue I am confronted with the reality that noting is perfect."
- Unknown

Now wasting blog space at QAForums Blogs - The Lookout


Post Extras: Print Post   Remind Me!   Notify Moderator  
Cies
Member


Reged: 07/11/05
Posts: 141
Loc: Gloucestershire, UK
Re: Iterative vs Agile [Re: michaeljf]
      #448366 - 01/14/08 04:17 AM

Many thanks guys.

Quote:

Agile is the "pinnacle" if people choose to believe hearsay. Other than hearsay I have seen no conclusive evidence that agile is better than any other development methodology.



I said the "pinnacle" of iterative development - not software development. What I was trying to say, was that (as I understand it) Agile is kind of as iterative as it gets - not as good as it gets. The jury is out with me on the Agile debate, until I've done it!

However, having said that, and read the above posts, I'm not sure that Agile is different because of the iterative approach. Surely the iterations may be very similar to a RUP project.

Talking of which:

Quote:

In agile, a chunk of working code is the king of deliverables for each work cycle...Contrast that with iterations in RUP where there isn't always a chunk of working code as a result of the iteration.



I thought that, too. But when I was given an "overview of Agile development" by my boss, I questioned why sprint 0 was a pure design sprint, where the architecture was fully defined. Coming from an iterative and risk-based background, this looked wrong to me. She said this approach is still Agile. I subsequently questioned it with the consultant brought in to implement Agile here (who is a guru on Agile development - his thesis is in it) and he, too, said this was ok. I said about the working code thing, and he said it was fine to have sprints without working code as a deliverable, and instead maybe documentation or a design. Just like iterative...what do you guys think on this?

Quote:

The team dynamic is generally different too. There is an emphasis in agile on co-located teams and people filling a role, versus being assigned a position in RUP.



That's not true about RUP - at least, definitely not where I worked. We made roles clear, and had flexible resourcing. I don't think that has anything to do with either RUP or Agile. It's common to all projects. I do see that the emphasis on co-location is different. I am also getting the impression that people may carry out roles for which they are untrained in Agile...which makes me nervous...but please do correct me if I'm wrong on this.

--------------------
"Even when the experts all agree, they may well be mistaken."


Post Extras: Print Post   Remind Me!   Notify Moderator  
DSquared
Moderator


Reged: 04/02/03
Posts: 4546
Loc: Wisconsin, USA
Re: Iterative vs Agile [Re: Cies]
      #448382 - 01/14/08 05:11 AM

Quote:

Quote:

In agile, a chunk of working code is the king of deliverables for each work cycle...Contrast that with iterations in RUP where there isn't always a chunk of working code as a result of the iteration.



I thought that, too. But when I was given an "overview of Agile development" by my boss, I questioned why sprint 0 was a pure design sprint, where the architecture was fully defined. Coming from an iterative and risk-based background, this looked wrong to me. She said this approach is still Agile. I subsequently questioned it with the consultant brought in to implement Agile here (who is a guru on Agile development - his thesis is in it) and he, too, said this was ok. I said about the working code thing, and he said it was fine to have sprints without working code as a deliverable, and instead maybe documentation or a design. Just like iterative...what do you guys think on this?




I've seen sprint zero as a design sprint too. And I've seen pure QA sprints where no new functionality was delivered. But generally, sprint goals include some sort of demonstration of working code.

The beauty of Agile is that it is not REQUIRED that working code is a result, although it is highly ENCOURAGED. Agile, by it's nature, allows you to change things to fit what you are doing. So, your observations and comments from others are not out of line for agile. Each sprint can be adjusted, based on what previously happened, to do what needs to be done at the moment, without hugely effecting the entire project. Please note that I did not say that there is no effect - just not as huge as if a change needed to be made in other methodologies.

Compare and contrast with RUP and other process oriented iterative development methodologies, where all deliverables are determined and scheduled at the very beginning of the project. Everyone knows that at the end of the requirements phase, a requirements document is due. At the end of development, the whole code thing is due. At the end of testing, all tests must have been performed and passed. Very lockstepped and not very flexible.


Post Extras: Print Post   Remind Me!   Notify Moderator  
michaeljfModerator
Veteran


Reged: 09/17/01
Posts: 3979
Loc: Yankee Land
Re: Iterative vs Agile [Re: DSquared]
      #448488 - 01/14/08 09:47 AM

Well in Agile the expectation is you are doing something you are trained to do, someone who is not a Java Coder shouldn't be doing Java tasks in a Sprint unless its with a mentor. Unless you are assigning people tasks that include coming up to speed, or studying it in the sprint, then no one should be doing work they are unprepared to do. I don't know anyone who has done it the way you fear it may be, so this may be an ungrounded fear.

--------------------
- M

Nothing learns better than experience.

"So as I struggle with this issue I am confronted with the reality that noting is perfect."
- Unknown

Now wasting blog space at QAForums Blogs - The Lookout


Post Extras: Print Post   Remind Me!   Notify Moderator  
devagile
Newbie


Reged: 01/28/08
Posts: 7
Re: Iterative vs Agile [Re: michaeljf]
      #452973 - 01/28/08 12:42 PM

You can be iterative and incremental without being "agile" (as if only one definition exists about what it means). In their book "agile and discipline made easy", Per Kroll and Bruce MacIsacc (both with a RUP background) tell us that you will be "non-agile" if you still perform activities (design, code, test) in sequence in each iteration. Thus to be "agile" (but it is not sufficient) you should perform all activities in parallel during the iterations.

--------------------
http://www.devagile.com/


Post Extras: Print Post   Remind Me!   Notify Moderator  
kamalakn
Newbie


Reged: 08/19/12
Posts: 3
Re: Iterative vs Agile [Re: devagile]
      #719260 - 11/04/12 11:07 PM

Iterative development is just one part of Agile. Agile is much more than the iterative development. Its holistic approach for development. If we can understand the 12 principles of Agile, it will clear this ambiguity.
1. Practice simplicity
2. Technical excellence
3. Satisfy the customer
4. Welcome change
5. Frequent delivery of working SW
6. Self-organized team
7. Sustainable development
8. Measure of progress wrt working SW
9. Team collaboration, etc


Post Extras: Print Post   Remind Me!   Notify Moderator  
Pages: 1



Extra information
0 registered and 14 anonymous users are browsing this forum.

Moderator:  blueinatl, AJ, michaeljf, swt88 

Print Topic

Forum Permissions
      You cannot start new topics
      You cannot reply to topics
      HTML is disabled
      UBBCode is enabled

Rating:
Topic views: 20231

Rate this topic

Jump to

Contact Us | Privacy statement SQAForums

Powered by UBB.threads™ 6.5.5