Managing Product Development

There’s a great quote over at The pernicious thinking behind multi-tasking.

Note the admission that required multi-tasking is an implicit means to avoid conflicts around setting priorities.

I’ve been doing a bunch of multitasking talks this year (and suggesting ways for people to say no), and have written about it in Successful Project Management. (I did rename the section that originally said, “Multitasking is the root of all evil.”) When I talk about it, and tell people it makes no sense, at least part of the time they say “Ooh.” Too many people have no idea what the cost of multitasking is.

But the conflict avoidance part is because management, especially senior management is unwilling to make the hard decisions about what’s most important to do. That’s unacceptable. Managers are the only people who can make these most strategic decisions.

Multitasking guarantees your project will be late. If managers don’t make the decisions, project staff will. And it won’t be the way the managers want it.

Labels: multitasking, project management, Successful Project Management

I’m trying to describe the costs of multitasking. Here’s what I’ve got so far:

There are three parts to multitasking:

• Stopping the work you’re doing. The stopping cost is the time it takes to mark your place, save your work, etc. You haven’t stopped thinking about what you’re doing, but when you stop to take a phone call or answer a question, there’s a stopping cost. If you’re in flow, this is surprisingly high.
• Swapping out what you’re working on. The swapping out is the act of clearing your mind of the work you’d been doing so you have room to swap in the new work. If you were in flow or concentrating deeply, this can take anywhere from 5 minutes to 30 minutes. Sometimes, it takes me even longer.
• Swapping in the new task. The swapping in depends on the complexity of the work and how long it’s been since you last touched the task. The more complex and the longer the time since you last touched the task, and the more people you have to talk to, the longer it takes.

I don’t know how to give ballparks for each of these. Certainly, for some tasks, it’s fairly trivial. If I’m organizing a normal weekday dinner, my swapping in/out is very fast, because there’s little knowledge associated with each task. But now when I write chapters of a book (or back when I was writing code,) the costs can be very high, because the knowledge in my head is not yet written down. For me, the stopping the work is defect-inducing. Unplanned interruptions help me make defects. So does the swapping back in, if it’s been a long time since I last worked on this task.

Did I miss anything?

A few weeks ago, I republished an article originally published in Better Software: Convincing Management That Context Switching Is a Bad Idea on the AYE site. I’d received no feedback about the article when it was published, so I wanted to generate some discussion about my ideas.

I did generate a little discussion. Don Gray first said “Context switching is fun!“. Later on, he said the differences were:

* One switches between similar tasks, the other doesn’t.
* I’m not under deadline pressure. (Should anyone be?)
* I get to choose when to switch contexts.

George Dinwiddie discusses the issues of flow in his Context Switching post and the consequences of being interrupted. Don Gray in a later post discusses why managers feel it’s ok to ask people to do multiple things.

I still think managers assign people to context switch for these reasons:

• The manager can’t decide what’s most important.
• The manager doesn’t understand/remember that technical work is different from management work, and that the more things a technical person works on, the less that person will get done and the worse the work is.
• The manager can’t remember all the work required and doesn’t realize he or she is asking one person to work on more than one thing.
• The manager still believes that people who multi-task are more efficient or get more work done than people who don’t.

Do you have better arguments than mine? What do you think?

A reader sent me email with this question: “We have a group of four people (3 developers and a tester). We work on 4 products, releasing one about once a month (each product is released once a quarter). The developers are devoted to one product when they’re developing, but have to fix problems immediately if someone finds a problem and reports it. How do I manage the multi-tasking?”

I’ve asked the reader a few questions. I still don’t know everything about the environment, but here’s what I suspect is happening, based on my questions:

Each product has technical debt, from insufficient testing (all the way through development) from previous releases.

There are a ton of ways to deal with insufficient testing. I would first start with peer review of fixes. If someone is interrupted from new development to deal with an already-existing, but newly discovered problem, have the developer ask a peer to review the fix. Part of the peer review would be to create automated tests for this fix. (Yes, I realize this now interrupts two people. I find that if there’s a Big Problem in one product, there are frequently other related Big Problems in the related products.)

After peer review and automated tests, I would (gently) ask the tester how the tester missed this problem. This is for root cause analysis, not to assign blame. The tester doesn’t read or write code, so the tester can only perform black box testing. Black box testing, by its very nature, is unlikely to find most of the gotcha’s in a product. After a short root cause analysis, I would add some form of automated test development activity to each project.

I can see some heads shaking from here. “If we take time to add tests, we can’t add as many features.” You’re absolutely right. But here’s the problem. You’re not adding the features now. You’re adding broken almost-features. That’s not helping the customers. The customers deserve to have features that work.

So, to deal with multi-tasking from defects in a small group, I recommend changing the way you work. If you keep the same lifecycle you have now, add the practice of peer review of all code and all fixes. Add in automated testing for all defects that have to be fixed from the field. Change the testing, because it’s not exposing the Big Problems before you release. If you choose to change lifecycles, I suggest an agile lifecycle with test-driven development.

Whatever you do, don’t assume that wishing away the problem will make it go away. Some practices need to change. Maybe not the ones I’ve suggested, but some of them do. The change will take time, depending on how much technical debt you have. Otherwise, you’re left with the quality pledge and no muscle behind it.

Clarke Ching’s Multitasking MAKES YOU STUPID is another great article. But when I teach PMs or coach managers, they say, “I need to multitask to get things done.” Or, they say, “I’m ok with multitasking.”

Even smart people think they can do a couple of things at one time. Maybe they can. But the more things you try to focus on, the less overall you do. Think about that word focus for a few seconds. When you focus on something, you concentrate. If you’re attempting to think or work on several different things, you’re not focusing on anything.

I once worked for a company who decided its mission was to “focus on five.” Even then, I knew five was too big a number. But when I suggested we focus on two, my suggestion was dismissed. Company no longer exists.

Deciding what to do –and what not to do — is not simple. I just created a simulation (Esther reviewed it for me) to hammer home the point that we all have a limited attention span, and when we pay the necessary attention to one thing, we’re not paying attention to something else. In the simulation, people have to make choices about what to do and what not to do. I’m using the simulation for the first time next week. We’ll see how it goes. Maybe I’ll be able to report back.

If you’re faced with multitasking demands, stop for a few seconds. What’s the most strategically important work? Do that first. If you have three or seventeen things you think are all at the same importance and you can’t rank them, ask your boss. You’ll find that a bunch of the things you think you’re supposed to do may not even need to be done. Just don’t think you can do them all at the same time, because you can’t.

At a recent presentation, (Managing the Management Balancing Act) I discussed the problems of multi-tasking. I received this feedback:

Johanna, I have to say that I think you are off the path in terms of “multiple projects.”

1) Organizations just don’t work this way - it isn’t cost-effective.

2) Today’s emerging workforce (20-30) were raised in an environment that was not FIFO. It’s multi-in, multi-out.

If you can prioritize projects and sub-divide the work, these people are fantastic “multi-project” testers. Looking around the room this morning, I see many young faces, raised with multi-tasking as the norm. I think you need to update your thinking.

Oh dear. When I read this feedback, I was sure this was an unseasoned manager, assuming he/she was encountering these problems for the first time. Unfortunately, multi-tasking has been around since people had more than one thing to do

In a recent Software Development article I discussed the true costs of multitasking (as have Hal and Esther and I in our blogs). This manager doesn’t seem to understand the costs; he/she sees the apparent completion of work.

As I reflected more on this, I realized that I believe each manager has the job of prioritizing the work as his/her first role. If you know what you’re supposed to deliver to the organization, you can select the people and organize the work to succeed. If you never choose what to deliver to the organization, you can never fail as a manager. Of course, you can never succeed either, because there’s always too much to do. But you can certainly never fail. Until the whole organization fails.

Managers who never reassess their work prioritization are inadequate managers. Managers who take on the work the organization requests (or demands) and who don’t prioritize are inadequate managers. Organizations that don’t rank their work will fail.

If you’re a manager, first prioritize your group’s work. Then assign it. Monitor the flow and the organization’s priorities. It’s not easy, and it’s necessary.

My Stickyminds column this month deals with choosing when to start and end project overtime, “When Should You Start Project Overtime?”

Frank Patrick has already chimed in with one of the common causes of overtime, multi-tasking. See Multi-tasking Multiplies Lead Time

Also see these blog entries from Esther Derby and Hal Macomber. A note: I think Esther, Frank, Hal, and I blogged bunches of entries about multi-tasking in March, which is why I referenced Esther’s March archive.

Please do read the Stickyminds column, and post your comments. The more, the merrier.

I’m a fan of nightly builds with automated smoke tests, run overnight. In the morning when everyone returns to work, anyone who’s broken the build fixes it. In most cases, the developers see what they did and they fix it. The agile folks take this even further and say to build the system whenever you’ve made a change and verify the changes immediately with your pre-written tests. That works too, and you have to have set up the system initially to be successful with being able to build small pieces that hook into the rest of the product, once the product is substantial.

I recently met some other folks who take 1-2 weeks between builds, and then it takes them 1-2 weeks to settle the software down between builds. This quickly builds up technical debt, and the debt can be so overwhelming that it takes more than half the developers’ time to fix the debt.

Here’s why. When developers have a chance to see why they made mistakes when their reasoning is fresh in their minds (building whenever you make a change, or at the longest, once a day), they have close-to-immediate feedback about their work. The longer the feedback takes (1-4 weeks is a very long time), the developers have forgotten why they made those decisions initially. Fixing problems in large systems becomes more of trial and error rather than systematic fixing, because the developers have lost the context of what they were thinking.

This is another case of multi-tasking (Hal just wrote about this, Esther Derby wrote about multitasking as have I in previous posts. My next SD article is about multi-tasking.)

Software development (or software testing, or project management, or any other knowledge creation work) is context dependent. If you change your context often enough, you can’t remember what you were doing or why. Then you make mistakes.

For builds, make the time between builds as long as you think you can go and still throw away all the work you did for the previous build. So the faster you want the project to go, the more frequently you need to build. If you have a lot of time, or don’t care as much about predictable schedules, you can take a few weeks between builds. (When was the last time that happened??)

If you’re in a tightly scheduled project, build at least once a day. That way if everything you did the day before was garbage, you can throw it out and only lose one day. Building twice a day is even better. Building every time you make any change at all is best. But no matter how you think about it, build fast to fix fast.

After my presentation last night at the Detroit PMI chapter, an attendee asked me, “Is context switching really as bad as you say it is?” Yes, it is. I believe Weinberg’s estimate of losing 10-20% of possible work-time every time you attempt to take on one more project. And, if you read Hal’s entry today, “Multi-tasking resources in contention is a principle source of throwing a project out of sequence.”

So if you’re faced with too many distinct projects, what can you do? I started to answer this here. But there’s more you can do:

1. Verify you understand the relative importance of all the projects you’re working on.
2. Verify all your work should be done.
3. Estimate how long each set of tasks will take. Bunch as many tasks together as possible.
4. If you can, spend a week on each project, so you can make progress. If you can’t spend a week, allocate days to projects. If you can’t allocate days, allocate mornings or afternoons. If you can’t do that, find another job, because this company won’t be around long enough to pay you.
5. Track your task estimates. If something starts taking longer, take a few minutes to determine why. Do you need help? Are you capable of performing the work? Could you work faster if you work with someone else?
6. If many of you are stretched over too many projects, consider pairing. Pair-work with someone on two projects, working on each one at the same time. If two of you work together on one project at the same time, you can make more progress than each of you working separately.
7. If you’re a manager, learn about project portfolio management, especially about when to fund, initiate, and staff projects. If you’re a technical person, discuss project portfolio management with your manager. Your manager may not realize what he/she is asking you to do.

Whatever you do, make sure you don’t let the context-switching and multi-tasking continue. The more spread you are, the less effective you are.

I’m at the Software Development conference this week. One of the hot topics I discussed in my presentations and with attendees during and after the talks were about context switching and multitasking, Focused Performance and Breakthrough Thinking on Worker Productivity and Multi-tasking Makes you Stupid, studies say.We agreed that:

• several pieces of work at different levels causes problems (defects in code, inappropriate project plans, etc.)
• too much work, when you try to work on it simultaneously, causes you to make no discernable progress on anything

But, you’re a development/test/project manager. You have too much work to do, and not enough time to do it. What do you do?

1. Make sure you know your boss’s priorities. What does he need now? Too often the boss says everything, in which case, go to #2.
2. What is strategically important for the company now? Note that this is not strategically important for your group, but strategically important for the company. Talk to your boss, yes, but then focus on what helps the company most.
3. Kill the projects you need to kill. Too often we have too many projects hanging around, or products we support because we always have. Stop that now, and only support what is strategically important.
4. Work on things that bring in revenue (or contribute to revenue) now.

Another piece of multi-tasking is to “create” more time in your day by:

• not attending meetings you don’t need to attend
• allowing interruptions from voicemail, email, pager, cellphone, and blackberries at specific times, not when the interruptions come in
• allowing people at the lowest level of the organization make decisions about their work, so you can make decisions about your work.

I’m still thinking about this, so I’ll try to post more helpful hints later this week. (Especially once I get my connectivity worked out.)