Developer using Agile

[SpontaneousOrder]

I see all this agile stuff as a means to handle poorly requested software. Ultimately agile is about releasing the build team from blame when changes are made.

You just want it all 100% specced off the bat so that you can code it all up in one single giant public method

[d000hg]

I see all this agile stuff as a means to handle poorly requested software.

Ultimately most companies who want software written and are not software companies, don't know how to figure out exactly what they want or to specify it if they did. I think trying to require such clients to submit (or sign off on) a monolithic design document is a bit daft because you know better than they do it will NOT be what they wanted, regardless if they signed for it.

I mean going that route they end up hiring Suity who promptly spends all their budget on requirements workshops and there's none left for developers.

[doodab]

Ultimately most companies who want software written and are not software companies, don't know how to figure out exactly what they want or to specify it if they did.

A lot of them struggle to buy off the shelf packages that do what they want, never mind manage bespoke development in house. This is why a lot of outsourcing deals go sour as well I reckon, they don't actually understand what they are buying or why.

[SpontaneousOrder]

Ultimately most companies who want software written and are not software companies, don't know how to figure out exactly what they want or to specify it if they did. I think trying to require such clients to submit (or sign off on) a monolithic design document is a bit daft because you know better than they do it will NOT be what they wanted, regardless if they signed for it.

I mean going that route they end up hiring Suity who promptly spends all their budget on requirements workshops and there's none left for developers.

Plus unless you're building a noddy system in a few months, it's quite possible that the market will be moving al the time you're developing. There's not much point fully speccing a system that will be redundant by the time it's delivered in 2 years.

[SpontaneousOrder]

Ultimately most companies who want software written and are not software companies, don't know how to figure out exactly what they want or to specify it if they did. I think trying to require such clients to submit (or sign off on) a monolithic design document is a bit daft because you know better than they do it will NOT be what they wanted, regardless if they signed for it.

I mean going that route they end up hiring Suity who promptly spends all their budget on requirements workshops and there's none left for developers.

I forgot... agility also means the agility to fail fast.
Failing fast is failing cheap.

[woohoo]

There's not much point fully speccing a system that will be redundant by the time it's delivered in 2 years.

I've always found that putting as much thinking up front as possible makes the whole process run more smoothly. Though I've never planned and delivered a two year project in one go, usually split it into phases that may take 2 years.

[original PM]

Ultimately most companies who want software written and are not software companies, don't know how to figure out exactly what they want or to specify it if they did. I think trying to require such clients to submit (or sign off on) a monolithic design document is a bit daft because you know better than they do it will NOT be what they wanted, regardless if they signed for it.

I mean going that route they end up hiring Suity who promptly spends all their budget on requirements workshops and there's none left for developers.

Indeed current project has over 400 requirements - there is simple no way that the first code drop (which meets all the requirments) will be fit for purpose as an actual usable system.

I've always found that putting as much thinking up front as possible makes the whole process run more smoothly. Though I've never planned and delivered a two year project in one go, usually split it into phases that may take 2 years.

Yes and nothing wrong with that - however the key here is that eveyone goes into the build knowing the first code drop is a beta and will change.

[SpontaneousOrder]

I've always found that putting as much thinking up front as possible makes the whole process run more smoothly. Though I've never planned and delivered a two year project in one go, usually split it into phases that may take 2 years.

Sure. The two aren't mutually exclusive. You just try to commit as late as possible.

An agile process of building prototypes with mocked out integrations etc can help.
I.e instead of getting a couple of BAs to write a hefty tome, and them locking away. Load of guys to a design for months, before anything tangible is seen, knocking up prototypes and getting feedback might help get the spec right in the first place.
Then let's say we're happy with the UX, we can start developing that while the data model is still being ironed out- reducing time to market.

A big mistake I see guys doing is thinking that delivering business value to the customer each iteration means delivering production quality deployable product each time. Half of the point of agile is to be able to layer on additional functionality at later stages. So the data model isn't decided yet? Who cares?! Delivering a UI with hard coded data backing it up is still delivering business value, because the customer gets to play with their new toy and make any tweaks as far as the UI is concerned.