A Completely Hypothetical Scenario…
Someone asks me “Andy, how quickly can you get from your home in Farmville, VA to LA.” I run through all the possible ways to get to LA, starting with ways I consider quick. I could drive 90 minutes to Richmond, catch a flight that would connect through Atlanta (you cannot get anywhere from Richmond without connecting through Atlanta), and arrive in LA after about 12 hours of travel. I could drive 3 to 4 hours (depending on traffic) to Dulles and probably catch a direct flight to LA, arriving after about 10 hours of travel . And, though way less feasible, I could finnagle a flight on an SR-71 Blackbird from Richmond to LA. With the 90 minute drive, I could be in LA in about 5 hours.
How do I answer?
“I don’t know.”
“Why don’t you know?” is the immediate response. Sometimes followed by “Andy, you’ve traveled before. You know about how long it takes to get from A to B. You’re a repected professional who has done math before… what gives?”
Option A: I cave at the you-should-know-this implication and say, “Best case: 5 hours.”
“Great!” says the requestor. They throw me the keys to a ’69 VW bus and say “Drop this off at the VW dealership downtown. I’ll let them know to expect you by 2:00 PM today!”
Option B: I ask questions: “Why do you want me to go to LA?” would be a good starter.
Questions are Good
In Waterfall projects, questions fill the Requirements Gathering phase. Ask anyone who knows me: I’m an Agile guy. Short project-ettes are really cool, whether you call them spirals, black boxes, iterations, or sprints. I haven’t met a proof-of-concept I didn’t like.
If Agile has a weakness, it’s estimation. “How many sprints until you’re done?” doesn’t have a lot of meaning at the start of Scrum project. Folks have tried to squeeze it in there up front; it defeats too much of the cool Scrumness to work – or at least to work well. Furthermore, some projects are fixed bid. And when the fixed bid project gets super huge financially, someone somewhere is going to ask you when you will be finished. Sometimes, they’ll tell you up front when you must be finished and it’s up to you to figure out how to get there on time. Again, not very Scrum-fortable.
So Agile is Out?
Did I say that? Gosh I hope not. Agile is not out. I said you can’t start that way.
Using Iteration for Estimation
There are a couple ways to use Agile methodologies (I prefer Scrum because it’s simple and effective) to assist on super huge projects.
First, you can use it to build a team characteristic. If I haven’t before, I need to warn you I’m an engineer. One of the coolest things to do with transisters is measure their amplification performance properties – referred to as a characteristic (here is a link to a wikipedia thumbnail showing the characteristic for a MOSFET transistor [no relation to Boba or Jango]). It turns out software development teams possess similar performance characteristics. There’s good arguments for and against how to measure developer performance: interesting white paper here (for) and great post here (against).
My opinion is individuals can be measured but should not be compared to other individuals – which just made measuring-Andy’s-way useless to 95% of the managers reading this post. Individual metrics should be used to measure the development of the developer. We’re in a field where it’s our job to learn new things and apply them to the problem at hand. Think about that for a minute.
I have two quips on the topic: 1) “One day, someone is going to hand me a spec to design something, and I am going to know how to accomplish every single piece of the design.” 2) “This ain’t changin’ tires.”
Individual metrics should measure the individuals progress in designing and developing better solutions. (I will not define “better” here. I’ve gone off point far enough…)
My point is a collection of developers will perform more or less consistently over time. Collecting performance metrics – projected milestone date vs. actual milestone date, for example – is useful. Again, it’s a time thing. You cannot collect a single measurement and draw the curve or plot the scatter points (and, by the way, this will be a scatter plot). But you can gather enough information to predict, with some mathematical degree of confidence, whether a team will hit a date.
Second, you can use Evidence-Based Scheduling as described here by Joel Spolsky. Truth be told, Joel’s method produces a performance characteristic, and his post describes using this technique to develop characteristics for individuals. I believe this works for some individuals but not all. But I have much higher confidence applying Joel’s technique to teams.
McConnell
No discussion of estimation is complete without reference to Steve McConnell’s excellent work on the subject: Software Estimation. Everyone needs to read this book. Especially project managers. The Cone of Uncertainty needs to be posted on every cubicle wall.
Conclusion
If, when asked to provide an estimate, your options are: A) Guess (Lie); or B) Admit you don’t know; choose B. But don’t stop there. “I don’t know” is perhaps the only wrong answer in software development – the sentence needs to be completed.
“I don’t know, but here’s my plan for figuring it out.” Now that’s an answer.
:{>
As with most SQL Server people, my favorite answer is "it depends". In my case, the follow up is "do you want it done, or do you want it done right?" The answer is usually somewhere in between these two.