The Benefit of the Doubt & Agile Estimating

Image by Wonderlane via Flickr

I was sitting in my cubicle, struggling with SharePoint’s stupid use of completely non-standard date formats (would it be so difficult for Microsoft to make sure their own DateTime.Parse() method can parse whatever format they decide to use?), when I heard my name mentioned in conversation going on nearby. Of course, my ears pricked up, and I overheard a snippet of discussion about the estimating process I introduced on a recent project.

The one person in the conversation who had any first-hand knowledge of my project was, essentially, mocking my approach by pointing out all of the details I had overlooked in my initial estimates. My first reaction to hearing this was to be a little hurt that someone I thought had understood what I was doing, and agreed with my approach, was so quick to “throw me under the bus,” so to speak. However, the more I thought about it, the more I realized that there were two different issues at play, here.

First, it seems this person did not really understand what I was doing; he apparently had agreed with my approach because I was using all the appropriate agile buzzwords, and his primary purpose in hiring me onto the team was to introduce some sense of agile process to the project. I really only have myself to blame for his misunderstanding about what was happening.

Secondly, he must not have realized that he didn’t really understand what was going on. If he did, then it seems he jumped the gun a bit, by not offering me the benefit of the doubt, that I actually did know what I was doing!

So, what was going on that caused this confusion? Well, because our company culture isn’t really very conducive to a truly agile approach to software development, I made it my highest priority to engender a sense of trust in the developers themselves. That seemed to be a an achievable goal, so I began all of my estimations with the assumption that individual developers would voluntarily accept specific tasks and provide their own, binding estimate of the effort required.

Accompanying such an approach, I wanted to leave as much of the actual design of the solutions to the developer, as possible. This is where, I believe, the conversation I overheard made its most erroneous assumption. They assumed that my estimates were based on a comprehensive design of the software being constructed, rather than an extremely broad brush view of the primary components I expected to be needed. This means that much of the infrastructure was left undesigned, as I trust the senior level developers to identify and design the infrastructure needs of the business solution.

Of course, it’s also entirely possible that what I overheard was not even about me! There are a couple of other “Kens” in my building, and you really have to give the benefit of the doubt to people when you’re just eavesdropping on a part of a conversation!