This week's book giveaway is in the Mac OS forum.
We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line!
See this thread for details.
The moose likes Agile and Other Processes and the fly likes what is advantage agile over other methods Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "what is advantage agile over other methods" Watch "what is advantage agile over other methods" New topic
Author

what is advantage agile over other methods

shinu pillai
Greenhorn

Joined: Oct 24, 2006
Posts: 9
what is advantage agile over other methods.How it ensure time frame keep with in deadline if one person resign from role??
Klaus Meucht
Greenhorn

Joined: Jul 24, 2004
Posts: 13
The main advantage is that Agile Teams are always open for changes.

Developing software is a learning process. The programmers have to learn about the business domain, the customers have to learn how the technology changes the workflows.

With traditional software engineering process the IT-Team gathers the requirements at the beginnig of the developement process. They are afraid if they miss one requirement, they won't get the best design. Traditional software engineering doesn't consider that learning process. They don't expect that the requirements will change over time.

Agile Teams, know that it is impossible to gather all requirements at the beginning. They try to write their software in such way, that it is always open for changes. They try to benifit from the learning process. They give the customer the chance to intervene in the developement process at every time of the developement process.

Agile teams are not such dependent on individual employee's like traditional teams. They don't seperate people in gathering requirements, design the software and testing. Every programmer is involved in testing (testing is part of programming), and is involved in understanding the business domain. The communication among the members of agile teams, and between the team and customer, is much higher as in traditional teams.

Agile teams hate solutions, that only a few people can understand and maintain - they try always to find the easiest design. The knowledge is not concentrated to only a few key-players. The iteration cycles are very short, a team member shows daily his work to his team. Often they do their work in pairs, and change their pair partner frequently. If one team member has difficulties doing his work, the team realizes it very soon and can help him. Because agile teams works very tightly together, beginners will learn very quick from experience people.

Please excuse my English. It is not easy to learn it.
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
Originally posted by Klaus Meucht:
The main advantage is that Agile Teams are always open for changes.

Developing software is a learning process. The programmers have to learn about the business domain, the customers have to learn how the technology changes the workflows.

With traditional software engineering process the IT-Team gathers the requirements at the beginnig of the developement process. They are afraid if they miss one requirement, they won't get the best design. Traditional software engineering doesn't consider that learning process. They don't expect that the requirements will change over time.

Agile Teams, know that it is impossible to gather all requirements at the beginning. They try to write their software in such way, that it is always open for changes. They try to benifit from the learning process. They give the customer the chance to intervene in the developement process at every time of the developement process.

Agile teams are not such dependent on individual employee's like traditional teams. They don't seperate people in gathering requirements, design the software and testing. Every programmer is involved in testing (testing is part of programming), and is involved in understanding the business domain. The communication among the members of agile teams, and between the team and customer, is much higher as in traditional teams.

Agile teams hate solutions, that only a few people can understand and maintain - they try always to find the easiest design. The knowledge is not concentrated to only a few key-players. The iteration cycles are very short, a team member shows daily his work to his team. Often they do their work in pairs, and change their pair partner frequently. If one team member has difficulties doing his work, the team realizes it very soon and can help him. Because agile teams works very tightly together, beginners will learn very quick from experience people.

Please excuse my English. It is not easy to learn it.


Very good explaination Klaus. Your English is perfect.
Klaus Meucht
Greenhorn

Joined: Jul 24, 2004
Posts: 13
I think the word deadline is not used by an Agile Team. Agile Teams don't plan for month's. They try to make the release cycle very short. And every release must have value for the customer.

In traditional software developers, the amount of features to implement for a release is defined, and the team try to implement this features as fast as possible. If the developement team is slower as expected they will deliver the software later.

For Agile teams the iteration cycle of a release is constant. An Agile team will always deliver the software on time. If the developement team is slower as expected, they will implement less features. Agile Teams avoid working for months, without feedback from the customer. It's not like christmas, when the child wrapp off all his presents at one time point. The child get every month a little present. The parents can watch the child, if it really uses the present. If not the parent can learn from it, and buy a better one next month.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I see the Agile advantages as few, simple and profound.

Agile stuff focuses on delivering working software. A rigid waterfall process might deliver use cases for a month, design docs for another month, test cases for a few weeks, then maybe some framework components, then a business case that runs.

In contrast, Agile gives you finished parts of the system early and often. This is the best possible feedback for everyone interested in the project. Users can see whether the developers understood the requirements, managers can see the pace of progress, everybody gets the psychological benefit of good work completed.

If you do it well enough, any iteration can ship to production users. Why not install as soon as using the system is better than not using it?

Agile stuff avoids investing time and effort in features beyond the immediate horizon. If you drop or change a subsection of a major system in a waterfall process you might throw out hundreds of pages of requirements and designs, spend a week reworking an MS Project plan and find complex parts of your framework never used. If you drop the same function from iteration current+2 in an agile project, you throw away a few story cards and keep on truckin.

Iteration planning invites (requires) the customer to prioritize features at a fine grained level. With waterfall our team usually assigned one developer a use case and they built every single requirement in it before they went to the next use case. The 80/20 rule suggests the customer gets 80% of the value from the first 20% of the features. Management tracked progress by use case and could not bear to see one of them left at 20% done. Story driven planning encouraged us to put the most valuable 20% of the whole system early in the project. Some of the rest fell completely off the table and will never be done.

So the advantages I think about most ...

* Real business value - deliver working software early & often
* Better visibility - the pace of delivering software is clear
* Rapid feedback after every iteration, not after release
* Changing anything about the future costs less
* Fine grained prioritization - avoid delays for gold plating

There are a lot of other great things going on in agile projects. Self forming teams, pair programming, test driven development, etc. I'm sure Ilja and the other regular practitioners can add more. These are just a few that I see our business customers caring about. YMMV.


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
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
From a business perspective, I think the following are advantages of Agile approaches:

better ROI

Agile teams work hard on always having a running, tested, deployable system with the highest priorities features from early on. Being able to put a system into production earlier increases return of investment.

decreased risk

Showing a running, usable system to the users early on gives you early feedback on whether you are actually building the right system.

high flexibility

An Agile team is prepared to change direction on the spot. So when new opportunities arise, the team can react very quickly and leverage it.

protection of investment

An Agile team works in a way that it can hold its development velocity indefinitely. It doesn't produce "legacy code" that after some while cannot reasonably be maintained or extended anymore.


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
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
Excellent. I find those very compatible and more focused on what customers think about for the long term. I'm going to keep this list.

I'm interested that nobody has suggested that large projects get done sooner or that agile is somehow faster. I'm not sure it is. Agile has more people working on software more of the time, fewer people working on things that don't create software, but Agile often has pair programming and the expectation or acceptance of some rework and refactoring to meet emerging requirements. Ilja, say I have a relatively stable set of requirements specified by new regulations. Would you promote Agile to me for getting done sooner?

On the other hand, the time to turn one idea into software can be very short if you prioritize it into the next iteration or so. Kent Beck writes about web shops with one day turnaround on high priority ideas. If you do it right you can surely get a valuable amount of usable stuff done sooner than a waterfall would get everything done.
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
I forgot one important point: high transparency

Have you ever heard of a project *always* being 80% done? Simply doesn't happen with Agile projects. Agile projects measure progress solely based on finished, running, tested features. From week one you know how fast your team *really* is, which actually allows you to actively *manage* the project.

Originally posted by Stan James:
I'm interested that nobody has suggested that large projects get done sooner or that agile is somehow faster. I'm not sure it is.


A lot of teams report something like doubled efficiency after adopting an Agile approach. I'd assume that reasons are reduced waste and improved morale. But it's not easy to attribute that effect to the adoption of Agile methods.

Agile often has pair programming and the expectation or acceptance of some rework and refactoring to meet emerging requirements.


Well, when transporting heavy furniture, whom would you expect to be faster: two people working together on one furniture at a time, or two people working in parallel?

And traditional approaches too have a lot of rework - in the form of debugging, which is very much reduced by the application of Agile practices.


Ilja, say I have a relatively stable set of requirements specified by new regulations. Would you promote Agile to me for getting done sooner?


Not necessarily for getting done sooner, but for other reasons. Are you sure everyone understands the requirements the same way? Do you expect to learn anything about how to implement the system while doing it? Can you put a partial system into production to get earlier return of investment? Do you need to know how long the project really will take?
 
GeeCON Prague 2014
 
subject: what is advantage agile over other methods