Don’t trust developers with project management - A good debatable blog entry by Udi Dahan - The Software Simplist
What with all the warm and fuzzy feelings around trusting developers (here, here, and here) I just have to tone it down a bit. The title takes it a bit far - but less than you might think. Just today I had a talk with one of the team leads on the project I’m consulting on. It boiled down to this:
Developers don’t know how to estimate.
Or more specifically, the variance in the actual completion time of a feature from the estimate given by a developer increases probably exponentially with time.
For example, if the estimate is a day, you can expect it to be finished in around a day. If the estimate is a week (5 works days), it will probably vary between 4-10 work days. If the estimate is a month, in all actuallity the developer probably doesn’t know enough to say but will answer when pressed.
This is why Ron (the team lead) asked me if I wasn’t worried I was putting myself in a lose-lose situation by changing the project structure. There were two “teams” when I came in - developers and testers. All the team leads had “committed” to “finishing” the project in 6 months. When I originally proposed the change to more feature-driven teams, mixing skilled and newer developers and testers together on the same team, came the cry:
“It’ll take us twice as long this way.”
“It’s so much less efficient than before.”
And on, and on. What was funny to me was that 3 of the “6″ months were already gone and not a single feature worked. We were half “gone”, and nowhere near half done.
The thing is that Ron was sure I was cooking my own goose with upper management. What he, and most other developers don’t know is that upper management has gotten used to the state of things. If developers say one month, management has seen enough history to know that it’ll really be 3-4 months. So when I come in and do things different from what developers are used to, upper management is thrilled - that’s why they brought me in the first place.
The difference is that by working based on features, and measuring project progress by feature-units completed per iteration, I drive down variability. This creates solid data about progress saying when we’ll be done (more or less). This is quite different from the “normal” course of many projects:
“OK, so it’s been 8 months now on your 6 month project. When will you guys be finished already?”
Without the data, your only strategy is hope: “Umm, I hope the developers will be done this week(?)”
Don’t get me wrong. I trust my developers and testers deeply. But it’s not their job to know how to estimate and manage projects. PMs who take developers estimates as is and stake the project on that being correct are setting themselves up for failure - with only themselves to blame.