In this article, I introduce a simple 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.
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: Adding a single project to your workload will drop productivity by 20%
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 productivity. You’re wasting salary. You’re wasting 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: 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:
- 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
- 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:
- 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
- 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 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.
As I said at the outset, there are huge productivity gains to be had and achieving them is a very simple two step process:
- 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
- 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.
The Turbo Scrum Course
This is just one technique of over 30 that I cover in my Turbo Scrum course. This course is designed for anyone involved in software development that wants to get more productivity from their software endeavours.