Multi-tasking Mayhem

One of Scrum’s rules pertains to the purpose of each Sprint, which is to deliver increments of potentially shippable functionality that adheres to a working definition of “done.”

Scrum Guide: http://www.scrum.org/scrumguideenglish/

A few weeks ago I was part of a small team creating an Agile training course for our Product Group.  The one-week time-boxed effort was broken into 5 one-day Sprints - we were going to eat our own dogfood and create the course using the Scrum framework.   For our second Sprint, day 2, I volunteered to implement a couple fairly involved stories from our backlog, each requiring me to create a dozen or so slides with associated training notes.  A accomplished multitasker, I dove into the effort, working on both stories concurrently.  Late afternoon I suddenly found myself in the final hour of the Sprint with both stories more than half complete, but neither story Done!  A bit of panic set in as I contemplated my mistake:  if I had worked on the deliverables sequentially, I’d have easily completed at least one Story, come Sprint review time.  As it stood then, I might not have anything done.   I felt momentarily paralyzed by my situation and realized that I’d have to put in extra effort to get the work done in time.  I also realized I had a great topic for my next blog, so all was not lost!

The ability to multitask is often viewed in the workplace as a positive skill:  the ability to juggle and deliver multiple competing priorities in an increasingly complex and dynamic business environment.   However, numerous studies have shown that multitasking only gives the illusion of enhanced productivity, when in actual fact, working on more than one task at the same time often results in less actual productivity!  According to Psychology Today “the mind slows down when it switches back and forth between tasks”.  Each time you switch to a new task you must gain context on the new task while losing some context on the task you left behind.   A Stanford study suggests that when you are switching between multiple tasks, you “couldn't help thinking about the task [you] weren't doing”, leading to a further drop in productivity.

My take-away from this is two-fold:

1. Teams (and individuals) should work on one story/task at a time and deliver on stories sequentially.   The prioritized Product Backlog and Sprint Backlog should is the artifact that focuses the Team.

2. Management should respect the Team commitment (of course!), keep team members 100% dedicated to the Sprint and do whatever necessary to eliminate competing priorities.  When competing work is discovered, the work should be added to the Product Backlog and prioritized by the Product Owner.

Focusing one one story and completing that work before moving on to the next, Scrum teams (as well as individuals) will deliver more work.  Sometimes you have to go “slow” to go fast.