Kanban Practices to Manage Context Switching

Picture this: You start your workday planning to finish a task assigned to you yesterday. As you begin, however, your manager emails you asking for an update on another high-priority task. You respond after quickly reviewing what’s left to complete, and then settle back into the initial task. Soon afterward, you receive an automated notification that you have a peer review to complete. You make a note to complete that later and get back to the task at hand. Then you get an alert from yet another app: You have a meeting starting in 10 minutes.

Sound familiar? We all have to context switch in some capacity during our workdays, but frequent context switching has a variety of consequences, including cognitive overload, reduced focus, and decreased productivity. The 2021 Workgeist Report found that it takes 9.5 minutes on average to get back into a good workflow after toggling between apps: 45% of respondents said this back-and-forth makes them less productive, and 43% said it was very tiring.

Context switching is baked into the rigorous, fast-paced work of Agile product development, in which team members are expected to context switch with ease. They must juggle multiple tasks, roles, and projects while constantly adapting to changing needs and circumstances. Being able to multitask, self-manage, and be flexible is essential. Leaders of Agile teams must therefore adopt strategies to mitigate the impact of context switching.

As a former developer, I know these challenges firsthand. Since I transitioned into a career in project management more than two decades ago, I’ve helped development teams apply Kanban practices to create engagement rules, set clear expectations with stakeholders, improve the visibility of their work, and confidently meet deadlines without feeling overburdened.

The Effects of Context Switching

When left unmanaged, the impact of frequent context switching on both teams and organizations can be extensive. In addition to reduced productivity, there are a range of other potential negative effects. The pressure to meet deadlines coupled with a diminished ability to focus can lead to more errors and lower-quality work overall, which in turn promotes a project mindset that prioritizes output rather than customer value. Team members can end up dealing with failure demand—the additional work generated when the delivered work does not meet the product goals—instead of focusing on value demand—the work done that generates value. This can have dire consequences for businesses, including the loss of users, clients, and revenue. All of this can lead to lower compensation, fewer perks, and a more toxic work culture, resulting in low morale.

The bad news is that you can’t avoid context switching altogether. The good news is that with more structured task management, context switching can be isolated, measured, and controlled, and its negative impact can be reduced.

Apply These Kanban Practices for Better Task Management

You are likely familiar with Kanban methodology, a project management framework based on the core principles of Lean thinking, such as creating flow and striving for continuous improvement. Here we focus on four Kanban practices:

1. Visualize the workflow.
2. Limit work in progress.
3. Manage flow.
4. Make process policies explicit.

I’ve found that the systematic approach of these four Kanban practices can be leveraged to manage tasks more effectively and mitigate the effects of context switching for today’s software development teams. Here’s how to integrate these practices into your work:

1. Visualize the Workflow

Creating a detailed workflow can help identify the stages in which developers can expect to context switch. Knowing when and where context switching will be necessary can help them anticipate the change and increase their ability to focus on the task at hand.

A workflow is usually:

This doesn’t really provide an opportunity to predict where context switching will happen. This Kanban workflow would allow for better planning:

Now the developer can visualize their workload and track progress more effectively, enabling them to isolate when they need to switch contexts and when they can expect communication from other team members. This allows them to better plan their days, pinpointing the times when they may need to juggle tasks and when they can focus solely on coding. It can also give other stakeholders more visibility into progress, which means they can set their expectations and plan their own workloads accordingly.

2. Limit Work in Progress

Setting limits around the amount of work in progress helps facilitate a continuous flow of work and ensures team members don’t take on too much at once. This practice is built on a principle of Lean thinking called the pull system, which recommends only starting work if there is capacity to complete it. As well as reducing the need to context switch, using this decision-making process can ensure developers are not overburdened and can focus on quality.

Implementing work-in-progress limits encourages developers to think about their workload more holistically. For example, their limit for one week may be to code two product features and handle two code review requests.

Encourage developers to set initial work-in-progress limits and monitor whether they are able to adhere to these. Work-in-progress limits may vary with the size and complexity of the tasks; developers should modify their limits accordingly so they can take more time if needed.

3. Manage Flow

The goal of Kanban is to create a predictable flow of work, and this can also help developers better anticipate and plan for context switching. Flow metrics like cycle time—the time it takes for tasks to move through the workflow stages—can be hugely valuable.

For example, measure the time it takes for 10 tasks to move from the Code in Progress workflow stage to the Peer Review stage, and calculate the 70th percentile. Over 10 tasks, let’s say the completion time in days was: 4, 5, 4, 4, 3, 3, 2, 3, 2, 3. The 70th percentile is four days, meaning that 70% of the tasks were completed within four days, and there is a 30% risk of delay. I find that the 70th percentile works well, but you may want to have less risk involved, and choose the 80th or 90th percentile. Measure the average cycle time for each workflow stage.

Now when a developer takes on a task in the Code in Progress workflow stage, they know they should be able to comfortably complete it within four days, and another developer knows they should expect to get a peer review request in four days. By taking a more scientific approach to workflow management, context switching is no longer a surprise, but an expectation.

4. Make Process Policies Explicit

Clearly defining and communicating the workflow rules ensures the entire team understands how work should be done. Setting explicit policies creates visible boundaries and expectations that can reduce context switching. These are some examples of policies that I’ve found work well:

• The code coverage should be 80% for all business-critical microservices enhancements. Code coverage is the amount of code executed by testing. By setting an expectation of the percentage of coverage, developers do not succumb to deadline pressure and deliver low-quality work that will only end up accruing technical debt.

• Developers should only pick up one enhancement request if stakeholders are testing or reviewing their previous enhancement. This policy supports the work-in-progress limits, ensuring that developers do not end up overburdened.

• Developers should complete at least 10% of technical debt tickets within one quarter. In outlining a clear target, developers can proactively integrate it into their workload; regularly addressing technical debt prevents it from accumulating to a point where it causes urgent or critical issues.

The Kanban “classes of service,” originally developed by David J. Anderson, can also come into play here. The four classes of service each have specific characteristics and implications for how work is prioritized and managed:

• Expedite: Tasks that require immediate attention
• Standard: Tasks that should be completed when capacity allows
• Fixed date: Tasks that must be completed by a specific date to avoid negative repercussions
• Intangible: Tasks that may have significant consequences if ignored

Categorizing tasks by classes of service provides clear guidelines for prioritization. By defining when and how tasks should be addressed, developers can organize their time more effectively, reducing the need to switch between tasks numerous times. It also prevents developers from cutting corners due to deadline pressures, enabling them to maintain the quality of their work.

Identify Other Improvement Opportunities

It’s worth implementing Lean philosophies more generally too. Conduct an operations review: Look at the current ways of working and identify opportunities for improvement and reducing “waste”; that is, eliminate any legacy processes, tasks, or activities that could lead to context switching. These might include:

• Unnecessary meetings: Revisit the objectives and audience of regular meetings. Do all developers need to attend? Can the meeting frequency be decreased?

• Manual processes: Pinpoint any current processes or clerical duties that could be automated. Perhaps developers usually send an email after moving tasks through the workflow. Could this notification be triggered automatically?

• Development environment: Maintain the sanctity of the product development environment. Do developers spend time resolving defects due to improper environment configuration or improper test data?

• Large tasks: Longer-running tasks tend to be subject to more context switching than small or incremental deliverables. Can you limit the size of user stories?

• Multiple tools: Teams often work and communicate across a range of platforms and software applications. Can you integrate tools or streamline usage?

Adopting a Lean approach to all facets of work—both projects and the processes that carry them—can help you eliminate waste and drive greater efficiency within the team.

Enhance Your Team’s Workflow Efficiency

The ability to juggle multiple tasks has become an implicit expectation for Agile teams, particularly software developers. While avoiding context switching altogether may not be feasible, integrating the above practices into your team’s workload can mitigate its adverse effects. By creating detailed, efficient workflows, limiting work in progress, measuring cycle time, establishing explicit policies, and implementing process improvements, you can create a more predictable work environment, empowering software development teams to plan and manage their tasks more proactively. Remember to conduct a regular review of these processes to ensure they are optimized for service delivery.

Thoughtfully applying Kanban practices and embracing Lean principles can transform workflows into more efficient, focused, and deliberate processes. Implement these practices to minimize the impact of context switching, reduce cognitive load, increase productivity, and allow project teams to meet deadlines without compromising on standards.