In this article, I introduce a simple, killer idea to boost a software team’s productivity. It’s incredibly easy to implement, plays to the strengths of management and software teams alike and produces noticeable improvements almost immediately. All software teams should be doing this but, most aren’t.

Regular readers of this blog will know that I’m a big advocate of boosting the performance of software development teams. In my travels around the UK and Europe, I come across organisations that suffer from one simple issue that reins in their software development productivity.

That issue is context switching (or, task switching).

It’s an evil, insidious leech that vacuums valuable time and productivity from software development teams. And it doesn’t have to be this way. The fix is simple. But let’s look deeper into the problem.

The True Cost of Context Switching

Far more intelligent people than me have been commenting on the evils of context switching for some time.

• Joel Spolsky, the much respected blogger, who runs his own software company, has been writing about context switching for years
• Jeff Atwood, another respected software development blogger had this to say on the topic of context switching
• Still not convinced? Then try this reference from Gerald Weinberg on Quality Software Management : Systems Thinking

Oh, you don’t have the book? Let me offer an edited highlight:

In real terms, if your development team are working on two projects simultaneously, you’re only getting four days work a week from them. You’re wasting 20% productivity. You’re wasting 20% salary. You’re wasting 20% time.

Guess what happens when we add another project to the workload of the software development team? Another loss.

The graph is from the Quality Software Management reference. It states clearly that, with five simultaneous projects on the go, a software development team can only allocate 5% of their productive work time to each project. That’s 25% productivity total.

If you’re reading this thinking that these are just made-up numbers or nonsense, I encourage you to do some independent research. You’ll find that the evidence is out there and it’s real. Thankfully, there’s an easy, and obvious, way to solve the problem. Stop multi-tasking.

If you’re thinking “that won’t work in my organisation”, you’re not alone. I come across that belief a lot and then spend a little time breaking this down into real numbers and dates. Here’s how it usually goes.

Multi-Tasking on Projects is a Sign of Indecision

The most common reason I come across for teams running multiple simultaneous projects is a lack of management decision on priority. If a software team are working on multiple products, it’s because management can’t decide on relative priority and so, to keep everyone happy, they work on all of them. This surprises me because I’ve always believed this simple axiom:

My earnest advice to all managers out there is to devote time to deciding on the relative priority of your projects. This is a healthy activity and it will pay back the investment in time many fold. Here’s an example:

A Tale of Two Projects

Let’s take the simplest case. A software development team working on two projects simultaneously. Let’s say each project is estimated to take 8 weeks to complete. If we work on them simultaneously, we get this:

I’ve calculated the above in the most efficient way for the multi-tasking scenario. That is, two clear days on project A before switching to project B. Here’s how it works out:

Multi-Tasking

Single Tasking

Here’s how it looks for three projects, each of which is estimated to take 4 weeks:

Multi-Tasking

Single Tasking

The only thing that multi-tasking gives you, is the impression that each project is progressing. While this is true, the cost is enormous as the context switching cost shows. Additionally, each project will be delivered much later than if we single-tasked.

Hopefully, this will convince anyone of the need to concentrate on one thing at a time.

Next Steps

As I said at the outset, there are huge productivity gains to be had and achieving them is a very simple two step process:

That’s all there is to it. Give it a try and watch productivity improve. If you don’t think you can get it to work in your organization, contact me. I’d be more than happy to help.