Agile

[SueEllen]

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

Not in the organisations I've done worked for. The teams have varied as some people have more than one role. Effective teams have never more than 10 core people or pigs.

[VectraMan]

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.

That's fair enough, but managers ought to understand the psychology of the people they're managing. Good developers who care about what they're doing soon lose motivation when they're constantly having their time wasted. After a while you find yourself saying "I'll get right on that", and go away and read CUK for an afternoon whilst half-heartedly updating your CV.

[original PM]

Not in the organisations I've done worked for. The teams have varied as some people have more than one role. Effective teams have never more than 10 core people or pigs.

Sorry yes I agree on that - it was the figure of about 10 wish people working on it full time I was trying to point out.

Not 100!!

[original PM]

That's fair enough, but managers ought to understand the psychology of the people they're managing. Good developers who care about what they're doing soon lose motivation when they're constantly having their time wasted. After a while you find yourself saying "I'll get right on that", and go away and read CUK for an afternoon whilst half-heartedly updating your CV.

I do agree with you - but in an agile environment you do not have managers

You have people that do things

[SueEllen]

I do agree with you - but in an agile environment you do not have managers

You have people that do things

You can have managers but they know their role is to facilitate the team e.g. do all the boring stuff, keep interfering busy bodies away, yell at 3rd party suppliers.

[eek]

I do agree with you - but in an agile environment you do not have managers

You have people that do things

And someone to facilitate the team so that they can work without distractions.

That means kicking everything none essential away and ensuring things are there when they need to be.

[tomtomagain]

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.

Of course. You can ask people to dig a hole and then fill it in again. You can ask them a few times. But don't be surprised when they start dragging their heels, answering back, and becoming demotivated.

The project-of-doom I was referring back to had 12 developers, it wasn't a case of code on Monday, throw away on Friday. It was code against spec today, throw away in 35 days time.

That's 35 x 12 man days of effort. If I remember my rate back then I think that it equates to about £140k of wasted costs.

It wasn't that anyone was particularly stupid or obstructive. Indeed there were smart, motivated people at all levels of the organisation. But it was how it was done.

In the Pre-Agile days projects "Waterfall" was best practice. It went roughly like this : Spend 3 months gathering the requirements. Spend another 3 months creating a "FUNCTIONAL SPECIFICATION", spend another 3 months creating a DETAILED DESIGN, spend 3 months writing code to the DETAILED DESIGN, spend 3 months fixing the bugs. Now show it to the users. What?? It's not what they want??? But they signed-off on the FUNCTIONAL SPECIFICATION 12 months ago.

Agile was born out of repeated large IT project failures.

But before Agile came "Rapid Application Development". That basically involved getting the smartest developer in the team to build a quick version in Excel and VBA. That got some good results .... but of course had it's own problems. But that's another story.

[FatLazyContractor]

[NickFitz]

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.

But that's a completely different thing to being told right now that you have to keep writing code in the certain knowledge that it will be thrown away several months down the line once the changes have been approved, which is the situation described there.

Agile specifically involves throwing stuff away, and no agile developer is going to get precious about it. You implement features, and you quite often identify that they don't properly meet user requirements. So you keep the bits that are still of value, chuck away the rest, and do what it turns out is really required. The point is that you found the problem and addressed it at the cost of a bit of work that was done in a couple of weeks.

Agile is (in part) about taking Brook's adage "Build one to throw away; you will anyway" and applying it at an extremely granular level. All the analysis in the world can't prevent the building of things that aren't really what's needed, because the users don't know exactly what they want until they sit down and try to use something which they thought was what they wanted until they got it.

And there will be other features in the same release that are OK, so you still have a working product that meets some of the requirements. This is the thing that's almost never done: making sure that, at the end of every sprint, you have something that could, if the plug was pulled right then, be released as it is and provide some value to the users, even though it doesn't do everything they'd like.

[minestrone]

As a graduate of a 'real' engineering degree I find the industry acceptance that specification can be changed at any point and that work casually thrown away truly shows the immaturity of the discipline.

We are meant to be in a creative manufacturing profession, not building a villa in Marbella on the cheap.