Thursday, 17 April 2008 at 09:34
A lot of Agile's power comes from its simplicity. It is a different theory. A theory that allows you to make sense of a ton of experience that previously, with your old instinctive project management methods, you were either throwing away, or even worse, getting depressed and feeling bad about. Did this task take three times as long as you thought it would? OK, don't beat yourself up about it. Don't wail and gnash your teeth because that wasn't in the plan. Feed that information into the next iteration. Get better at estimating. Did the priorities of the project change all of a sudden because of a boardroom reshuffle. Make sure that's reflected in the next iteration. Deal with change and get paid for it.
From the date of the previous post (when I first started thinking about it), you can tell how long this post has been troubling me. Maybe it's taken me so long to respond because there's a lot in this post, and I can't possibly comment on all of it.
The tone of the whole post is slightly depressed. My guess is the author (Mike Griffiths) had just got off the phone to a sales prospect and the news hadn't been good. Or he'd had some energy-sapping conversation with somebody who'd tried some bits of Agile and then rejected it out of hand at the first sign of trouble. We all have those days.
When things go bad, we fall back on our instincts, we try to do the "safe" thing. For project management this tends to be some form of waterfall planning - "OK, the chips are down, the pressure's on but if we just think of everything, plan every little detail and don't make any mistakes...". It doesn't work. This is one of the central ideas of Agile - although it sounds like something from a Kung Fu movie - "Don't trust your instincts - they're wrong. Learn some new ones."
The way that Mike muses in this post about writing a book sounds to me like a similar kind of instinctive reaction: "where my passion lies and where I believe the greatest leverage resides, is in effectively describing this balanced approach to leadership and project management. Strategies and visuals for finding that ever changing balance between people skills and process mechanics, order and adaptation, detail and intent." - if I just think of everything...
Two hundred pages of havering and hedging? That doesn't sound like a book that I'd want to read. The books that I tend to find most rewarding and instructive are the down and dirty ones which report ways that the author tried out a theory, took the experience, good or bad, on the chin and went back and modified the theory. Rinse and repeat as they say. There's some of this in Kent Beck's Extreme Programming but the best example I've read regarding Agile is Henrik Kniberg's Scrum and XP from the Trenches (also available free on-line).