Managing Product Development

I’ve discussed this situation with several managers recently. The manager says, “I have a wonderful developer, who can code circles around everyone else. If he doesn’t like someone else’s code, he rewrites it over the weekend. If he sees a hole, he writes a ton of code over the weekend He starts work early and works late. But, I have a tiny little problem. I can’t keep people who might be just as good. I can keep people who are not as talented, but can’t retain people who are not quite as good. But that’s ok, isn’t it? After all, don’t I have the most productive employee?”

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.

Tweet This Post

Jack has an intriguing post, The fun of productivity measures. He ponders how to measure knowledge workers.

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?

Tweet This Post

I’ve been sick for weeks, and am finally coming out of it to be close to healthy. (I was still coughing in the 8-degree Fahrenheit cold leaving the gym. Oh well.) One of the problems is that my work doesn’t stop if I’m sick. I bet yours doesn’t either.

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.

Tweet This Post

Esther has insights, Specialists AND Generalists, on Why Projects Don’t Need Specialists. Her point, that people tend to coalesce around their interests, and that as specialists, they may not share interests, is something I have also seen on projects. As Esther says,

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.

Tweet This Post

This year, after I archived my last year’s inbox, I decided my email problem was getting worse, not better. “I’m Johanna Rothman, and I have a problem collecting email in my inbox.” I decided to make an effort, one day at a time, to get to zero emails in my inbox. I’m inspired by Merlin’s inbox zero.

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…

Tweet This Post

I taught several PM workshops last week in Israel. The Israeli project managers have the same concerns that my US students do–it’s difficult to imagine moving to Agile or even just integrating agile methods into your project if you have specialists.

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.

Tweet This Post

Earlier, I made an off-hand comment, “The zeroth measure of productivity is showing up.” I now think showing up is necessary, but not sufficient. I’ve been thinking about what each of us produces individually, and thinking of ways to understand and possibly measure it:

1. How many hours per day do you stay focused on strategically important work? Sometimes, I keep a time log to make sure I’m working on appropriate things. Especially if my to-do list is very long. Like many other people, I can be distracted by things that are easy to do, but not as necessary as the work that may be harder to finish.
2. How many stupid mistakes do you make? When I was younger, I was so proud of myself. I would take myself home after making three stupid mistakes. ARGH. Three! Why did I have to make more than one stupid mistake??? I learned that three stupid mistakes is two mistakes too many. Now, if I make my mistake at 9am, then I can clean up email or my office for a few hours until my brain has a chance to think again. If I make another mistake, I take the rest of the day off (from hard-thinking work). There’s almost always something I can do that doesn’t require hard thinking.
3. How many of what did you accomplish in a week? How many times did you revisit that work? When I’m writing, sometimes it takes me too many drafts to find the right way to discuss the topic. Same for creating presentations. When I was a manager inside organizations, I noted how many decisions I had to re-open. When I was a tester or developer, I looked at the work to see how much rework I had to do. Finishing a piece of work the first time isn’t enough; the work isn’t complete until the people you hand the work off to agree that it’s complete.

So, my measure of personal productivity is how long I can stay focused on useful work, and how few times it takes for me to accomplish that work until the person I hand off to is satisfied.

Tweet This Post

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.

Tweet This Post

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.

Tweet This Post

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.

Tweet This Post