The ServerSide wrote an article, summarizing both mine and Venkat Subramaniam's talks at The ServerSide Symposium last week. It's a reasonable summary, with a few details left out (that's why it's a "summary").
But then, Cedric Beust takes the summary and constructs a agile development straw man to beat up. And, like many straw man arguments, he takes lots of stuff out of context and makes his own conclusions not supported by the original talk.
The first thing he gets wrong is the fault of the summary. Early in the talk, I clearly state that the best way to get good software is to interact directly with the users. And I give an example from my project history of the best project experience I every participated in, where the developers literally sat in the middle of the users. Every time we had a question, we just got up and resolved it directly with the users. It was project heaven.
But most corporate environments won't give you such direct access to the users, because the users are after all there to get work done. Thus, you must have user proxies. And that's where the business analysts come it. Perhaps at ThoughtWorks, our business analysts are different from the "typical" ones (I know our project managers are). The best business analysts are direct proxies for the users. They understand the users concerns and a little about technology. During the talk I also made the point that good business analysts prevent "paving the cowpath", suggesting innovative business solutions to problems rather than "that's the way we've always done it".
When I say that business analysts participate in the estimation process, that's because we can't get the users directly.
Do you know the difference between a good developer and a bad developer? A good developer can give you an estimate of the time needed to complete a task. And the better that developer is, the more accurate their estimate will be. If I ask a developer "How long is it going to take to do this?" and he answers with "It's very complicated", I want him off my team.
Another point I made in my talk is that, regardless of developer, you can't ask developers "how long will this take". Every project is different: in a 2 man project with no meetings and direct access to users, each developer will get more done in less time. In a project with 16 developers and a 2-hour status meeting every day, each developer will be much less effective (this has been known since Brook's The Mythical Man Month). But that is constant is the relative complexity of the story you are trying to complete. Relative to the other stories, not the entire universe. This allows developers to hone their estimation skills because it cuts down on the number of variables they have to hold in their head. This is the closet you can get to an objective measurement of the work required to complete a piece of software.
We don't need agile consultants and book authors to sell us vague and unproven metrics along with rigid guidelines that your team must embrace without any questions.
Ironically enough, we agree wholeheartedly about this, but he doesn't seem to know that this is exactly the point of my talk at The Serverside Symposium. The whole point of the talk was that we need real metrics like passed tests, real reconciliation between estimates and actuals, and binary completion criteria. The article makes that pretty clear, but that doesn't contribute to the weak straw man, so Cedric conveniently left that out.
What's most frustrating about Cedric's rant is the implicit assumption that "agile" is this vague concept that no one seems to be able to define. Yet, at ThoughtWorks, every single project is agile to some degree (and where we control everything (like fixed bid projects), it's pretty close to Extreme Programming). And we have a really high success rate, way above the industry average. I've been around for a while (one of my colleagues once told me that I was old enough to "add diversity to the company"), and I've used a bunch of different methodologies. One of the reasons I'm at ThoughtWorks is because we use proven techniques for building software, and we're damn good at it, making it a much less frustrating place to work.
