Team players and MVPs

Team players (yes, these two are mine...)

What are the qualities you look for in a “team player”? Respect? Experience? Competence? Levelheadedness? A great personality?

When I hear people use the phrase, I confess I don’t know what they really mean. That is, I know it is a common phrase, but I wonder if people give the jargon any thought.

Sometimes it seems people use the words when they really just wants someone else to change… as in “he/she is not a very good team player”. Yet they offer no (or little) direction on precisely how to become one.

Have you ever met a “team player” you didn’t like to work with? Have you ever seen the term “team player” used in quotes, besides in this post? Ever?

Putting the jargon aside, who do you want on your teams?

Standardization, commonality and best practices

Every project includes some fundamental tasks. Sometimes they are repeatable, even mechanical, and you can train people to do them. You can often anticipate contingencies, and you can teach people to recognize them and act appropriately when they arise.

To that extent, you can train people and substitute them into teams as backups or replacements. So we cross-train on each others’ jobs to provide backup for people to go on vacations. We define standard practices and “best practices” and teach them to people to drop our costs of repeating the same tasks over and again.

Now, the last thing we need is somebody on the team who messes up our routines every day. The person who habitually “breaks the build” or who fails to write unit tests forces his teammates to bear added costs to keep everything running smoothly, until eventually we start to wonder how we can get those people off our team.

So the factors that help us work together in standard practices are one thing that makes us good “team players”.

But that is not the end of the story…

Marginal utility in the team

Not everybody takes the tiller

This post is the fourth in the principles of economics in software development series. We are pausing for a time on the third of Greg Mankiw’s principles, which says “rational people think at the margin“.

Last week I wrote about the implications of this principle on the value of our work (and our salaries). As an illustration, I suggested the difference between the professional basketball player’s income and the amateur’s income might come down to four extra baskets per game.

They’re paid all the extra money because of the incremental points they score.

Now, nobody asked them to score those points in high school or college. Nobody forced them to practice. Nobody read their job description to them.

They did the work. They built their abilities. They found ways to produce value for their teams… and they earned their rewards.

For that, they were not easily replaced. For that, they could compel a little VIP status. For that, they sometimes got out of hand, acted like prima donnas and started producing high costs for their employers (and themselves).

Thinking at the margin doesn’t discriminate

So while there are marginal utilities, which produce marginal value… there are also marginal costs.

“Rational people think at the margin” means nobody worries about what is the same. All “team players” who follow standard practices and never step out of line, but never produce incremental value over their coworkers may feel “safe”… whatever that means to them. But they can never be valued any more than what is commonplace (…and there is nothing wrong with that).

Hire this guy? The most interesting guy in the world...

On the other hand, rational people evaluate the costs associated with picking up those few extra points in a basketball game… with adding that expert to their team, along with any eccentricities they bring. The person who has that unique knowledge of a technology or who can make the database “sing”, but who may not perfectly fit in some other way, might be just what is missing.

They evaluate whether it’s “worth it” – worth the costs in terms of time, energy, money and lost opportunities. And then they willingly make investments to get access to all the difference in the world, if it will help them achieve their tactical, strategic or ultimate objectives.

So let me ask again… who do you want on your teams?

Advertisements

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?