Traditional Estimating and Individual Accountability
One of the reasons some folks struggle with the idea of relative estimation, is that they want a tool to hold people accountable for doing what they say they are going to do. You said this would take 40 hours, I gave you a week to do it, why isn’t it done yet? Sounds reasonable… right?
In addition, if everyone provided estimates for their part of the job, and we made sure that we had enough people to cover all the estimates, that would mean that we had a credible plan, and should be able to deliver by the required due date, right? Again, sounds pretty reasonable.
Get this… not only could we hold individuals accountable for being done when they said they’d be done, we could hold them accountable for estimation accuracy too… and maybe even gather some data to get better estimates for the next project… and as a bonus… if these folks didn’t get done when they said they would, it wouldn’t even be our fault, they were the ones that provided the estimate. Excellent!
Here’s the problem… what if that individual commitment doesn’t work in the best interest of getting the product delivered? What if helping someone else on the team is the behavior we really want… the behavior we really need…. but our accountability to the estimates causes us to look out for our own individual commitment instead?
For example, let’s say that Bob and Sue both estimate their individual tasks for the next sprint. It becomes pretty clear early in the sprint that Bob’s tasks are going to take way longer than he though. Sue on the other hand is rockin’ her estimates and has moved on to the next set of work.
The thing is, both Bob’s work, and Sue’s work, are required to deliver an increment of value to the business. It doesn’t matter if Sue delivers her work exactly according to her estimate, if Bob is struggling to get finished, she needs to throw in and help. Holding Sue accountable for her part isn’t helping get the product delivered any faster.
That’s why Agile doesn’t care about estimated hours, and furthermore holds the entire team accountable for the iteration deliverables. We want to incentivize everyone on the team to look out for the best interest of the product. We want everyone on the team to work together to build a working product increment by the end of the sprint. Individual estimates, and individual accountability, oftentimes work against that goal.
But here’s the deal. The team and the team’s management need to be vigilant to make sure that the superstars aren’t in a position to always carry folks on the team if they are consistently underperforming. If Bob always struggles getting his commitments delivered, we may have a performance issue that needs to be dealt with.
There are other ways to deal with people that are struggling, other than requiring individual estimates and individual accountability to those estimates. Focusing on the rate at which the team creates business value is the only real measure of success.
(BTW – On a plane to San Francisco, riding in coach. No room for the 15″ MacBook, so I did this post from the WordPress app on my iPhone. It crashed once while I was writing. So if there is any goofiness in this post, that’s why… happy reading!)
I do trianings on Scrum. Just a few hours back, one client called me and said they want “Functional point analysis esitmation” to be taught as a part of Scrum course. The client does not understand that esitmates in software are mostly not precise. Old habits are difficult to change. Many people in software development will have to die / retire before the transition to Agile is complete.
Was that a whine about riding coach? :-)
If I understand correctly, what you are trying to do is reduce the average flow time of the process. Reducing the flow time of the process helps to increase your overall throughput which reduces the amount of unused work at any given point in time. (Little’s Law).
One way I’ve thought about is getting people to bid for work (after having an initial discussion about what it involves). The lowest bidder gets the work, and then has to achieve it in this timescale (or give a very good explanation why not).
This would mean people bid low for things they know about and enjoy doing, so the best people are doing the right jobs. For less exciting work, people would bid higher, and would be compensated for the less exciting work by working fewer hours.
If someone bids too low, then they will have to work long hours (and won’t do it again).
If you’ve already committed yourself to one project, you won’t be able to bid for another until that is complete.
If someone doesn’t have any work to do because they don’t bid low enough, then they will be first in line for redundancy.
Has anyone used this approach in paractice?
Going further, it may be that both Bob’s and Alice’s work could be done faster if both of them collaborated on all of the work. Yet the practice of holding individuals individually accountable undermines the beneficial effects of true teamwork.
I’d bet Bob will learn to pad his estimates in the future. That will keep him out of trouble. Too bad it won’t help the organization.
Your post is very interesting and I have translated it into french :
Thank you, Fabrice.
Agile estimation techniques pay more attention to complexity instead of time and group estimates instead of personal, so nobody has personal time pressure. Estimates should be used more for planning then for controlling. Team commitment keeps focus of the team on delivering business value instead of personal performance and forces team members to help each other to archive common goals.