Food, Attention Deficit and Context Switching

“The art of eating your work.”

Okay, had a stray thought while eating breakfast one fine Saturday morning.  It dawn on me that in today’s twitch generation, many people have fallen victim to the dangers of attention deficit and context switching.

Attention deficit (AD) is chronic condition including attention difficulty, hyperactivity, and impulsiveness.  It’s where you have trouble focusing on one thing for a long period of time.

Context switching (CS) is the case where you are interrupted (either externally or internally) with your work and switch to something different.  In the process of switching, Gerald Weinberg proposed in “Quality Software Management: Systems Thinking” that for over 99% of people, it decreases productivity, starting at 20% by adding one more project.

context switching

Both AD and CS go down to even emailing and talking on the phone at the same time or working on a task and then checking LinkedIn or Twitter for a post updated to you.  For me, I’m a victim of wanting to check an email or switching between the remembering of a task and then wanting to switch to that now in order to get it done before I forget it again.  Often, I have to re-remember what I was doing in the first place!

So it dawned on me that I should be approaching work like I approach eating.  I eat one thing at a time.  I focus on eating until done and I cannot stand wasting food.  I won’t stop until I’m done.  Every so often, I’ll run out of time to finish, so I just save the food and then finish it later.

My eating habits are certainly mine and everyone has their own, but consider picking up your best habits and applying them to your work, whether it is for eating, watching the Lord of the Rings / Hobbit marathon or playing basketball.

What I’ve found to help my modern day “ooh shiny” syndrome be held at bay are through the following techniques:

  • “Stop Starting and Start Finishing” – A great slogan from the Limited WIP Society and the idea behind Kanban.  Using Kanban boards, whether personal and / or professional can really help decrease context switching
  • Turn your notifications off! – Phone notifications, email, alarms, alerts, etc.  Create a period of no interruption in advance and close your door, shut yourself out.  This is not possible if you are tech support, but you can at least minimize the noise and clutter of all the devices you programmed to bother you on a daily basis
  • The Pomodoro technique is fabulous way to place structure into your work day.  You get 25 minutes of focused time with an actual timer where you are not allowed to have interruptions.  If you do, you are supposed to write them quickly down and move back to your task.  If the interruption is urgent, then the pomodoro must stop and you have to begin from the start again to continue.  You get a 5 minute break to take care of the shiny objects and then start again, doing a set of four time in which you get a 25 minute break

These methods help combat attention deficit and context switching, but I’ve found that treating my tasks like food has made doing these “a piece of cake”.

Root Cause Analysis – Core Competency

Related to removing impediments is the skill of identifying root causes, typically called Root Cause Analysis (RCA) within the technical world.  Some Project Leaders (be it a traditional Project Manager, Scrum Master or something in between) may believe that RCA is really a skill that the team has full ownership and that the Scrum Master should simply connect people with the right resources to either swarm or focus on the right path to resolution, but believe that approach is short sighted.

An experienced Project Leader will be like the Larry King of root cause investigation, asking questions to determine the signs of where a root cause may be found.  Project Leaders should help “connect the dots” like Steve Jobs has been famous for saying in his Stanford Commencement address in 2005 (http://news.stanford.edu/news/2005/june15/jobs-061505.html).  Connecting the dots isn’t just about product vision or strategy but finding the missing part that is blocking the team from completing the blocked task.

Confident many reading this are already thinking along these lines, so I’ll state that there are times with the Project Lead will have no clue about the root cause and should instead play the role of observer so they gain more experience on helping identify trends for future issue resolution and impediment removal.

The Art of Removing Impediments

Been noticing in my career that one skill set Project Managers / Scrum Masters should master, but often don’t is the art of removing impediments.  This is not an easy skill to master and requires curiosity, courage, diplomacy, tenacity and a little bit of creativity and communication.

Often removing impediments involves connecting the right people together.  It is typically a social problem.  Yes, going to Uncle Google or Father YouTube certainly helps with any issues that plague people  the time like, “why doesn’t my OneDrive show up on Windows File Explorer”, but often with teams, these are very specific and challenging issues that won’t have an apparent answer on the grand Internet.

A true leader, whether a “command and control” leader or “servant leader” or something in between should have the curiosity to always be asking and encouraging the delivery team to bring up impediments that impact a person or the team within a short period of time.  I’ll usually state, “come see me in an hour if you and your contacts haven’t been able to figure out a solution to a given issue stopping you”.  However, the expected escalation time frame is really specific to the situation of the team, the project and the company, so use your best judgment, knowing that many team members will stretch the escalation time if they think they are close (but may actually not be even in the same planet).

Also, a project manager should have the courage to ensure the team is following the guidelines on requesting help and be willing to take ownership of resolving that issue with a high degree of urgency.  Project Managers should do anything within their power to help team members as fast as possible, but also show diplomacy, recognizing people’s time and always making them feel respected and important through the addressing the issue.  Project managers have to deal with the human microcosm of tradeoffs and ensure that those that help resolve the issue get the recognition deserved and also in turn be helped when they are in a time of need.

Tenacity is a necessary core skill a project manager must possess to resolve any team blockage as soon as possible.  Don’t ever give up, especially when you feel like it is hopeless.  There is always a solution, given enough time and thought.  That leads to creativity since the solution may require a different approach than initially expected.  The project manager should encourage the team and any parties that get involved to be educated on the nature of the issue and think through every possible path to resolve the problem.  This requires that tenacity to ensure no one feels like throwing in the towel.

Dual Track Scrum Summary

In my previous blogs of Dual Track Scrum (DTS), I cover the current expansion of Scrum to place more attention on building the right product through the means of a detailed, continuous discovery process tailored for developing better backlogs through multiple tools and techniques, such as story boards, feedback groups and surveys.  This is tracked through a separate discovery backlog similar in usage to the product backlog and feeds the results into improvements in not only the accuracy but the certainty that the right backlog is in place.

This overall discovery backlog (or also called the Opportunity Backlog) should address the pains of the target users, remedies to resolve/alleviated those pains, experiments to validate those remedies and any ideas and further options for product development.  It is very user centric, intended to identify those features that will delight users.  For instance, like many people I use my smart phone to deposit checks.  I used to get frustrated by having to deal with poor lighting or poor focus for the checks and would often have to take multiple pictures to get one to take.  Now, the Bank of America app came up with a version that turns on your phone’s light and auto sets the box so that when you have it at the right place, the app automatically takes the picture for you.  Viola!  Instant gratification!  This is the type of feature that I wanted, but hadn’t expressed.  Bank of America did a good job finding out a chief issue I had with electronic deposits…

home_MobileDeposit

I see two primary benefits with Dual Track Scrum:

  1. Increased confidence and improvement of delivering the best product to increase end user adoption
  2. improved handover of the product backlog to delivery

Note if your solution is strictly regulated and have little leverage to change or delivering in more of a waterfall fashion, this may seem like an improbable approach, but would say in my experience in for example the Health Care industry and Government, that the usability of regulated systems are in the most need of Dual Track Scrum.

With regards to the benefit of improved handover, it will directly address the issue many organizations have early in their Agile adoption and essentially break out requirements development, architecture and development/testing into an mini-waterfall process, which breaks one of the few core tenants of scrum of having fully tested, working software at the end of each sprint.  When the product backlog is unclear and backlog grooming isn’t sufficient, often delivery will slow down unless a more thorough approach such as DTS is substituted.

This often happens when a Product Owner is overwhelmed or simply not certain where to take the product next.  Often, I’ve seen Product Owner training for newer Product Owners unfamiliar with Scrum, and that would be a good supplement along with DTS.  Identifying and addressing insufficient Product Owner coverage early in delivery is critical for the successful implementation of DTS.

Cost and time are factors involved and often an approach such as Dual Track Scrum will be sacrificed or not even considered due to those limits.  Every situation is unique, but highly recommend considering using as much of DTS as possible even if “watered down” with the frequency of discovery sessions held is decreased.  Why?  Because cost and schedules will inevitably deliver an inferior product and assumptions with delivering your Minimum Viable Product should be validated frequently.

So if you aren’t sure your solution truly addresses your user’s needs or your scrum teams are frequently frustrated with extended user story elaboration and prolonged marathon Sprint Planning events due to nebulous product backlog items, then try Dual Track Scrum is worth trying and remember to fail (and learn) fast!