April's CHIRB: Andy Lester's "Preventing Crisis" Project Management talk

The Chicago Ruby User Group met yesterday, and Andy Lester gave a talk about a lightweight project management methodology and technical debt. You can find the slides from his power point presentation here.

I took some notes, but am not going to post them here because you are better off just looking at his slides. I am classifying Andy's process as a waterfall methodology for a post agile world. According to Andy, Waterfall is too heavy a process, and XP is fatally flawed because there is no concrete schedule up front to show the customer. With that in mind he has created his own method for developing software. It seems to be just what he advertises: lightweight and adaptable. However I have some concerns about it I am going to address here. I am a big fan of XP and would have liked to hear him talk more about his experience with that. In my experience the people who don't like XP are people who have never been on a project where XP was done right, but that is a whole other topic.

One of the premises of Andy's methodology is that you do a detailed schedule for the project up front. All work is broken down to tasks of 4 hours or less. People responsible for the work have to sign off on the task estimates. I don't think this is realistic even for small projects, and on a big project, say 10 developers for a year, you are kidding yourself if you think you can break the whole thing down into 4 hour tasks. The problem is that even if you are right 90% of the time with your estimates (very unlikely) as you build your schedule out into the future that 10% comes back to bite you. Imagine these estimates stacking on top of each other as building blocks for a skyscraper. If 10% of the blocks are too big or small, the entire structure becomes a wobbly mess. Maybe an accurate schedule isn't the point, but if it isn't then why spend all the time figuring it out?

Overall his process seems like it would work for very small teams in workplaces where the management was rather hostile to XP. Lightweight is good for small projects, and XP requires discipline. Without team buy in XP can be pretty crappy. So if you can't seem to make XP work perhaps Andy's methodology will click with you. I'd be interested to hear from somebody besides Andy who has used his method. I still maintain that when done right an XP team is a complete joy to work on. I love the social and humanistic side of the methodology, and I would fight against any method, including this one, that would try to take that away from me. Viva XP!