One Simple, Killer Idea to Boost Software Development Productivity

13 May

fastIn 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.

 

If you prefer to watch, rather than read, I’ve made a short video that covers the issue and how to resolve it.

CONTEXT SWITCHINGRegular 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, 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:

Adding a single project to your workload will drop productivity by 20%

Bit of an attention grabber that one. 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.

ContextSwitching

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:

If everything is top priority, then you have no priority

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

  • Project A delivered 19 weeks and two days after work started
  • Project B delivered 20 weeks after work started
  • Context Switching cost 4 weeks since work started

Single Tasking

  • Project A delivered 8 weeks after work started
  • Project B delivered 16 weeks after work started
  • No Context Switching cost

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

Multi-Tasking

  • Project A delivered 19 weeks and one day after work started
  • Project B delivered 19 weeks and three days after work started
  • Project C delivered 20 weeks after work started
  • Context Switching cost 8 weeks since work started

Single Tasking

  • Project A delivered 4 weeks after work started
  • Project B delivered 8 weeks after work started
  • Project C delivered 16 weeks after work started
  • No Context Switching cost

The only thing that multi-tasking gives you, is the belief 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 that 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:

  1. Prioritise your projects. I know this may not be easy and I won’t pretend to understand the politics of where you work. But, if you’re convinced you can boost a software development team’s productivity, it’s time to put your diplomacy skills to work and establish priority.
  2. Have your development teams work on one project at a time until they’re done. And by ‘done’, I mean completely done.

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.

Share and Enjoy

  • Facebook
  • Twitter
  • Delicious
  • LinkedIn
  • StumbleUpon
  • Add to favorites
  • Email
  • RSS

2 Responses to “One Simple, Killer Idea to Boost Software Development Productivity”

  1. Nick Zdunic 13 May 2014 at 12:47 pm #

    Great article. Succintly,simply stated. I like to use the multi tasking name game in my training to illustrate the point. Kniberg came up with that.

    • dd 14 May 2014 at 9:38 am #

      Hi Nick

      I’m glad you liked the article. I love some of the stuff that Henrik Kniberg comes up with too. A great guy in the agile community.

Leave a Reply