C# course

[oscarose]

I've worked on way more traditional waterfall driven projects that have been badly project managed and had the exact same scope creep issues.

In situations where the requirements cannot be nailed down 100%, this is EXACTLY when Agile is very good at dealing with things like scope creep.

The "thing" that creeps into scope after the start might be entirely valid. It might be more important than something else. So instead of, with waterfall, telling the customer they'll need to wait til phase 2 or having he project run past the nd date, you can prioritise the new thing at the expense of the other.

Now if you can't drop the other thing then you'll end up going past the end date anyway, but Agile can help you manage the fluidity of requirements very well.

To put the record straight I'm not against agile and we all know the issues with traditional methodologies.

However your point illustrates very well a risk with agile projects. We agree that requirements aren't fully defined before development starts. In your example, after development has started the customer realises they have overlooked a key requirement(s) and whilst you state this can be prioritised at the expense of another, in reality this is never that straightforward and the project can become a runaway train or diluted e.g. the missed key requirement(s) grab a large chunk of development time or even worse not identified, so a solution is delivered not fit for purpose and back to the drawing board and already over budget.

Hence, the value of the business analyst to extract the key information from the customer asap not half way through development.

Apologies to the OP if this thread has gone slightly off track.

[jmo21]

To put the record straight I'm not against agile and we all know the issues with traditional methodologies.

However your point illustrates very well a risk with agile projects. We agree that requirements aren't fully defined before development starts. In your example, after development has started the customer realises they have overlooked a key requirement(s) and whilst you state this can be prioritised at the expense of another, in reality this is never that straightforward and the project can become a runaway train or diluted e.g. the missed key requirement(s) grab a large chunk of development time or even worse not identified, so a solution is delivered not fit for purpose and back to the drawing board and already over budget.

Hence, the value of the business analyst to extract the key information from the customer asap not half way through development.

Apologies to the OP if this thread has gone slightly off track.

Lol, yeah apologies too.

We are in agreement then!

[russell]

Lol, yeah apologies too.

We are in agreement then!

There are various good software development methodologies that work well, the real problem is the people trying to execute them are usually incompetent fools (i.e. managers).