Interrupting (or distorting) your velocity

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 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?


Does your IT salary depend on what makes you different?

"Rational people" think at the margin...

It’s Monday, and that means I take another crack at an economic principle and apply it to software development and IT. (Here is a link to the series so far.)

This week we are on principle #3 which goes something like this:

Rational people think at the margin.

I am going to put aside questions about whether (or which) people are “rational”, or whether I would be qualified to make the assessment in the first place.

Instead, I want to focus on the “margin”. (Perhaps that makes me “rational”, after all.)

In this context, the “margin” relates to an economics principle called “Marginal Utility“.

A summary of the concept (for our purposes, anyway) is that people will value two otherwise equivalent items against each other based on their “marginal” (or incremental) differences, positive or negative.

So we might pay more for one car based on its gas mileage or on its performance characteristics, all other attributes being pretty much the same.

Fundamentally, the market of buyers and sellers converges on a certain price at which a commodity might be bought or sold.

As long as a surplus of buyers or a shortage of supply exists, prices may rise… and the converse also holds.

Designing for marginal utility

Now, if a company wants to sell its products at a premium, you may have heard that it needs to “differentiate” them in the market.

More specifically, the company needs to name, find or design a marginal utility for its offers… an incremental change that drives a disproportionate increase in assessments of value (price).

Don't quit your day job!

My business teacher, Toby, used an analogy like this (the following numbers are illustrative only, and may not be accurate):

  • A “good” college basketball player, scoring 26 points per game, has no chance of becoming a professional…
  • A “great” player, routinely scoring 30 points per game, might get drafted at a league minimum salary…


  • The “elite” player who always scores 34+ points per game might get a starting salary ten times higher (not to mention endorsement deals and other additions to income)

Looking at it that way, you could say that the difference between getting into the pros and not is 2 baskets per game.

You could also say that the elite player gets 90% of their income from the extra 2 baskets they make every game.

Bringing the topic back to IT

Since I thought it would be good to set up what marginal utility is and offer an illustration, it seems to me that we can spend a couple of weeks on this subject. We can speak about designing marginal utility at the individual, team and organizational levels.

So while we have the notion of salaries fresh in our minds, let’s start with you and me, shall we?

First, let me make my intentions really clear: I accept that people say money isn’t everything. People don’t have to slave and toil to get paid more. There is nothing morally ‘right’ or ‘wrong’ about wanting higher pay or not.

Remember that the topic is marginal utility in the domains of software and IT. So I am just speaking of the topic about how much we get paid. That’s all – I have no judgments and am not making any recommendations – “I’m just sayin’.”

I have nothing particularly witty to write this time - this is a piggy bank on a pile of money.

In the basketball analogy, good players don’t become professionals. There is nothing wrong with them – they’re good… just not valued highly enough to get in at that level of competition.

In my career, most of the IT people I’ve met are good.

They get paid what the market bears for their roles, which our industry declares clearly and consistently in job descriptions from one company to the next.

A Java developer is a Java developer, and they make a certain amount of money. They make a little more as a consultant, generally speaking.

A “senior” Java developer wants to get paid more, but the standard for assessing what “senior” means is not well established.

And don’t get me started on what an “architect” really is in all its various derivations… except they also expect to get paid more, and have higher expectations to live up to.

The point is: as long as what defines your capabilities and accomplishments is the same as everyone else, the market sets your rate pretty clearly.

In this situation, your income fluctuates with the market, and you are a commodity, in a sense. A business may see you as replaceable, you may struggle to find your next role and you may feel trapped in roles, feeling underpaid and undervalued.

On the other hand, when you find those strengths that you bring to bear – those things that makes you incrementally more valuable than someone else in your role – that could be marginal utility (your “2 baskets more“) for which you compel other to pay a premium.

Just be careful in thinking that what you value about yourself is what they value, and that you deliver enough that they will feel your premium is worth it.