Developer using Agile

[original PM]

Your experience says more about the kind of places you work than Agile IMO The places I've seen it used well have all been young enthusiastic teams.

Indeed - the main challenge I have is that some of the more mature developers come from a background where you would not code until you had all requirments and it was expected that anything which was coded would be used.

Not sure if this was due to constraints of the way coding was done back in the day or what.

But nowadays younger developers are much happier to knock some code up and then bin it and start again.

[doodab]

Indeed - the main challenge I have is that some of the more mature developers come from a background where you would not code until you had all requirments and it was expected that anything which was coded would be used.

Not sure if this was due to constraints of the way coding was done back in the day or what.

There was a time (before my time) before timesharing systems with online compilers and such when it was awfully expensive to code up anything that wasn't complete or that you wouldn't use. A lot of people who started out in that world that carried mindset over long after modern tools tipped the balance in favour of frequent build and test.

But nowadays younger developers are much happier to knock some code up and then bin it and start again.

I would say that I, and the home computer generation in general, grew up on systems where writing something, running it, tweaking it and repeating the cycle were the way things were done. An online interpreter encourages that sort of thinking. A lot of modern development practice is a scaled up manifestation of that iterative process.

[minestrone]

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.

[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

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

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.

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

[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'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?

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