Agile

[NigelJK]

Yep I distinctly remember the morning scrum where the product owner insisted that the graphic placement of the carousel (5px out) was more important to fix than the fact that the product search was returning incorrect results.

[tomtomagain]

So if you are not doing Agile what are you doing?

I remember back in the 1990's coding away on a big project as a junior developer, which had a big detailed design spec, all signed off and everything.

As I was developing a function I realised : "Hang on, this is wrong, it doesn't work as the customer wants it to".

When I raised it with the Team Lead I was basically told : "You're just the programmer. Just code it to the specification".

So away I went, tail between my legs, and carried on coding what I new to be wrong.

A few weeks later everybody in the development team has got some serious problems with the spec. None of the team, including the Team Lead, now have any trust in the specification. However because this is a waterfall project, "done right", we the development team, have no authority to change it.

To change the spec a review board needs to be held, the change has to be discussed, the change has to be re-analysed, the change has to be approved.

During the 6 weeks it takes to do this the development team are expected to continue coding to the current design. This is very demotivating. Spending 8 hours a day, writing stuff you know is not what is needed. So of course the quality and productivity across the team drops dramatically.

The spec comes back changed. We have a brief upswing of enthusiasm, but of course now the damage is done. Nobody trusts the analysts, the business requirements or the management. And so the project begins it's death spiral. In the end nothing is delivered, it is chalked up as another IT failure at a cost of a couple million quid.


And that is why I started getting into XP in early 2000. Because while it is by no means perfect, certainly does not fit every organisation, project or culture, it's a damn sight more reliable than what went before.

[d000hg]

Seriously does it work for you?

Sure. I get on with my work in an agile way and ignore what everyone else is doing.

[eek]

Yep I distinctly remember the morning scrum where the product owner insisted that the graphic placement of the carousel (5px out) was more important to fix than the fact that the product search was returning incorrect results.

You're missing a bit there. The question is which browser is it wrong in.

I remember a similar conversation where it was if you use this browser (opera) and this operating system it doesn't work. It was only important in that that was what The produce owner used. He didn't comprehend that if 99.9% were happy I didn't care about him and his 0.0001%

[Cirrus]

Never Trust a Person Who Offers You a Burn-Down Template.

Unfortunately I've been involved in two largish (50-100 people) 'agile' projects recently and it's just waterfall with more graphs, more plans. You have to say 'sprint' for a piece of work and you have to say 'user story' or 'epic' for a requirement and so on and so on. There's nothing agile about it - "You must hand in your user stories for the sprint two weeks before the start of the sprint". It is bloated and stuffed with expensive outside consultants. The best agile is done in strict waterfall outfits like banks. Waterfall patently doesn't work (see previous posts) so people honour it in the breach. Agile projects called 'agile' can't get away with turning a blind eye to bureaucratic nonsense because of the intense religiosity of these groups. So when you say 'agile' you can be talking about entirely different things.

[VectraMan]

So if you are not doing Agile what are you doing?

...

WHS.

I was doing Agile long before it was invented. I didn't know I was; I thought I was applying common sense, but I know now that's what it was. It only doesn't work for you if you're one of those people looking to get a 12 month contract out of a few weeks work.

[LondonManc]

You must be great fun at parties.

You're a strange creature, of that there's no doubt.

I'm passionate about my work and generally enjoy what I do.

However, I don't let it overspill into parties because it's no doubt dull as f**k to people not in the industry, just like their work probably is to me unless they're a condom sensitivity tester.

[minestrone]

Most of the tulip it just invented so that training companies can fill up courses with dull gullible feckers who can't manage a group todo list.

[SueEllen]

Unfortunately I've been involved in two largish (50-100 people) 'agile' projects recently and it's just waterfall with more graphs, more plans. You have to say 'sprint' for a piece of work and you have to say 'user story' or 'epic' for a requirement and so on and so on. There's nothing agile about it - "You must hand in your user stories for the sprint two weeks before the start of the sprint". It is bloated and stuffed with expensive outside consultants. The best agile is done in strict waterfall outfits like banks. Waterfall patently doesn't work (see previous posts) so people honour it in the breach. Agile projects called 'agile' can't get away with turning a blind eye to bureaucratic nonsense because of the intense religiosity of these groups. So when you say 'agile' you can be talking about entirely different things.

The number of people may be the problem there.

[original PM]

So if you are not doing Agile what are you doing?

SNIP

As I was developing a function I realised : "Hang on, this is wrong, it doesn't work as the customer wants it to".

When I raised it with the Team Lead I was basically told : "You're just the programmer. Just code it to the specification".

So away I went, tail between my legs, and carried on coding what I new to be wrong.

During the 6 weeks it takes to do this the development team are expected to continue coding to the current design. This is very demotivating. Spending 8 hours a day, writing stuff you know is not what is needed. So of course the quality and productivity across the team drops dramatically.

The spec comes back changed. We have a brief upswing of enthusiasm, but of course now the damage is done. Nobody trusts the analysts, the business requirements or the management. And so the project begins it's death spiral. In the end nothing is delivered, it is chalked up as another IT failure at a cost of a couple million quid.

Whilst I agree that developer input is important - sometimes developers need to understand they are there to create code - and if you start coding something on a Monday and get asked to rip it up and start it differently on the Friday then so be it - it is what you are paid for.

In much the same way as there will be a BA running round in the back ground constantly updating the requirements document.

The idea that you will only write code if it is going to be used is a bad place to come from.

The number of people may be the problem there.

Indeed - Agile should be approx

1 product owner
2 'digital' BA
3 SME's
6 developers one of which is a lead developer and responsible for setting up environments and all the NFR's the other 5 are coders and there to write code