The secret to 3-digit productivity growth

Daniel Burm

The secret to 3-digit productivity growth is simple; stay focussed on your goal. One thing that keeps us from staying focussed is context switching; picking up a task, then interrupting it for another task and the starting up the previous task. Context switching originates from different levels within the organization. If you can effectively manage and decrease context switching, you can achieve amazing results and save a lot of resources. In this post I will tell you how to best combat context switching and gain more focus.

Last week we did sort of the same exercise with a group of six people at once, naming the sequences; a to z, 3 to 42 (in steps of three) and 5 to 60 (in fives). It was part of a presentation by Olav Maassen about context switching. He got really inspired by a talk at agile 2013 from Peter Saddington and decided to pass on some of the learnings to my colleagues and me.
Olav led the exercise and he would tell us when we needed to switch context. You can imagine the results. When Olav turned up the amount of switches, our team resulted in total chaos. Leading to a lot of laughs, but also many, many mistakes. In the last round, with the most context switches, we were six times slower to finish the exercise than without switching. That's simply amazing; 600% better results with less context switches....
So if reducing context switching is a good thing, then let’s take a look at what practical things you can do to combat this phenomenon.

Context switching is a multilayered beast. "Why", you ask? The answer is, because it is not only an issue originating on an individual level, but also on various other levels throughout the organization. In the section below, I will illustrate the individual, team, managerial and organizational levels and share measures you can take to combat context switching.

The individual level
People tend to pick up more work then they can handle at once. Of course there is a myriad of reasons as to why we like to do so, some positive and some negative. I believe people genuinely believe they will produce more by multitasking. Filling in the short periods of waiting time in between tasks, starting up activities and contributions by others so you do not have to wait for it later on etc.. From a negative perspective: to have the feeling we are busy and important, have the feeling we are worth our pay (the worst that could happen is idle time…), cover up for mistakes or to strengthen blame on others and avoid taking responsibility for seeing things through, solving issues and finishing work.

4 Things you can do to decrease context switching on an individual level:

  • Strengthen your individual intend to act responsibly -> don’t pick up new stuff to avoid the issues but choose to deal with them instead. A great model to support responsible behavior can be found here.
  • Keep administration of things causing you to switch context and then work to get the #1 thing off your list. then move on to #2, and so on.
  • Actively manage your work time. Block your agenda to be able and focus on specific tasks.
  • Do the context switching exercise with your team and make it a group goal to maximize focus.

The team level
On a team level there is context switching as well. Productowners can ask to work on various customer needs within the same team and sprint. This deludes the focus of the team by not having a clear goal. A thing I have seen many times is team(members) being asked informally to jump in and do some other important chore for managers, this chore even more important than the work at hand. Another common pitfall is that people expect the team to be able to handle improving and finishing work items at the same time.

7 things you can do to decrease context switching on team level are:

  • Use Sprint goals and WIP goals to create a container around user stories so there is no context switching on this level. Do 1 goal at a time and stay focused on delivering this goal. This is also a practice described in the 2013 scrumguide, Woohoo!
  • Use magnets and avatars and only make one for each team member
  • Make working agreements, to enforce the correct usage of the magnets
  • Set limits to the amount of work in progress (or any other stage of work) to an amount that discourages multitasking (for instance the limit is lower than the team members active in the column)
  • Effectively use your scrum master capabilities and PROTECT the team from distraction. The scrum master should have enough power to deflect other requests from outside the team if necessary.
  • Always plan the teams’ improvement actions. Include all bells ‘n whistles. Talk about validation, estimate, plan, task breakdown etc. Treat improvement as normal work.
  • Introduce pair programming. It’s fun, useful and chances are less that a pair is tempted to engage in multitasking than a single person.

The managerial level
As usual it is the root of all evil that lies at the managerial level…. Well that’s not exactly true, nevertheless there are a couple of things managers can do to reduce context switching.

3 things managers can do to counter context switching:

  • Make sure you focus on 1 goal at a time. Be it a business goal, program/project goal, sprint goal or KPI (beware that these goals should be stringed together so they add up). Trying to fulfill all goals at once is a class of context switching on it’s own. First fill in the most important goal, and then move on to the next. Most times people like to have slack, so they can reduce goal scope if things get hairy. Of course we know better and tell them we can do far more if we focus on completing the number one goal first.
  • Prioritize portfolios, so everyone in the organization knows the priorities. Sure there can be deviations and changes, but at least it will be a conscious decision to do so.
  • Create stable teams. Context switching can also be caused by switching teams. In light of decreasing context switching, it would therefor be wise to keep teams together as long as possible. Team members will not have to get used to the new circumstances all the time, saving them energy and focus. Another advantage of stable teams is that people will be less tempted to ask a team member to do work outside the team domain (for example a previous project)

The organizational level

As we move on we get to the level regarding the orientation of teams. Now this is not so much a “things you can do-section” as it is a “what option best suits a non-context switching way of working – section”. So lets get to it. There are roughly 4 ways to organize.

  • Project/ program orientation: People have to learn to work with new teammates all the time, work for different clients or market-segments and on different products
  • Component/ technical orientation: If stable, people need to work for different clients and products.
  • Client orientation: If stable, people need to work on different products (except if there is only one product).
  • Product orientation: If stable, people need to work on the same product and build features fulfilling different needs and goals.

So if you are looking for things to combat context switching, you should change the team orientation to products. This also fits in best with the “build it, run it” – principle from devops practices.
JSN

Conclusion:
There are a lot of things you can do to combat context switching and gain more focus. Above all, context switching is a mindset change; accepting that it's ok to be idle now and again if the upside is to have way better focus, providing and accepting feedback if you struggle with it and honoring focus even though your request is rejected because of this.

Context switching occurs on different levels within the organization. If you can effectively manage and decrease context switching, you can achieve great results. Imagine yourself being 600% faster. Sounds good? Implement the above suggestions and you will be well on your way to achieving amazing.

Like our ideas? Please check out our Xebia ACT website to learn how Xebia can help you improve your time to market, reduce costs and improve quality using Agile and Lean best practices.

Comments (2)

  1. Shiva - Reply

    September 5, 2013 at 7:43 am

    Hi Daniel,
    Thanks for bringing attention to a very important-but-often-neglected influencer of individual productivity. Multi-tasking or context-switching has proven to be a major productivity-killer in many work environments, more so in software development.

    I believe that you and your colleagues would have better understood the perils of context-switching when you did the group exercise. Some time ago, I came across a very insightful simulation game that very clearly highlights the bad effects of multi-tasking on productivity. Have you seen / heard of this before?
    http://blog.crisp.se/2011/12/07/henrikkniberg/multitasking-name-game

    It is very quick and easy to play with a small group (8-10 member teams) – does not take more than 20 minutes. Also, it would help to perform this simulation on a regular basis, especially, when welcoming new members into the team (which happen often – whether we like it or not), or when starting out on new projects/programs – to illustrate the perils of multi-tasking, while shining the light on the need to have laser focus on a well-defined delivery goal/objective/KPI.

    I also like your suggestions on the different measures to take at the various levels. An especially key point is your observation at the team level that Improvement should be treated as normal work. Many teams, team leaders, managers fail to recognize this aspect. Borrowing from the tenets of Lean philosophy, as encapsulated in the Toyota Production System, the core lesson of Toyota is to shift from Job = Work to Job = Work + Kaizen (continuous improvement for the good). In other words, everyone, from the CEO to the lowest level team member, must factor in the education aspect (learning) of any job as well as the execution part (getting the job done). Put in other words, a good day’s work should be Execution + Education, and the proportion of each varies according to the role played by the employee (whether low-level operative, middle management, top management etc).

    Again, thanks for the write-up!

    • Daniel Burm - Reply

      September 5, 2013 at 8:48 am

      Hi Shiva,
      Thanks for your reply. I read the name game manual and especially like the trick question on influencing factors for the time it takes to complete. This illustrates how deep multitasking is embedded in our system(s). Great stuff,
      thanks a lot

Add a Comment