Why Agile Teams Fail
Joh and I wandered up to Why Agile Teams Fail, an evening event being run by Skills Matter last night. The top was self-explanatory - what goes wrong with all this terribly fashionable agile business?
The overall message seemed to be "if it doesn't work, you aren't doing it right, or your people aren't any cop" which didn't seem to be massively helpful. But I found lots of interesting stuff in the detail: Erik pulled out lots of interesting facts from the experience of Thoughtworks; some of these I've documented in the Flickr photoset where most of my notes live, a few others here:
- Pair programming can be better sold to sceptical upstream management ("what? you mean we'll halve productivity?") as "constant code reviews";
- Software is never finished;
- True weekly iterations don't often happen, but iterations where each discipline does a weeks work then hands it on (analysts to developers to QA) are more common; I'm still not sure how you balance the fact that a weeks analyst work might lead to 3 weeks development which might lead to 5 weeks QA tho...
- Story points (something I've often failed to grasp the point of) are if nothing else, a good way to avoid confusing the "ideal effort days" estimates are written in with "actual productive days" that you end up dealing with;
A shame that by the end of the talk, the room was sauna-like and we had to run back to Brighton, I would have liked to have nattered more but just didn't have the time. Maybe at the upcoming Brighton Agile Forum, eh?