SoftwareGR

Carl Erickson, Atomic Object

Andy Lester gave a great talk last night. This is clearly a hot-button topic as there was lots of discussion and questions afterwards. Some things I thought were valuable from his talk:

The importantance of adapting practices to fit the circumstances. Andy’s team uses lightweight, homegrown tools for estimation and tracking that would be familiar to any XP team. But unlike the planning game in XP, they do more work up front and they don’t have the customer steering the project from iteration to iteration. It works for Follett.

Fred Brooks is not god. Well, actually he might be, but the jury is still out. Transparency and honesty are essential to successful projects. Andy’s techniques (decompose, estimate, plan a week’s work, plot burndown over time) give a realistic view into project status. The point of the exchange on the divinity of Fred Brooks was if you provide the management a view into the true state of the project they may actually be able to add developers to the team early enough achieve a positive outcome for projects that are behind schedule.

“Iterative releases don’t work!” (long quiet pause in the room, kind of like the old Sprint pin drop commercials) This statement of Andy’s turns out to not be blasphemy but rather semantics. They can’t release to the end customer until the application is complete. But they do internal iterative releases for all the same reasons we do.

Technical debt flattens the velocity curve of projects towards the end of the project. This is why all tasks/stories should be in one of two states: completely done or not started. A bunch of 90% done stories represent technical debt building up. Toward the end of the project this debt comes due, with interest, and project velocity goes to zero as the team spends all their time fixing things they already took credit for in earlier iterations.

Accurate estimates aren’t free. Developers need to help customers understand that accurately estimating a problem is difficult and takes time. At Atomic Object we find that accurately estimating a project requires decomposition and design, and sometimes experiments. All of this takes time; in effect you start solving the problem to estimate it.

Estimation isn’t magic, but it is. Or at least that’s how I started thinking about it. Yes, it’s hard to do accurately (Andy’s got a favorite impression of developers who refuse to estimat the size of a task…) But doing something (even a SWAG) buys you an awful lot. And the process really isn’t magic. Break the big rocks into little rocks and keep breaking until you’ve uncovered as many rocks as possible and each rock is big enough to get your brain around and estimate. A simple process, really, but one that can be the foundation for what we refer to as data-driven project management.