Let’s review what productive means for software. It means the most number of features per unit time per team. Personal productivity is meaningless. Keeping everyone busy is meaningless. But having one employee who is a bottleneck, or one employee who prevents a team from increasing their overall capacity (running tested features per unit time), that’s a problem.

One manager who had this problem has a bottleneck employee, one who prevents other people from doing their work, by interrupting others from finishing their work. (See Retrain Your Code Czar for an article I wrote about this a number of years ago.) Bottleneck employees are frustrating to the rest of the team and prevent everyone from accomplishing work–except the work they want to accomplish.

Another manager has the problem of one person bringing down the expertise of the entire group by being an indispensable employee. Indispensable employees prevent other people from learning because they take care of things for other people. Other smart people don’t want to work with the indispensable employee because they don’t get the challenge of solving the problem themselves.  Indispensable employees are quite dangerous to the longterm health and success of your group.

If you are faced with one really productive employee and some not-so-hot folks, reexamine your situation. Do you have a bottleneck or an indispensable employee? If so, fix the situation. They are not helping you.

For software project teams, it’s easy: the number of running, tested features over time. The features have to be complete. No partial credit for partially done features.

But what about for managers? That’s a little trickier. I like to start with these things:

• How many obstacles did I remove?
• Did I make decisions that stuck? How many? How many had to be remade? (Remaking decisions can mean the time spent on the first one was waste. Maybe.)
• How much strategic thinking and action did I take? (A little each week and you make progress. None each week and you fall behind.)
• Did I prevent any crises?
• Did I cancel any meetings?
• Did I have to change the project portfolio between portfolio evaluation meetings? (This makes waste for everyone)

Do you have any measures you like for managers?

Daughter #2 asked last night if I was caught up. “No, I just made choices about what could slip, and I made choices about what not to do anymore or for a while.”

As you can tell, blogging slipped. I’m not yet late on some writing projects, but I may well be. It depends on how quickly I can write my next Stickyminds column. I postponed several coaching sessions because if my brain doesn’t work, that’s not helpful for my coachees.

I’ll be at SD West next week, and was planning on having an entire day in the gym because I have no sessions on Tuesday. Nope, not going to happen. I can do a short workout and then my free day will be taken up trying to get the things done I haven’t done for the last three weeks.

You can postpone work. You can choose not to do it. You can deliver it late. You can do less. But catching up is not possible. Something gives when you can’t work.

The same thing happens when you manage a project portfolio. Just as projects don’t make up time, the portfolio can’t either. If something slips, you make choices about what to do next. You can postpone a project. You can transform it in some way. But don’t expect to make up time. Catching up doesn’t work.

Reducing categories (having “developers” rather than many named specialists) reduces differences and helps people focus on shared goals.

Shared goals that lead to working product is the point of the project.

P.S. I realized late that I had forgotten to title this post. Fixed.

I did well until yesterday, the first real workday of the year :-) When I left my computer for the day, I had 6 emails in it. Since I’d started the day with zero, that was a bad thing. I’ve really worked at it today, and I’m down to 3. I hope after lunch that I can get back to zero.

I think I have these issues:

1. I have to know what actions to take on each email. Sometimes, that’s not clear.
2. I have to take that action :-)
3. Sometimes, those actions are longer than I want to spend on email.

I might have more issues, but those are the ones that have arisen since Jan 1. Now that I know what hey are, maybe I can address them.

BTW, these are the same issues that managers have with ranking the portfolio. I’m hoping that the measurement chapter will make the actions for managers clearer. Maybe there is something I need to measure for myself…

Specialists increase project delays in these ways:

1. They aren’t available when you need them. Because they are specialists, it’s too easy for the specialist to be busy on another task when you need that specific person. And, because you or the specialist estimate only the time the specialist needed, if you ask anyone else to do the task, the task will take too long.
2. The work backs up. No, you don’t need a specialist all the time. But when you do, you need them. So, since work doesn’t arrive as an even distribution, but instead arrives more in a Poisson distribution, the specialist has some periods of time when they aren’t busy, and more times when they have a queue of work.
3. Murphy’s Law will happen. Just when you need a specialist, that person will want a vacation, or want to get married, or go skiing for two weeks, or have a baby. Or, leave the organization.

PMs (and projects) don’t need specialists. They need people who are multi-talented and can finish tasks. Am I saying that we turn GUI designers into kernel developers? No, but there are many more things that a GUI designer or a kernel developer can do, rather than just one specialty.

If you have specialists now, rethink your staffing, and offer people opportunities to learn new skills. Your projects will progress faster and you’ll be more effective.

The zeroth measure of productivity is showing up. Sorry I haven’t been showing up, but I have to admit, sleeping is good :-) Ok, back to business.

When I tried to calculate productivity of a team, here’s what I measured for one team over the course of five releases (Apologies to bloglet subscribers; tables don’t email well):

Ok, so this team had a number of problems. The first problem was that they didn’t think defects was part of what they produced, so they didn’t count defects for the first two releases. By the time they started counting defects, the defects overwhelmed them.

Their management didn’t think counting defects was important at first, which is why their apparent productivity was so high for the first release, and not too bad for the second release. By the time they attempted release 4, the product was so error-ridden, they couldn’t make any progress on features, and were adding to the bloat and defect levels. For release 5, they instituted peer reviews and better end-to-end testing, so they could see if their fixes worked.

Contrast this traditional development with more agile projects. In an agile project, you can determine each iteration’s velocity (number of user stories per iteration) and the number of outstanding defects. Because people on agile projects tend to perform test-first development the sheer number of defects tends to be fewer. And, if the testers and the customers write user acceptance tests in advance of the first line of code, agile projects tend to have fewer egregious defects. (The one problem I don’t know how to solve with agile projects is keeping the customer involved.)

So if you’re measuring productivity, try measuring size, time, number of people, and defects. Once you’ve calculated some sort of team productivity, see if you can figure out personal productivity. Just don’t forget that a person’s productivity is based on their entire contribution to the product, not just the number of lines of code (or tests or whatever) they contribute.

When we think about manufacturing work, we measure labor productivity as the ratio of the output of goods and services to the labor hours devoted to the production of that output, output per hour. (See U.S. Dept of Labor)

Remember the discussion of Project Constraints and Requirements? That’s where I said the project requirements were a tradeoff of how much (feature set), when (time to market) and how good (defect levels). That’s the reason we can’t use output per hour as a software (or any knowledge worker) productivity measurement. Here’s why: If you don’t care how good a deliverable is, I can have it for you almost immediately. It won’t work, but my “productivity” if all you consider is when I say the deliverable is complete, is very high. (Not much time spent, so the ratio is high.)

If we want to start measuring developer or tester productivity, we have to define output per hour (or whatever time period you desire).

For developers, we can measure designs considered, lines of code generated, the number of defects generate along with the code, unit tests generated, unit tests run, how good that output is,and the time it took the developers to generate all that output.

For testers, we can measure test designs considered, number of tests generated, attempted, and run, test logs, defects detected, defects reported, number of measurements provided back to the developers as information,how good that output is, and all the time it took the testers to generate all that output.

Not so simple, eh? If we just knew how to measure how good our work was, we’d have a chance to measure individual producitivity. The more I think about productivity, the more I know it’s a project-by-project thing, not a person-by-person thing. Yes, some people have more effective output than others. And I’m not sure that matters.

If I can figure out how to share some data tomorrow, I will. Most of my data is under non-disclosure, so I have to be careful with what and how I talk about data.

In the past few weeks, too many managers have written to me, asking for help on knowing how “good” their people are. When I ask more questions, such as “What does good mean to you?”, they say they want to know who’s most productive. Then I walk through this analysis with them:

Productivity is not about the number of lines of code, the number of tests, the number of defects reported, or the number of requirements defined. Productivity is how long it takes the entire team to create a usable product, and for whom that product is usable.

It usually takes us a few emails to get past that statement. That’s because these managers now realize a single-dimension measurement is inadequate for measuring a person’s productivity, and that on a project, it’s the productivity of the project, not the productivity of a given person that matters.

For you lifecycle/process aficionados, that’s why agile projects, staged-delivery, evolutionary delivery lifecycles, and critical chain project management works. Each of those lifecycles or techniques focus on getting work out of the project, not waiting until the entire project is complete.

Tomorrow, I’ll deal with the kind of things you can measure.

For those of you who were wondering, the spring cold that started two months ago developed into pneumonia last week. Maybe now I’m at the end of my personal disease season :-)