During my Lean Software Development talk on Wednesday, I got into a small tangent about one of the 7 wastes of Lean: Task Switching. In the world of software development, this means multitasking. Much digital ink has be spread about the waste that manifests from multitasking. When going through a production process, this multitasking does extra harm because it makes the overall process susceptible to delays and delivery slippage.
I used the following example to bring the concept home for software developers. Let’s say you have 3 tasks, A, B and C. Each task takes 8 hours to complete. If you did them a half at a time, the resulting delivery would look like the below:
So it takes 24 total hours to complete all three tasks. No surprise there since 3 * 8 = 24 hours. However, it actually takes 16 physical hours to deliver each task. For example, 4 hours for the first part of tasks A, B and C and then another 4 for the second half of task A. That’s twice as long each task would individually take:
In the second example, any process or task depending on task A can get started a full 8 hours sooner than in the first example. That can result in a huge gain in throughput for your team or project. This is also assuming that there are no delays in delivering each task. If they are delayed for any reason, suddenly you’re staring down the barrel at a 200%+ delay for delivery than the second example. It also results in smaller units of work, which we’ve already discussed is a great thing.
So the next time you’re planning out individual tasks, think about how you can break them down into the smallest, deliverable chunks you can. This will enable you to churn out smaller, more functional pieces quicker and with great precision.
