Reply to: Developer using Agile

[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.

[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.

[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.

[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.

[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.

[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.

[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.

[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

[jmo21]

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.

If someone designed a hotel and pretty much everything in the place got changed at build time they would not get to design a second hotel. Designing in a process that deals with change is expensive and unnecessary and would not be tolerated in other sectors.

We should just sack people who request work that gets binned or is not fit for purpose.

This. It gets the "business owner" to be more committed (in theory) and involved on a sprint to sprint basis, constantly evaluating the pile of requirements and getting a feel for the software as it progresses.

[original PM]

I've always tried to get as much of the requirements up front as possible, I then mock up a system (screenshots) or do a prototype to show the customer. Then I agree with the customer points in the project plan where I will demo the system to them. If the demo results in major changes then timescales etc have to change.

The challenge is often getting the right people to the demo, it's surprising how often the people that will actually use the system are not included in the process.

Cannot agree more with that - execs are normally only interested in the financial impact - so the new systems meets all of the execs requirments but any financial benefits are completely eclipsed by the extra overheads of having to train and deploy brand new systems/interface.

Also is it only me that finds execs think that training/documentation/a decent UI etc etc will 'just happen' as an outcome of the project?

[woohoo]

The main challenge I find is that you can gather as many requirements as you want but until you put the new system in front of the users you will not get any decent useability feedback.

So you could test the system and you can sign it off as having the required functionality but if the user journey is so convulted as to render the system unusable then re-work is needed.

However if you only put the system infront of the user at the end of the build you could find that the whole thing needs to be ripped apart where as if you had planned the user journeys earlier on and been able to show a beta you could have caught the problems.

However there still should be a high level costs/ benefits analysis which would tell people to p*ss off way before they got near any development.

I've always tried to get as much of the requirements up front as possible, I then mock up a system (screenshots) or do a prototype to show the customer. Then I agree with the customer points in the project plan where I will demo the system to them. If the demo results in major changes then timescales etc have to change.

The challenge is often getting the right people to the demo, it's surprising how often the people that will actually use the system are not included in the process.

[original PM]

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.

If someone designed a hotel and pretty much everything in the place got changed at build time they would not get to design a second hotel. Designing in a process that deals with change is expensive and unnecessary and would not be tolerated in other sectors.

We should just sack people who request work that gets binned or is not fit for purpose.

The main challenge I find is that you can gather as many requirements as you want but until you put the new system in front of the users you will not get any decent useability feedback.

So you could test the system and you can sign it off as having the required functionality but if the user journey is so convulted as to render the system unusable then re-work is needed.

However if you only put the system infront of the user at the end of the build you could find that the whole thing needs to be ripped apart where as if you had planned the user journeys earlier on and been able to show a beta you could have caught the problems.

However there still should be a high level costs/ benefits analysis which would tell people to p*ss off way before they got near any development.

[doodab]

The best software gets written by independent houses that have the power to say 'fook off' to the ridiculous. That is a better model.

Indeed. They have the benefit of more than one customer which helps somewhat with defining priorities.

[minestrone]

True, but in many places I work it seems that any fecker on the business side can demand new functionality after 1 day on the job. The subservient and performance pay driven technical analysts jump at any request as a chance to raise their profile so the most ludicrous requests get made and dev end up having to fulfil them.

That whole model is broken, Agile does nothing but work around the problem.

The best software gets written by independent houses that have the power to say 'fook off' to the ridiculous. That is a better model.

[doodab]

We should just sack people who request work that gets binned or is not fit for purpose.

If we did that there would be no customers left