Interrupting (or distorting) your velocity
July 21, 2011 2 Comments
How is your velocity? Do you focus on the highest priority actions in your projects? in your workday?
This Tuesday, The Daily Stat from The Harvard Business Review reported that R&D engineers completed only 73% of their planned daily tasks.
Maybe it is not applicable to software engineers, but I don’t have grounding for refuting the stat in our space as well.
The short brief goes on to say that interruptions caused 58% of that lost effectiveness, resulting in about 96 minutes of lost time each day.
In my agile teams (and as far as I know a standard practice everywhere), one of the factors I consider in estimating velocity is time lost to interruptions.
So we might also figure that using a flexible velocity that doesn’t rely on 100% productivity will take care of us…
Getting our priorities straight
What really caught my attention, though, was the last sentence in the briefing:
Although urgent tasks tended to be completed, the researchers […] found that less-important tasks were somewhat more likely to be completed than more-important tasks.
Slow down and read it again, if you didn’t catch it. Tasks considered “urgent” DID get completed. That’s good… and it is consistent with what I would have figured.
But less important tasks were somewhat more likely to get completed than more important tasks.
Do we just ignore this because, after all, we are agile software developers and our teams, coaches and customers are awesome at prioritization?
Are we better than R&D engineers, more gifted, or less “human” that we are not affected in the same ways they are?
More interestingly, I wonder why it might turn out this way? What are the characteristics of high and low priority tasks that might make this situation happen on my projects?
Has it already, and I never really analyzed the data this way?
The anatomy of low priority tasks
I have one theory about why this may happen, and if it has merit it might even be LIKELY on just about any project.
As I think back through various projects and the tasks that were not high priority, I noticed a few characteristics:
- They were often “bonus features”
- They sometimes involved using libraries not needed elsewhere in the solution, or required integration with external services (Amazon, Google maps, etc.)
- They may have involved some dressy UI tricks
- Developers generally thought they might be “easy” changes
In other words, they were the PERFECT kinds of tasks a developer might “volunteer” to do in the evening or over the weekend for the sheer joy of development. You know, the tasks a developer might pull as a “freebie” to the project.
If that’s what is happening, I can imagine we might see this kind of statistic on just about any project.
Of course, that brings up other issues like what our velocity really is, and how we might address the higher priority tasks not getting done. Honestly, I can’t say I have seen the same effects as HBR is reporting about high priority tasks.
But what do you think about the low priority ones? Can you think of other reasons they could be getting done at a rate higher than you might expect?
You must be logged in to post a comment.