Alternative project management styles are faster than multitasking

Rather than rely on multitasking, project managers should focus each team's efforts on one project or iteration at a time.

I bet you've heard this a million times: If you have too much work to do, just pile more things on -- multitask.

But that happens to be very bad advice. There is research that tells us that multitasking actually makes us stupid. See Michigan University's research on the subject for references.

Johanna Rothman, project management expert and authorJoanna Rothman

The problem is that we are not computers. As humans, we don't actually process more than one task at the same time. We only fast switch. And, because we are humans, we need to swap out what we are doing now, and swap another task in. When we are done with the second task, we attempt to swap the original -- or worse, a third task in -- and, if we are lucky, we remember everything about the state we were originally in.

But, we rarely remember all the original state. Or, more likely someone else changed the state when we weren't looking. It's almost like reading a book on your Kindle, but not connecting it to your network, and picking up the same book later on your iPad. You know you read past that point, but you can't quite remember where you left off. It's a similar problem, but with very different consequences.

Slowing your reading is one thing. Slowing your project is totally different. Multitasking is the fastest way to slow your projects down. But what can you do? Don't you have to multitask to get the work done?

No. You have several alternatives, especially if you work as part of an Agile team. Let's explore some of them now.

Commit to one project for this iteration

The best alternative, if you can manage it, is to commit to just one project for the duration of the iteration. This is called project portfolio management. Some group of decision makers in the organization decides which project is number 1, which project is number 2, which project is number 3, and so on down the line. They assign the projects to the teams and let the teams know the rank order of the projects.

The reason the teams need to know the rank order of the projects is because it lets team members know whether it's worth it to interrupt another project or not. If a tester is working on project number 3 and wants to interrupt someone working on project number1, he or she might wait until lunch time or might send an email. But, the worker on project number 3 would wait with the question. IT would not be okay to walk over or IM the worker on project number 1 with an interruption because the question will create a context switch for that person, and a question about project number 3 is not as important as the number 1 project that person is working on.

When the person on project number 1 has a free moment -- and that person will, during the day -- that person will check email, or break for lunch. At that time, that person will have the mental cycles available to answer questions about lower priority projects or at least send the asker in the correct direction to their own question.

Committing to one project for the iteration, and explaining to each of the project teams the rank order of the projects is the single best alternative. However, it's not always possible. In that case, Agile teams can commit to one feature at a time.

Commit to one feature at a time

Even if management cannot commit to one project at a time, the Agile team may not be too hard hit because, as a team, they can commit to one feature at a time. The team can swarm over one feature because they have a ranked backlog. They commit everyone on the team to one feature at a time.

When the team reduces its work-in-progress by taking just one feature at a time, everyone focuses on that one feature. Everyone says, "What can I do to move this feature forward?" Even largish features get done faster when teams swarm.

This works well for teams who are collocated. But not all teams know how to swarm or are collocated. In that case, a team can make sure they leave room for interruptions in the iteration.

Leave room in the iteration for interruptions

It would be great if each iteration could be full of features, but that is rarely the case. There might be a legacy product where there is technical debt to pay off. Or the organization may be responsible for support of a previously released product, as many of my clients are. Even if the managers decide on a new project portfolio, the teams still have to support previously released products. There is no separate support group. So, the teams leave room for support or other interruptions.

When the team estimates what they can complete in the iteration, they collectively consider how many features they can finish. Is the team full for the iteration? If so, they have to back off the estimate and leave room for the average number of support requests. If they have gathered data in the past, they know approximately how many support requests they can expect over the course of an iteration. Support requests are somewhat similar to stories, and the team will need to leave room for them in the iteration as if they are stories.

Maybe as the team pays off technical debt, they will have fewer support requests, but not always. It depends on the type of support requests you receive and the type of debt you have. The good thing about Agile is that you will have the transparency to gather the data you need to see what decisions you might need to make in the future.

You can do it all -- but not at the same time

Sequencing your work in a reasonable order is something we do all the time. We make easy decisions from the time we awake in the morning: Do you brush your teeth first or eat breakfast first? As long as you do both and get yourself to work, does it really matter? No. But you cannot both brush your teeth and eat breakfast at the same time. That doesn't work. When I use that example it seems silly, doesn't it?

It's the same problem with knowledge work, except the consequences are worse. We fool ourselves into thinking we accomplish more. The reality is that we accomplish much less when we attempt to multitask. We slow down each of the multitasked projects. We lose bits and pieces of critical information. We become frustrated with our inability to finish anything.

Instead, if we manage our project portfolios, and decide -- even if just for an iteration -- which project is number 1, and finish some features, we feel a sense of accomplishment. That feeling allows us to make more progress in the next iteration.

Remember, it doesn't matter how many projects you start. It matters how many projects you finish.

Johanna Rothman is the author of the Jolt Productivity award-winning Manage It! Your Guide to Modern, Pragmatic Project Management and Manage Your Project Portfolio: Increase Your Capacity and Finish More Projects. She has more information about avoiding multitasking and what you can do in both of those books. You can read more of her writing here.

This was first published in June 2013

Dig deeper on Building Software Project Teams

Pro+

Features

Enjoy the benefits of Pro+ membership, learn more and join.

4 comments

Oldest 

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

SearchSOA

TheServerSide

SearchCloudApplications

SearchAWS

SearchBusinessAnalytics

SearchFinancialApplications

SearchHealthIT

Close