Explicit Agile Requirements Definition

[suityou01]

I've said it before and I will no doubt say it again but

Agile development methods and offshore development teams are the worst possible combination.

If you are going to use an offshore development team then the specs do need to be like legal documents.

Agile approaches can work but you need the constant input of the business that you are developing for and developers that can appreciate what the software is intended to achieve so that the software can be continually adjusted.

I sometimes wonder if the reason that developers are so enthusiastic about Agile approaches because it means their jobs are less likely to go offshore ...

Thanks Gonzo, that's a good measured response. And I'm not suprised.
I heard that thoughtworks produced an article about distributed agile development and basically the premise was that it can work providing :

You don't have all your testing resource in one place
You allow each distributed development team to specialise in one area alone
You have regular flights and "face to face" sessions



So basically agile and off shoring do not mix well.

[Gonzo]

Got an off shore development firm. They are ok, but under estimate and like to try and blame the BA a lot. My predecessor produced a requirements spec and they didn't like it. Too ambiguous. I re-worked it and tightened it up. They said it read like a legal contract.

Anywho, they came back this week with "the spec doesn't say xyz so we didn't do it" type crap. I handled it beautifully by also pointing out that the "short circuited" behaviour they delivered was not mentioned in the spec either and that no spec is perfect and they needed to apply some analysis to what they are doing.

All good fun but I think they won't try that on again in a hurry.

While the spec I am currently working on is in flux because the business keep changing their minds. I asked for a requirements freeze on 2/12 and they are still changing their minds. I am capturing their new requirements for the next release but they are insisting this functionality is critical. They won't slip the deadline and to be honest the whole thing has hit the buffers.

What made me chuckle was that the PM stated that requirements need to "explicit", but as soon as I start asking for more time he suggests trying a "more agile approach to requirements definitions"

Then this set me thinking. Is there a way to define "explicit" and yet agile requirements definitions?

On the one hand explicit req defs are the kind of F-Spec > T-Spec > Code monkey route and on the other Agile req defs imply more senior level developers are in the mix and can run with less explicit and more tacit statements.

I've said it before and I will no doubt say it again but

Agile development methods and offshore development teams are the worst possible combination.

If you are going to use an offshore development team then the specs do need to be like legal documents.

Agile approaches can work but you need the constant input of the business that you are developing for and developers that can appreciate what the software is intended to achieve so that the software can be continually adjusted.

I sometimes wonder if the reason that developers are so enthusiastic about Agile approaches because it means their jobs are less likely to go offshore ...

[suityou01]

Got an off shore development firm. They are ok, but under estimate and like to try and blame the BA a lot. My predecessor produced a requirements spec and they didn't like it. Too ambiguous. I re-worked it and tightened it up. They said it read like a legal contract.

Anywho, they came back this week with "the spec doesn't say xyz so we didn't do it" type crap. I handled it beautifully by also pointing out that the "short circuited" behaviour they delivered was not mentioned in the spec either and that no spec is perfect and they needed to apply some analysis to what they are doing.

All good fun but I think they won't try that on again in a hurry.

While the spec I am currently working on is in flux because the business keep changing their minds. I asked for a requirements freeze on 2/12 and they are still changing their minds. I am capturing their new requirements for the next release but they are insisting this functionality is critical. They won't slip the deadline and to be honest the whole thing has hit the buffers.

What made me chuckle was that the PM stated that requirements need to "explicit", but as soon as I start asking for more time he suggests trying a "more agile approach to requirements definitions"

Then this set me thinking. Is there a way to define "explicit" and yet agile requirements definitions?

On the one hand explicit req defs are the kind of F-Spec > T-Spec > Code monkey route and on the other Agile req defs imply more senior level developers are in the mix and can run with less explicit and more tacit statements.