Agile(SCRUM/DSDM/XP) Vs Waterfall?

[kri shan]

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]

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]

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]

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.

[Jeanne Boyarsky]

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.

[Akram Chotu]

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]

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.

[Mary Poppendieck]

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]

Thank you Mary. That clarifies a lot.

[lexica filozima]

Really interesting discussion

[Sai Hegde]

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

[Pradeep bhatt]

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