wood burning stoves 2.0*
The moose likes Agile and Other Processes and the fly likes Agile(SCRUM/DSDM/XP) Vs Waterfall? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » Agile and Other Processes
Bookmark "Agile(SCRUM/DSDM/XP) Vs Waterfall?" Watch "Agile(SCRUM/DSDM/XP) Vs Waterfall?" New topic
Author

Agile(SCRUM/DSDM/XP) Vs Waterfall?

kri shan
Ranch Hand

Joined: Apr 08, 2004
Posts: 1371
Lots of confusion in process methodologies/patterns

Agile methodologies: (SCRUM/XP/DSDM) supports iteration planning and TDD(Test Driven Development) - First write unit test then write code.
Within agile itself SCRUM is different from XP. XP supports pair programming. Code review is on the fly(during coding) in XP. code review isn SCRUM, before end of iteration.

WaterFall: Everthing is upfront planning.

Some companies follows Agile + Waterfall: Whole project is divided into different phases/iterations(Agile approach).Then each phase/iteration implemented as waterfall model.

Which is best approach (Agile or waterfall or Agile+waterfall)?
Justin Rundle
Ranch Hand

Joined: Mar 26, 2008
Posts: 123

Hi Kri,

Which is best approach (Agile or waterfall or Agile+waterfall)?


Well this is open ended, but for me this depends on the struture of the development team and the nature of the project. For example if you have a distributed development where a few developers are assigned to local offices and other developers assigned to remote offices (client's premises) then I've found a Waterfall approach is best suited as there is less back and forth banter and all requirements are defined upfront. However Agile approaches provide higher productivity in terms of delivery of projects and Agile also supports the ability for clients to back changes to the requirements late within the development phase.

More so I have found Agile to be at best when developing an application that already exists and the constant enhancements and changes are made.
Akram Chotu
Ranch Hand

Joined: Apr 18, 2006
Posts: 43
More so I have found Agile to be at best when developing an application that already exists and the constant enhancements and changes are made


I have been given a new Offshore assignment where the client is US based and most of the requirements and activities flow from Onsite to Offshore and expectations from Offshore (for which I am team lead) is to implement change requests, bug fixes etc. for the "existing project". So as obvious thing is that we need to work in a Onsite-Offshore model where we will have phone calls with onsite for clarification on requirements and most of our Offshore time is spent in communication itself (like writing mails articulating our problems, issues, clarifications etc.; phone calls, micro managing Offshore team as a Team Lead etc.) and to overcome communication challenges in implementing the change requests and clarifications required from Onsite in fixing the bugs in the existing application. So in this kind of environment, what do suggest for Offshore team to be productive ? what software development methodology do you suggest for Offshore ? do you suggest Waterfall or Agile ? any other tips for Offshore team without slogging at Offshore or spending long hours working at Offshore ?
Mary Poppendieck
author
Ranch Hand

Joined: Oct 04, 2006
Posts: 62
I have been given a new Offshore assignment where the client is US based and most of the requirements and activities flow from Onsite to Offshore and expectations from Offshore (for which I am team lead) is to implement change requests, bug fixes etc. for the "existing project". So as obvious thing is that we need to work in a Onsite-Offshore model where we will have phone calls with onsite for clarification on requirements and most of our Offshore time is spent in communication itself (like writing mails articulating our problems, issues, clarifications etc.; phone calls, micro managing Offshore team as a Team Lead etc.) and to overcome communication challenges in implementing the change requests and clarifications required from Onsite in fixing the bugs in the existing application. So in this kind of environment, what do suggest for Offshore team to be productive ? what software development methodology do you suggest for Offshore ? do you suggest Waterfall or Agile ? any other tips for Offshore team without slogging at Offshore or spending long hours working at Offshore ?


Sounds to me like you have a problem that isn't going to be solved by a methodology. You seem to be sitting toward the end of a long and messy line of handovers.

You could - if you can get away with it - start by clarifying exactly what an acceptable request for your team's services looks like, and then work with the people supplying you with work to be sure that each request is clear, understandable, and actionable. Instead of clarifying the request, clarify what a clear request would look like, and insist that each request you get meets your needs.


Mary Poppendieck
Author of Lean Software Development, Implementing Lean Software Development, and Leading Lean Software Development
Jeanne Boyarsky
internet detective
Marshal

Joined: May 26, 2003
Posts: 30130
    
150

Akram Chotu wrote:I have been given a new Offshore assignment where the client is US based and most of the requirements and activities flow from Onsite to Offshore and expectations from Offshore (for which I am team lead) is to implement change requests, bug fixes etc. for the "existing project".

This was actually discussed at the local SPIN (software process improvement network) tonight. They measured scrum at both onsite and offshore as being most productive because it forced the US based team to really understand/describe the client's needs properly.

They also said that the offshore team doing waterfall was only productive if the rates were at 10% of onsite rates which was not the case.

All of this implies what Mary said of course - improving communication is the #1 thing to improve overall.


[Blog] [JavaRanch FAQ] [How To Ask Questions The Smart Way] [Book Promos]
Blogging on Certs: SCEA Part 1, Part 2 & 3, Core Spring 3, OCAJP, OCPJP beta, TOGAF part 1 and part 2
Akram Chotu
Ranch Hand

Joined: Apr 18, 2006
Posts: 43
Thank you Mary and Jeanne.

instead of clarifying the request, clarify what a clear request would look like, and insist that each request you get meets your needs


Mary, can you please explain if possible with an example
Rainer Eschen
author
Ranch Hand

Joined: Jan 24, 2009
Posts: 75
Mary suggests that you define criteria how a request "is written". Those criteria have to ensure that a request is understandable. You need rules that ensure that requests are written this way. So, you can reduce the amount of communication.


ICEfaces book . ICEcube . ICEfusion . Scrum
Mary Poppendieck
author
Ranch Hand

Joined: Oct 04, 2006
Posts: 62
Mary suggests that you define criteria how a request "is written". Those criteria have to ensure that a request is understandable. You need rules that ensure that requests are written this way. So, you can reduce the amount of communication.


Right. Some other group is handing off some information to you, and you are supposed to do something with it. What you are looking for is test-driven handovers. By this I mean that when someone hands something over to you, they know what they need to supply in order to make your part of the job possible. This is the "test" that the information must pass. If it doesn't pass the test, then you work with the other party to clarify what it is that you need from them to have actionable work requests. So instead of clarifying one instance of incomplete information coming to you, you clarify how information should look so as to be adequate.

As an example, Mike Cohn has a suggested format tor user stories. When stories are written in this format, teams generally find them actionable. If you get random or garbled information, then you would work with your information source to agree upon a format (maybe a user story format, a spreadsheet matrix, whatever) that will have the information you need to proceed. If you get a request in a random format, it fails the test, and you help your information supplier modify it to the agreed-upon format. At that point, you should have what you need to proceed. If not, maybe the format needs some improvement.

So the idea is not to fight fires every time you get confusing information, it's to create an environment in which fires are much less likely.
Akram Chotu
Ranch Hand

Joined: Apr 18, 2006
Posts: 43
Thank you Mary. That clarifies a lot.
lexica filozima
Greenhorn

Joined: Oct 08, 2010
Posts: 1
Really interesting discussion


Scrum Process
Sai Hegde
security forum advocate
Ranch Hand

Joined: Oct 26, 2010
Posts: 199
    
    1

I'd say all the insights were very helpful but then finally it's a way of work and sometimes preference.
Pradeep bhatt
Ranch Hand

Joined: Feb 27, 2002
Posts: 8904

one negative thing about agile was that new joinees take more time to ramp up as there are very littles docs available.


Groovy
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Agile(SCRUM/DSDM/XP) Vs Waterfall?
 
Similar Threads
Agile Vs XP
Possible Category and New Forum Changes
Difference between methodologies
what is agile?
What's the difference between ExtremePlanner & FileNet's Team Collaboration Manager?