Jul 212011
 

We interrupt this broadcast...

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.

Where are your priorities?

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:

  1. They were often “bonus features”
  2. They sometimes involved using libraries not needed elsewhere in the solution, or required integration with external services (Amazon, Google maps, etc.)
  3. They may have involved some dressy UI tricks
  4. 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 reallyis, 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?

  2 Responses to “Interrupting (or distorting) your velocity”

  1. In LinkedIn Group “Agile”, Yasser Farra wrote:

    Actually, this finding doesn’t surprise me at all. In my experience as a software developer and as a manager, many (not all) lower priority tasks are what I call LHF tasks (Low Hanging Fruit) – nice quick wins that are easy to implement, pose little risk on other parts of a software system, and have a positive vibe with customers. Most engineers if left up to their own devices will gravitate toward the easier tasks first, especially those that are fun to implement. Higher risk features require more planning, design and thought, and as such appear less inviting and attractive to a developer. After all, there is often no quick gratification in the more difficult and risky tasks.

    There is also a product-related aspect to this. In Agile, a backlog is prioritized by a business person based on the relative value of each user story. In the Agile literature and training programs I’ve encountered, very little attention is paid to technical risk and how it impacts priorities in the backlog. Therefore, as items are prioritized, features that are quick wins with customers are prioritized higher. Every product manager wants to get something to their customer, and rapidly. They understand that the more complicated features, those with dependencies on other applications, services, and systems are going to take some time, so these items often get pushed behind the LHF items. But even when the more complicated features are prioritized first in the backlog, their complexity and risk tend to be underestimated by engineers, and therefore end up exceeding their estimates.

    The way I have solved this in the past is by introducing a risk factor into the back log. The concept originates in RUP. Simply stated, you assign a technical risk level to each item in the back log, a simple High/Medium/Low rating. Then you use that in combination with a High/Medium/Low business value to prioritize the back log, using a 3×3 value-risk matrix. The back log is then prioritized in the following order (Value/Risk): High/High, High/Med, Med/High, Med/Med, High/Low, Low/High, Med/Low, Low/Med, Low/Low. Most of the time, the four first combinations are the most critical. By addressing higher risk items as a priority, any delays in their implementation and delivery is mitigated by the extra time gained by starting on them sooner rather than later.

    • And my response: @Yasser, thank you for sharing your straightforward prioritizing structure. Where I can see the tendency for developers to “work ahead” on their own time and get lower priority tasks done, your writing also triggered in me that even the notion of prioritizing within an iteration suggests we do not expect to complete what we have said we would work on in the first place.

      Maybe I got caught up in the suggestion about applying the stats of the R&D engineers to our space, when we have mechanisms designed to protect us in agile projects anyway? My question related to whether this relates to us… because I accept your rationale regarding how we look at those LHF tasks… and I think perhaps the answer is it shouldn’t if we keep to the tenets of the approach.

      Thanks for helping think this through.

Leave a Reply