Recently, we’ve introduced Commitment Based Estimation to a couple of our software teams. Typically, this helps a team provide highly-accurate estimates. These teams go on to deliver successfully by meeting these estimates.
This time around, we encountered a new anomaly. Although both teams were following the identical process, one teams’ estimates were consistently off. While one team was able to match their estimates, the second team was consistently inconsistent.
In Commitment Based Estimating, you allow the team to give their own estimate without imposing one on them. Given teams with similar experience, you typically see very similar estimation results. We couldn’t figure out why one team’s estimate was so much higher than another similar team. The teams had similar experience. The technology they were using was also similar. The team members had equivalent experience.
Typically, after introducing Commitment Based Estimation, it will take the teams a few iterations to find their strides. Once they do, the teams estimates become highly accurate. We couldn’t understand why one team wasn’t finding their stride.
The 3 Great Interrupters
When we lifted the cover, we found that by using the Getting Predictable, the teams naturally started managing their time better. One team improved their estimates by as much as 30% while another team’s estimates seemed to be inconsistent at best. We found one significant difference. Actually, we found three differences:
- Management, and
- Drive-bys (These are when the boss comes by and throws a grenade at you, like, “Hey, I need you to help me with a problem…” Then all of the sudden you’re off on some tangent.)
The team that was inconsistent had experienced a higher percentage of interruptions than the other team. Drive-bys and management interruptions were constant. But the team didn’t feel safe to simply close their team room door and put up a Do-Not-Disturb sign.
The Solution: Allocating Time for the Interruptions
Once we understood that the team couldn’t find their rhythm, we decided to divide the work-week into ten buckets of time. Each bucket was effectively half a day. Monday morning was one bucket, Monday afternoon was a second bucket, and so on. Seven of those time buckets were reserved for heads-down coding. Nobody was allowed to interrupt the team. No project meetings. No estimation meetings. No drive-bys. It was their Do-Not-Disturb time.
The three remaining buckets were allocated for interruptions.
For example, there might be a scheduled project meeting on Monday morning, when estimation could be handled and their boss could make team-requests and stop by to ask questions. That afternoon they could go back to planning and coding. Then we would have another half-day midweek, where, again, they might do some estimation meetings. Finally, at the end of the week, they might have a half-day dedicated to administrative work.
This strategy allowed everybody to be mindful of interruptions and to be very productive on the seven half-days that were dedicated to real work.
What we found was the team developed a much higher velocity or rhythm and started to improve their own performance and focus. It became a process they started using on all projects. Finally, both teams were experiencing similar results!
So to sum it up…
Get a handle on distractions and interruptions. Dedicate certain time slots to those interruptions. Manage everyones expectations. Advertise that these time slots are available for any non-coding needs. Make this a team-norm and protect your teams productive-time.
Do you have some other time management recommendations?