We also always start a project with a facilitated workshop wherever possible, and of course do some estimation from that. But I don’t see how you can call a project “agile” if it’s done on the basis of requirements and estimates based on a single up-front workshop. I’ve always considered the FP approach pretty much antithetical to agile. In an agile project, requirements change, hence the FP count changes. Are you saying you used the up-front FP count as a benchmark, or that the changes were small enough not to impact it?

On Paul’s point, there’s no denying that a reluctance to do documentation is built in to agile (it’s in the manifesto after all), and this is a problem. A lot of less experienced practitioners seem to think there’s no need to worry about maintainability, but it’s no use “valuing individuals and interactions over processes” if the individuals who had the interactions have left the company.

My experience was working for a project contract house from 1997-2006. In 1999-2001, we set up a half-dozen projects using a plan-up-front, fixed-fee strategy. Most of them ended up under water, often badly.

Having barely survived that ordeal, our group director told me we needed a “failure-proof methodology.” I said there wasn’t such a thing, did a lot of thinking about the failures we had, and ended up with Agile, fronted with a Facilitated Requirements Workshop, and supported with metrics-based estimation using IFPUG Function Points (I owe Eva-Marie Postion of Siemens in 2003 for the idea of FRW+FP). We “flew it off the drawing board” with no gradual testing, and proceeded to have 12 “three-green” successes–happy customer, healthy team, profitable–out of 13, and the failure was really a breakdown in account/customer relationship management.

My analysis of that experience is summarized in the links I posted above, to which I would add http://www.ufunctional.com/2009/01/30/load-bearing-walls/.

I think what you’ve seen, Paul, is a common early-majority adoption of Agile, which without ruthless, daily attention to quality, isn’t Agile at all. All methodologies devolve. Agile devolves to what we used to call Cowboy Coding: http://www.ufunctional.com/2009/02/01/all-methodologies-devolve/.

Helpful?

Can you give an example because I’m struggling to be convinced.

Function Points and Agile Methods: http://www.ufunctional.com/2009/07/13/function-points-and-agile-methods-i-promise-i-wont-tell/

Diminishing Returns: http://www.ufunctional.com/2009/02/06/diminishing-returns-a-key-agile-principle/

6’40” Pecha Kucha talk: http://www.youtube.com/watch?v=KZOQ3wpQYuM