The horrors of context switching (and how to beat them) – Part 2

Part Deux

The first post on this topic covered many of the ways that context switching can destroy the productivity of your day but most of the post was aimed at developers.  This one reaches out to everyone that works in an office.  Scott Adams has made a career out of ridiculing the pointlessness of workplace politics.  In no setting is this ridicule more pronounced than the pointless meeting.

Agile best practices

Multitasking meetings?

Have you ever been in a meeting and looked around the table while someone is giving a presentation?  What do you see?  Too many times I would see a scene like this:  John is looking at his phone, Betty is trolling the web while Michael is writing on a post-it in front of Margaret.  Sound familiar?  Exactly, the workplace has regressed back to fifth grade.

Agile best practices

Even worse, I once had a CEO that would regularly take phone calls from his wife while we were in a meeting and would talk with her on the phone for a good 5-10 minutes while everyone would be sitting there waiting.  Sometimes, he would even lapse into baby talk.  It was a fantastic use of time.  This happened in executive leadership meetings all the time.  Let’s look at the economics behind this.  If he took a call with eight of us in the room, each of us making an average of $250/hr, each 10 minute phone call he took would cost the company roughly $500.  This accounts for the 5 minutes it would take for us to get back to where we were in the meeting.  Granted, this guy was a world class asshole but these types of things happen all the time in meetings across the globe.

Luckily, there is a cure for the pointless meeting.

7 tips for a productive meeting

The best way to deal with distractions if these are your meetings is to be honest with your teams.  Be very clear that you are not going to waste their time but be just as clear that you will not tolerate them wasting yours or other people’s time.  When people aren’t paying attention, most of the time it is because they are not engaged.  That’s on you as a leader.  These are 7 tips that I have found to be incredibly effective for holding a highly engaged meeting:

  1. Have an agenda and stick to it
  2. ONLY invite people that can contribute to the topics on the agenda
  3. Lids down.  Phones down.
  4. Start on time
  5. Don’t take up the full meeting time if you don’t have to
  6. At the end of the meeting ask the attendees if they thought it was productive or not
  7. Write down action items and send them out with a summary after the meeting

Make it about respect

The strongest statement you can make that the meeting will be productive is to have an agenda.  Having an agenda means that you have enough respect for your team that you prepared in advance.  If it is not your meeting, it is perfectly acceptable to ask what the agenda is.  If the leader of the meeting doesn’t have one, make sure you get that person to cover the points they hope to get done in the meeting before the meeting starts.  I’m at a stage in my career that I will typically leave a meeting if there is no agenda.  The end result of this action is that I either don’t get invited to, in my opinion pointless, meetings or the leader of the meeting puts together an agenda before inviting me.

Always run the numbers

Run the numbers.  If somebody is not going to be contributing in the meeting and you invite them to it anyway, ask yourself, how much do they make an hour?  If they’re not contributing am I willing to burn $100 of the company’s money to have them there doing nothing?  Many times people are invited to meetings not to contribute but just so they don’t miss out on information being passed in the meeting.  This is a terrible use of their time.  A simple summary email once the meeting is over is far more effective and will not require context switching.

Once the agenda is briefly covered, expect all participants of the meeting to be engaged.  The best way to enforce this is by asking for lids down and phones down.  It is far more difficult to be engaged if the distraction of a laptop or a phone is staring you in the face.

Start your meetings on time.  Do not wait for stragglers that are rolling in late.  Start on time and either end on time or end early.  Respect your people by treating them like adults.  If somebody rolls in late, let them catch up on the topic in their own time.  Do not keep stopping the meeting to fill folks in on what they missed.  That’s a waste of everyone’s time.  Even if it is somebody who is higher than you in the corporate hierarchy.  If somebody asks for a summary after showing up late, you can handle this with tact.  Say something along the lines of, “I’ll be happy to fill you in later but with respect to everyone’s time we need to stay on topic.”

I used this approach with a former COO of mine.  This COO would roll into every meeting 5 to 10 minutes late.  I could tell he was annoyed with my approach but, very professionally, he waited until the meeting was over to let me know.  He explained that he was incredibly busy and that most other meetings he had ran over.  I let him know that I understood that frustration but then I went to the numbers.  If I interrupted the meeting every time someone came in late, I not only risked disengaging the rest of the team, but we would be forced to go off topic, then context switch back to the topic on hand.  If there were 10 people in the room each making roughly $100 an hour, that 5 minute interruption costs almost $100.  If we do that twice a meeting, it starts to get very expensive.  The other point I made was that if I only were to do this for him because he outranked me, I would be showing my team that we have two different standards in the company in regards to respecting people’s time.  We would basically be saying that it’s ok to waste other people’s time as long as you outrank them.  To his credit, he just nodded.  I would love to say that after that conversation, he was never late to a meeting but that just wasn’t true.  He never asked me for a summary again however.

When you get through your points, end the meeting

Once you are through with the agenda, END THE MEETING.  Nothing is more infuriating than having a leader of a meeting look at the clock and say, “Oooh look, we still have 20 minutes left, let’s try to get this done too!”  Why is that so infuriating?  Because of tip #2.  You put the attendees of that meeting together ahead of time to contribute to the topics on the agenda.  Once you go off of those topics, somebody, if not everybody will feel like you are wasting their time.  Ending early is a sign of efficiency and your team will respect you for it.  Throwing pointless filler in at the end of a meeting is a waste of resources.

Incorporate the feedback loop.  At the end of the meeting ask the group if they thought the meeting was an effective use of their time.  Make sure you get an answer from each attendee.  It is critical that you are open to this feedback or else it just comes across as lip service.  If an attendee says they think that it was an ineffective use of their time, make sure you get them to give you a couple of ideas of how they would make the time more effective.  If the majority of the attendees say the meeting was an ineffective use of time, you need to be ok with cancelling similar future meetings especially if they are scheduled weekly.

Finally, make sure to write down the action items that come up during the meeting.  When the meeting is over, take five minutes to write up a summary that gets sent out to the attendees and anyone else that needs to know what was discussed in the meeting.  This summary should also contain the action items that came out of the meeting.  This is critical because this is a written record of the commitments that people made in the meeting.

Conclusion

I would say that at least 60% of all meetings are a complete waste of time.  Not only do you lose the time that is spent in the pointless meeting, you also lose all the time around the meeting when you have to context switch and try to get back in the flow of what you were actually working on.  It doesn’t have to be this way:

Agile best practices

Advertisements

The horrors of context switching (and how to beat them) Part 1

Context Switching

Context switching is the bane of productivity.  For those of you not familiar with the term: context switching is when one is forced to switch from one topic or work item to the next.  This is also known as multi-tasking.  Sadly, too many people believe they are excellent multi-taskers.  This is nonsense.  Nobody is an excellent multi-tasker.

The brain is single threaded.  We are not processors that can be running two tasks in parallel.  We don’t have the internal CPU for such a job.  Every time we switch tasks, we have to rebuild our mental architecture.  We have to tear down the thought processes for our current task and replace them with the thought processes for the new task.  This takes time when we are working in a vacuum.  But when’s the last time you worked in a vacuum?  Think about how much more time this takes when we are getting interrupted on a regular basis.

This is the famous chart that Gerry Weinberg put together to illustrate the waste caused by context switching.

Context Switching Chart 1

If the numbers aren’t working for you in the first chart, that is because several assumptions are being made.  The chart below explains those assumptions in a little more detail.

Context Switching Chart 2

If you don’t find these graphs shocking, you’re not reading them right.  If you are working on two projects at one time, then you are losing a full 20% of your productivity.  If you are working on 5?  75% of your productivity goes straight in the shitter.  To say that another way, when you are working five projects, each project gets 1/20th of your time.  Rebuilding your mental architecture each time gets 3/4ths of your time.

That doesn’t apply to me, I’m a great multi-tasker

Oh yeah?  If you are such a good multi-tasker do these two simple tasks for me:  recite the lyrics of your favorite song and calculate the square root of 2,116.  The hitch?  You have to do these two tasks at the same time.  Start the lyrics now and do not pause.  Before you finish those lyrics, come up with the answer to the math problem.

In my personal experiments, one of two things happen here.  The person gives up OR they come up with the right answer to the math problem but keep losing their place in the song.  Humans are NOT capable of multi-tasking.  Unless you are a cyborg or have figured out how to split your brain, please stop claiming that you are a good multi-tasker.  My crappy personal experimentation aside, the science is in.  You can start here for more info: http://www.npr.org/templates/story/story.php?storyId=95256794.

There is always some wise-ass at this point that asks the question: if that is true how can I drive and hold a conversation?  OR, how can I chew gum and walk at the same time.  The answer: habits don’t count.  The things that you have done so many times where your lizard brain takes over and the action gets moved to auto pilot don’t rely on higher level thought.  We are only talking about those tasks that take higher level thought.  Which, hopefully, is most of the tasks you do every day at work.

Interesting sidebar edit:  It took me an hour and a half to write 80% of this column.  I received a phone call when I was almost done writing that I had to take.  It took me another hour and a half to write the final 20%.  Context switching in action.

So what do we do about this loss of productivity?

One of my old bosses had a great philosophy: you want to move faster?  Do less at one time.  This is another way of stating the old maxim that less is more.

Let’s get specific and address one of two primary issues where context switching is a huge killer: software development.  We’ll cover the other productivity killing issue, meetings, in the next post.

Cut your WIP (work in progress) ASAP

This is where the less is more rubber hits the road.  When it comes to agile, one of the questions we need to be asking ourselves all the time is how much we can cut our work in progress.  This questioning is where Kanban can be incredibly effective.  Kanban translates to ‘visual signal’ and was pioneered on the floors of Toyota plants back in the fifties.  Most people will use Kanban to give the team and folks outside of the team insight on the progress of work.  Boards like the one below can be seen in almost every agile shop out there:

Kanban Board 1

Unfortunately, for most teams, that’s where the utilization of Kanban ends.  This is a shame.  If you end with just the visual representation of the work moving from stage to stage you are missing out on the critical improvements that Kanban can offer you and your team.  As you dive deeper you realize that much of the benefit of Kanban comes from identifying and eliminating bottlenecks.

One of the ways to tell if you have bottlenecks is to identify where most of your cards are backing up on your Kanban board.  If most of your cards are in your backlog (to do) or sitting in Done, this isn’t much of a problem for your team.  If however, most of your cards end up sitting in develop or test for most of the sprint right up until the last day: you’ve got WIP problems.

WIP problems typically fall into two categories: context switching and process problems.  These categories have a ton of overlap, so we’ll talk about both together.

Set fixed limits for WIP

In a previous life, one of the teams I worked with had six devs, three QA and a product owner.  Our rule for this group was the team could only have six WIP cards that were between the backlog and the done swim lanes.

The reaction to this early on was unexpected.  The developers complained that they would be sitting on their hands a lot waiting.  Granted, there was some hand sitting but not nearly as much as you would think.  Instead, the team gelled better than ever before.  A lot of agile teams pay lip service to the idea that no matter the task, the whole team pitches in to move product through the pipeline.  So dev will help with QA, QA will help with requirements definition, etc.  The sad reality is that these teams almost always get siloed.  Developers just work on dev and QA just works on quality.

What happened with our team after instituting very strict WIP limits is that the devs got a lot more involved with the QA process and helped test other developer’s stories.  In doing that testing, they gained a much better understanding of how QA was writing test cases.  Most QA folks can’t code so QA didn’t implement any stories but the QA team got much more involved in the definition of these stories.  Our devs also learned how valuable a good unit test is.

In the end, the numbers told the final story.  That team went from an average push rate (work items being pushed at the end of a sprint) of 17% to under 5%.  And their overall velocity increased by 10%.  What we found was that keeping the whole team focused on a small number of items at one time caused us to move a lot faster.  Less is more when you limit context switching.

You will need to play around with what your WIP limits are but err on the side of less work items at first.  Even though it may feel like some people are sitting around waiting to work, people generally like to work.  Chances are, you will find them helping out with other jobs and understanding the process as a whole a lot better.  You will also quickly identify your bottlenecks.  For us, the bottleneck was QA.  Having developers finish more stories was only backing up the QA machine in the production line.  Having dev help out with QA made everyone faster.

Segregate the issues coming in from the field

Another issue that can completely destroy your team’s productivity is adding work items to the sprint after the sprint has started.  This is agile 101.  Most of you know this and know that most product owners would never dare to add a new work item mid sprint.  But what happens when a defect comes in from the field?  This issue turns out to be bad enough that the customer is genuinely pissed off and now you have your CEO breathing down your neck.

The most effective way I’ve found to deal with this issue is to build a dev support team.  We had a rotating dev support team that was made up of one developer with another on back up.  The person on the dev support team was only on that team for two sprints at a time.  Then they would move to the backup position.  When they were the primary support dev, their only job was to handle issues coming in from the field.  When there were no issues coming in from the field, they would fix defects.  They were never assigned story work.

This is another great anti-silo approach.  This forces all of your developers to become familiar with the entire codebase.  It also shows you as a leader, how your different devs react to stress.

What if I’m on a custom software team?

If you’re building custom software for clients, context switching comes with the territory.  It can be managed but not eliminated.  The most effective custom or outsource teams that I have worked with manage this in a couple of ways.  First, they budget for the context switching costs.  Most of these teams have been doing this long enough that they understand the impact of context switching WAY better than product development teams so they incorporate it into their estimates.  They also mitigate some of the risk by trying to keep their resources on one project and only one project as long as they can.  When that is not a possibility, the best outsource teams that I have worked with try to limit their resources to working on only one project per day.  It’s easier to rebuild that mental architecture if you only have to do it once per day.

Conclusion

None of us can multi-task effectively which is why context switching is such a killer.  Acknowledging that multi-tasking is the problem is the first step in the healing process.  The more you can eliminate context switching from your life and the lives of your team, the more productive you will be.  This is part one of the context switching topic wherein we covered the mechanics of context switching in the agile product cycle.  In the next post we will cover the other big context switching time thief, meetings.