Let go of knowing. I'm sure you know that I am a big proponent of Agile. You almost certainly know that I like estimating and planning and have written a book on that. I've written about these topics and I believe in these things because I have seen them work. But hey, I could be wrong. As a matter of fact, i hope time has proven me wrong about some of the things I written. Agile is about trying things. It's about experimenting, having a hypothesis, a best guess about the best way to achieve the result. But sometimes things don't work out for the better. And a big part of being agile is being able to admit that, to learn from it, and move on. Let me give you an example about deliberately setting up an environment where we could learn, even when we were wrong. Back in 1999, I was the vice president of engineering for a public company in Colorado and I had a really good boss, the CEO. Things were going very well for this company. Our projects were finishing on time and our products were successful. I wanted to take advantage of all that to get good at something we were not yet good, estimating. Our CEO knew that not every project would finish on time and not ever product would make a ton of money. He wanted that, of course, but he was realistic and knew it wouldn't always happen. I took advantage of this good situation, a successful company with a great CEO, to undertake an experiment. i told each of my development teams they had to estimate differently from every other team. When I first told everyone that each team had to estimate differently, it led to a wide range of estimating approaches being tried. We had teams doing good old task decomposition in which you think about the work and break it down into a big list of tasks. This is where you identify the parameters of an estimate and do things like multiply the number of expected lines of code times the domain complexity divided by the average number years of analyst experience plus the square root of the architect's birth date, and that tells you a due date. We also had teams estimate with what today we'd call story points and ideal days. Most of our projects were two to three months long. And every time a team finished a project, they looked at how well their estimating approach had worked. They looked how at well what other teams were doing had work. And they decided what to do next. Based on the rules I'd put in place, each team had to try something different on each new project. It didn't have to be dramatically different. Just a little different would do. But they had try to something When we first started, I thought an approach we'd been dabbling with called Experienced Senior Programmer Days would turn out to be the best. I wanted it to win. And not just because it had the great acronym of ESP Days. The premise behind this approach was that each team member would estimate as though he or she were an experienced senior programmer. It was a way of normalizing what today we call ideal days. And it was an attempt to get around the problem that your ideal day aren't the same as mine because we have different skill and experience levels. These teams had a definition of an experienced senior programmer, and each team member estimated as though they were that person. So people were estimating for themselves and then adjusting longer or shorter for this archetypal experienced senior programmer. It was a nice theory and it had worked well on an initial project. But it worked because the people on that initial were all pretty close to the archetype. When other teams tried it, we realized it wasn't going to work. it is hard enough estimatin how long something is going take you to do. This approach required everyone to estimate how long it would take a mythical person to do. Bad idea, but I had thought it'd work. Fortunately, although I went into that experiment thinking experienced senior programmer days would be our winning idea. I was open-minded enough to realize, hey, I could be wrong about this. And the rest of the department went in to the experiment with a similar attitude. After the first projects finished, and teams were picking their second approaches, we saw teams begin to coalesce around certain ideas. Parametric estimating was out because it relied on having something like lines of code or function points to multiply by. And estimative lines-of-code was no easier than directly estimated the length of a project. Task decomposition was up because is was too time-consuming and because was impossible to think of all the tasks anyway. Through nothing I did, other than put in a rule that said no two teams can estimate the same way, our teams were converging on approaches around story points and ideal days. There were still some big differences in how teams thought about those, but the differences were smaller than when some teams where advocating parametric estimating or task decomposition. These teams, in fact, that entire development organization, had learned quite a bit about how to plan projects. But as the teams were not yet close to agreement on an approach, the experiment continued. We had teams experimenting with different number sequences, 1, 2, 4, 8, 16, or the Fibonacci sequence, for example. Other teams experimented with whether it was better to always round estimates up, always around estimates down, Still other teams experimented with how to conduct estimating meetings. Some teams experiments with what turned into planning poker. Other teams tried more traditional Delphi and wideband DelPhi approaches. Others teams try creating checklists of things to consider, or having only one or two people estimate each product backlog item.