The Art of Distraction (and How More Stories Doesn’t Mean Better)

I got a little distracted trying to write this. I’ve regularly wondered why it is SO HARD to focus and get something relatively simple done. I now have my answer. I was listening to NPR and wouldn’t you know, a discussion about distraction came on. The topic of the podcast was that every time something distracts you, it can take up to 30 minutes to re-focus and be productive again! (Hear more of The Hidden Brain podcast episode "The Cost Of Interruptions: They Waste More Time Than You Think"). But why is that important in software development and testing?

The Distracted Scrum Team

Imagine you are on a scrum team. You have agreed to stories for your sprint, and it looks like you’re going to get a lot of features delivered! Unfortunately, you haven’t looked at frontloading quality and really owning it as a team. Your engineers tend to just say “We’re done” and leave the testing to QA, handing off fairly buggy code for testing, and then move on to the next story. This really just turns into a lot of Work in Progress (WIP). So you start working on the next story as QA tests what you just “finished”, and bugs start coming in. You have to switch contexts to fix those bugs, and then switch back to the story once you think the bugs are fixed (as you wait for QA to verify them, again, without having tested the issues yourself).

Now imagine that you have done this for sprints. You have to pull in bugs from the last sprint (or earlier). You’re not only looking at current sprint work, but you also have to remember something you worked on maybe a few weeks ago. You have several things going on at once. And what should be razor-focus on one story has now turned hazy because you have too much WIP. Focus!!! Leonhard Widrich wrote a great article about the 8-hour workday (read it at Huffington Post). What was really interesting to me was his summary from a study by Justin Gardner on what your brain really does when you are trying to focus and there are distractions. Let’s take a look at an image from Gardner’s study that shows a brain focusing on a target without distractions (in which the target stays in sharp focus as shown in the box on the right), and a brain focusing on a target with several distractions (in which the target is not as clear).

Image Source: http://www.riken.jp/en/pr/press/2011/20111208/
Image Source: http://www.riken.jp/en/pr/press/2011/20111208/

Widrich summarizes the figure above as follows:

In figure A, as the brain is presented with only one task, we are able to separate out distractors (blue) from what's actually important (yellow).

In figure B, when we are presented with multiple tasks at once, the brain is increasingly easy to distract and combines the actual tasks with distractors.

The key conclusion that Gardner suggests from his study is that we have to both:

  • Stop multitasking to avoid being distracted in our work environment.
  • Eliminate distractors even when only one task is present

In a scrum context, how can we have crystal clear focus on a story if we are working on others at the same time? A good way to illustrate this is to play some Agile Games! One of my favorites is the Name Game (try it!)

The Focused Scrum Team

The good news is that some key Agile principles can help a distracted scrum team turn into a focused team. Here are some key points that can help keep you focused:

  • It is far better to complete only one quality story than half-complete 20. You must also consider that complete means testing is done. If you have a story in progress and want to start another, consider what else you can do to get that story done. (See Greg Sypolt’s post What is your Definition of “Done”?). Since the team takes ownership of quality, you may need to consider helping with testing.
  • The highest priority is completing stories that are already in progress (over starting new). Stay focused! It feels REALLY good to close a story out. Can everyone pitch in to help get it done? Really try to do that before you consider starting a new story.
  • Your individual work on a story or bug is not done until the issue is closed. Just because QA has started testing does not mean the developer is done. Done means all bugs for that story are fixed and verified.
  • If you are not actively working on a task for a story/bug, you should be monitoring and pestering others about it. Help drive your team to done! Is there testing remaining? Help test! Your QA team is there to help facilitate and drive the quality, not the sole person that can do the actual testing. Pitch in!

Let’s move away from the idea that a lot in progress is progress. Get one story done, then another. Stay focused!

Ashley Hunsberger is a Quality Architect at Blackboard, Inc. and co-founder of Quality Element. She’s passionate about making an impact in education and loves coaching team members in product and client-focused quality practices. Most recently, she has focused on test strategy implementation and training, development process efficiencies, and preaching Test Driven Development to anyone that will listen. In her downtime, she loves to travel, read, quilt, hike, and spend time with her family.

--- Below the Fold ---

I sit down to write. Feeling focused. I type: The Art of Distraction... Ding! Email! Ding! Joe is following you on Twitter! Ding! Greg likes your Facebook status! Oh I wonder what he’s up to? Oh look, Rachel likes this recipe, hmmm… that looks good! What should I make for dinner? OMG Laura’s baby is so CUTE! LIKE TIMES A MILLION! I look around, oh wow — Laundry exploded all over my house, I should probably fold that. I’m hungry, I need a sandwich. An hour later, I still just have my article title.

Written by

Ashley Hunsberger

Topics

Agile DevelopmentFrameworks

Categories