Understanding Agile

Question

Hi,

I recently shifted to a new organization that follow Agile mode of development. The current project we are working has stalled due to many requirement changes that were reported recently. Since this is my first Agile assignment (after working in 4 years in non-agile environ), its a bit hard to differentiate where the problem really is.

Ruby on Rails is the platform that is being used for development. Since I can't ask a vague question, I will narrow it to this.

In agile, is it ok for the business team to relax and give requirements at will? (Some requirements given during the final sprints were altering the entire design of our app)

Or, its the development team's mistake not foreseeing the numerous possibilities of the application and not having a concrete design that could have welcomed abnormal changes?

Answer 1

Agile doesn't mean you don't have requirements or specifications or you can be free and easy with them. The business leads need to know what they want. The benefits of being agile is that if you do need to change paths, you can do that in an easier way, so you can adapt quickly.

Requirements changing will be painful no matter what your development methodology. There still has to be a strong clear plan, at least at that point in time.

Answer 2

In agile, is it ok for the business team to relax and give requirements at will? (Some requirements given during the final sprints were altering the entire design of our app)

It is OK (albeit not wise ;-)... so then an agile development team would tell them "fine guys, this would cost this amount of extra time and consequently this much schedule slippage."

• If they are willing to pay the price, all's well.
• If they decide that maybe the new feature is not that urgent after all, all is well too.
• If they insist on including the new requirements and keeping the original schedule, that project is not agile :-(

Or, its the development team's mistake not foreseeing the numerous possibilities of the application and not having a concrete design that could have welcomed abnormal changes?

I don't think the design should be ready to welcome any kind of changes and any new features - that would only lead to bloatware, and a lot of extra work which in the end proves useless.

Agile projects should have some sort of roadmap too, so that the developers have at least a rough idea where the product is supposed to be in a year's time etc. This would allow them to plan forward and extend the design to make room for probable future changes.

If business doesn't give timely information about the roadmap (or if it proves unreliable), that is (usually - barring really unforeseen market/environment changes) business' fault. If the team did not use that info wisely, it's their fault.

Answer 3

Agile projects are supposed to have requirements gathering, design, analysis, coding, testing; just like the waterfall development model. However, in an agile project, the phases are supposed to cover less ground and therefore, happen faster.

I agree with Péter Török's answer, but its also the responsibility of the agile team or the agile team manager to teach the business team that the project will deliver better results each round if they postpone new requirements until the next requirements phase. Since a round is supposed to be 30 - 90 days, most new requirements can wait. The few requirements that can't wait, need to have a time and schedule cost.