Youch! Just before Christmas I posted an article on Agile Development on CIO Online. There’s nothing like constructive feedback, they say, and this was indeed nothing like constructive feedback… so anyway. I collated a set of responses and found I had written too much for the CIO Online comments field, so I have posted my responses here.
Here we go.
My goal in this article was to distil the content of a research report in a way that would be usable at CIO level. For your information, I was trained in DSDM and worked as a software development consultant for a number of years before becoming an analyst. Indeed, given the amount of time I have spent trying to convince more traditional developers of the merits of non-structured approaches, I am very interested to experience what happens when one dares to suggest that Agile might not be the ultimate answer. I hope that helps set the context.
Thank you for your comments – let’s work through them. As a first point however, I hope nobody has an issue with the main thrust of the article, as stated in the conclusion: that while there is a place for Agile approaches, they should not be attempted without due care. To try to suggest to CIOs (or anyone else) that things are otherwise would be irresponsible in the extreme. Do feel free to try to catch me out on the rhetoric, but please do not lets obscure this, most important point.
@Mike – I am delighted for you. There is no doubt that Agile can add a great deal of value if things are done right. I would be interested to know what level of consulting, mentoring etc was required, and how the 11 years panned out – was it forming, storming, norming, performing for you? Apologies for the sprints/scrums slip of the pen. But I don’t “fail to see” anything – rather, we have been advised by people who have had difficulties on Agile projects, that the shorter timescales can make things harder, as documented in the report.
@Agile Dude – I’m using Agile as a word for the same reason this does. I have spent many years watching in-fighting between methodologists, indeed, I would think it would be fair to say that the U in UML, once derived, meant that people needed something new to fight about. I mention some experience above which, while not as comprehensive as many people I know, and plenty I don’t, puts me in a better position than many of my analyst peers. Your mileage may differ but I suggest that you talk to me first before drawing any conclusions about competence or otherwise from a single article.
Finally, and sadly to your point, we don’t offer any services in this space. I’m not worried about a backlash as much as I am worried about “experts” trying to suggest that Agile is an easy ride.
@Ilja Preuss – good point. But it requires strong managers, and not the types who think rebaselining is a project management technique :). As stated in the article, the key factor is to impose a suitable level of structure – whether agile or otherwise, this will win over (let’s call them) anarchic approaches. With regard to communications, indeed, this will be a factor but the continuous development/integration involved in Agile requires this communication more actively than does the gating/reviewing involved in (say) waterfall. It’s not me saying this but the audience we researched.
@Dave Rooney – It’s a fair cop isn’t it! Indeed, when I was running the software development environment for an out-of-control software project (which led me to write the article Craft or Science? Software Engineering Evolution back in 1994) I was led think that if only I could have taken a dozen of the bright sparks involved in the project and locked them in a side room somewhere, they might have been able to deliver something faster than the hundreds involved in the ‘main’ project. You point is “divide and conquer” which I think is totally valid.
Less valid is the remark “you would have done your research” unfortunately. I could answer, “If you had done yours you would have discovered bla bla bla…” but I will resist the cheap shot 🙂 Seriously, I’m very happy that there are good experiences of Agile out there. I don’t say Agile isn’t suitable for large projects, the people we researched did say it gets harder to get right for larger projects. This might be obvious to you, but that’s another way of saying it’s fundamental, and this won’t be obvious to everyone.
@Mark Levison – did you read the report itself, or take a look at the materials from which it was derived? If so I’m not sure I understand your use of the term “back yard”.
@Alistair Cockburn – shame on you for suggesting I twisted the results of my own research report, particularly given that the citations you draw from the report are indeed summarised in the article. I suggest you re-read the article and the report, and tell the CIO Online audience where exactly the article denies that Agile approaches are beneficial, and where exactly the research report disagrees that Agile should be treated with due care. I am embarrassed by your myopia, but equally, I do understand that it can be difficult to see beyond something you have been espousing so long, and generally so well. Frankly, if you had spoken directly to me we could have had a quiet discussion and most likely avoided this faux pas.
@Anil Oberai – Thanks for your considered response. I think key to what you are saying is that it is important to choose project stages and documents which will work best for your organisation. I have no problem with hybrid approaches, nor with the recognition that wholesale adoption is not always the wisest approach off the bat.
@George Dinwiddie – yeah, I’ll cop that one 🙂 but all the same, in my experience this one bears out – that people want to stick with the monolithic, or reach out towards a ‘brave new world’. There doesn’t seem to be much middle ground – but I believe there should be!
@Agile/XP Coach – God forbid I should ever take advice from you. No wonder you keep anonymous.
@Grant (PG) Rule – There was some good information garnered in the research about what metrics are seen as appropriate – and you are absolutely right that few saw resource consumption as a valid metric. I’m a bit wary of metrics for a number of reasons – not least that very few places I have seen have tended to implement them in a way that would satisfy their advocates. Which leads me with two questions – are such metrics a valid pre-requisite to project success, and if so, what is the relationship between having the right metrics implemented, and the delivery of project value? When I was a real developer, the metrics that seemed to make the most sense were those that were outcome-based, for example the number of problems fixed; however, artefact-based metrics (number of use cases, test scripts etc) have not always been quite so successful. This is not an area we have researched significantly, so I would be very interested in any steers you might have.