Agile methodologies yield appealing promises – deliver the maximum value for customer money by frequently releasing a shippable version of the software kept in sync with the customer’s needs by the presence of a customer proxy in the development team.
I hadn’t really bought in all the hype of agile, but I think that there are a bunch of principles that make a lot of sense. Unit testing and make the simplest working solution are the first two that come to mind. Beside that I was very curious about how the agile deals with planning.
In fact, though agile preaches not investing on documentation and does not make any warranty about reaching any given feature set in a given time, agile uses estimation to size iteration time span and move one to the next. The same estimation is also used to assess the “speed” of the team and as such forms the base for next estimations.
In XP you have the so called “planning game”, where programmers confront each others bidding for features (“I can do this in 3 days”, “I can do it in 2” and so on).
“Agile Estimation and Planning” is a very good book, it presents the matter in a smooth way, with many examples, but not too much. It doesn’t tackle a specific process, but illustrates a way to estimate and plan that is compatible with the agile practice.
Such compatibility is also a limit. In fact, in order to have the agile working, you need to find a suitable context. One where everyone is willing to accept that at the end of the budget there won’t be what we agree on today, but (if everything goes fine) the best value for the money spent. Let’s say that if you find such a context of trust and understanding, then it is likely that any methodology will work. But I am digressing.
Nonetheless Mike Cohn manages to provide how-to guide for the cases for the rest of us, i.e. when the customer wants something for a given date and in a given budget. The method described accounts for evaluation of worst case and some statistical mumbo-jumbo to get a number that is less than the sum of the global worst case. That makes sense, though I didn’t find in the book any mathematical support for his method. Well this doesn’t mean that the method has no mathematical ground, just that it is presented as something “given” rather than derived.
Overall the book is a pleasant and inspiring reading regardless you are on an agile project or not. I recommend it to anyone who is required to estimate software development task.