Agile Teams and Context Switching
Stop Starting — Start Finishing
Multi-tasking which requires context switching does not give us the productivity gains we think it does and in my humble opinion should be discouraged. It is both a myth and counter-intuitive; the greater the level of context switching (from one task to another) the greater the loss in productivity (initially as high as 40%). There is also an increase in the level of frustration for the people involved in working on these tasks and the ‘task-masters’ (delivery managers) waiting for the tasks to be completed.
Other costs of multi-tasking (context-switching) is high:
- Mental fatigue increases (our brains have to constantly switch gears)
- Loss of focus
- Quality of work suffers
- Not completing a task, whilst starting a new tasks has our brains switching back-and-forth between the two tasks — we are not in control of how our brains work
According to the American Psychological Association:
Although switch costs may be relatively small, sometimes just a few tenths of a second per switch, they can add up to large amounts when people switch repeatedly back and forth between tasks. Thus, multitasking may seem efficient on the surface but may actually take more time in the end and involve more error. Meyer has said that even brief mental blocks created by shifting between tasks can cost as much as 40 percent of someone’s productive time.
1. Multi-Potentialites and the Super-Hero Complex
Unfortunately besides giving in to the temptation of multi-tasking in 21st century office environments, some people, who are multi-skilled with the potential to fill multiple roles at a high level of competency are volunteered to take on multiple roles and tasks at the same time.
These individuals cannot resist the temptation to get stuck stuck in, help out or get started on multiple tasks at the same time (time-slicing and context switching throughout the day) with the resultant loss in productivity or negative effect on work-life-balance.
I have found that, as a career-motivated individual with very little interests outside my work — which is also my hobby, doing this keeps me highly engaged, excited and satisfied; however, it can also result in me giving some tasks less of my time is needed, not polishing or even completing some of the tasks at a level that pleases me (a good maxim to follow here is; ‘perfection is the enemy of good enough and getting things done’).
I have found, as Agile Coach, that individuals have a sense of guilt when they do not complete tasks they have committed to because they are not finishing work as early as is expected of them; they end up feeling that they have let their team-mates down (the daily stand up meeting feels like a ‘name and shame’ event which they dread attending). They feel like failures at every task they undertake because they did not complete a single task to the level of quality or in the time-frame required.
So it is important that we keep these highly talented people focused and ensure that they commit to work on one thing at time until that task is done; but also give them the variety they need to thrive in the 21st century workplace, if they are to best serve the teams they work in and the companies they work for.
2. Agility and Many Shaped People
The agile team of the 21st century is expected to be ‘cross-functional and self-managing’, so it needs more than just the I-shaped person with a single area of expertise. A T-shaped person (that is, a person who has a broad base or depth of experience in one area of expertise) or even a Pi-Shaped person (broad base with two areas of expertise which results in the shape of the Pi symbol) or even a M-shaped person in the Team. The Team itself has to be M-shaped or even comb shaped (multiple legs of specialism and broad-based generalist skills across the people in the team).
However, it is still important to remember, that within this 21st century team (organisation structure) with its need for people with multi-varied skills, the aim is still to focus on getting work done fast, efficiently and to a standard that meets the acceptance criteria of our customers and the industry we operate within, especially in software engineering (which is my focus).
When we apply this to the Team’s backlog of work (that is, the Product Backlog which consists of user story cards), just do enough work to get the one story to its requisite state of done, one story at a time; no more than that. Only ‘create’’ the T-shaped or M-shaped ‘persons’ by getting people in the team to collaborate to get the user story to a state of done (I like to call it the ‘woo! hoo!’ state).
3. So — How to Get Work Done!
The are a few strategies that can be applied to getting work done; I suggest just using two, initially, both may seem counter-intuitive, but from first-hand experience, they both work:
- Limit work in progress — setting a WIP limit for the team and possibly a separate WIP limit for individuals. Some people find this very hard to do; I belong to the Limited WIP Society and have seen how limiting work in software engineering teams works, especially when building MVPs. Try it! It works.
- One story at a time (mono-tasking)— i.e. working on a single task at a time leads to a sense of achievement when that task is completed and it also leads to an increase in productivity; the Delivery Manager will love you for it and so will the Product Manager.
So … stop starting & start finishing.