The Road Ahead?

Project Management have an impossible job. Part of their job is predicting the future. The goal is to identify when a project will complete so that resources can be managed. Project Managers also have an interesting way of dealing with the difficulty of this situation. They pass it on. That is they ask the developers when they will be done. At least that is the way it has worked on the software development projects I have been involved with. As a developer I don't like the question "When will I be done"? To begin with it involves the question how done I am. As I wrote last week, I don't think that is a very useful question. Of course, starting with the shaky footing of how done am I and adding the uncertainty of the future into the equation leads to unreliable answers. Of course, it also allows the project manager plausible deniability. After all, it wasn't the project manager who incorrectly estimated.

Why shouldn't the developer estimate when the work will be done? Isn't the developer in the best position to estimate the work? Actually, the developer is not. Now if you are a developer you likely take offense to that, but let's consider the facts. A developer is, or should be, focused on the thousands of detail decisions that go into, well development. What data structure should be used? What UI paradigm should be followed? Is this a part of the the system a candidate for some type of an extensible framework, or should it just be coded and forgotten? To estimate when the work is going to be done, the developer needs to focus on the work that remains to be done. She needs to consider the work schedule not only for herself but for others who's work supports, or interacts with the work that needs to be completed. As developers we like to think that we can do anything, but we have to admit that we cannot do that all at the same time.

So now that I am off my soapbox, how do Agile Methodologies deal with the need for precognition in Project Management? First they avoid the infatuation with dates. A completion date is a pretty poor piece of information. Without know the expectations that went into arriving at the end date, one cannot use it to evaluate how changes in staffing might effect the date. Is the end date 2 weeks out because there is 2 weeks of work to do, or because the developer is waiting on something that will arrive in 10 days and then there is 3 days of work. If all you have is an end date, how do you know the difference? In Agile Methods we are interested in velocity, and issues. From velocity we get an estimate of how long the remaining work (to do estimate from the developer) will take to complete. Obviously the project manager will take any time off or other distractions into account. The issues tells the project manager what is slowing development so they can do something about it, hopefully. What I especially like about Agile Methods is that they look for ways to ensure people are working together.

So that is about it for what I like and don't like about Agile Methods. Not, sure what I will write about next, but having a series like this seemed to work pretty well.