Focus

One of the five Scrum values is Focus. There are many ways in which developers can apply the concept of focus. There are also many ways in which developers, managers, and organizations as a whole can impede the application of focus.

When developers lose focus, the quality of code suffers, productivity suffers, and most importantly, the developers suffer.

Singular Goal, Realistic Planning, and Elimination of Multitasking

In Scrum, there is always a Sprint Goal. This goal is singular, transparent, and as brief as possible, which helps developers focus on an achievable outcome.

Realistic planning makes a world of difference for the outcome of a Sprint. Developers have issues that come up during the Sprint, they get stuck on problems in the code they’re trying to write, unexpected business needs come up; I could go on and on about this one. Planning more lightly makes it easier to be flexible and still deliver on the goal.

Eliminate multitasking wherever it crops up. It’s often the case that management has dictated that progress must be demonstrated on a daily basis towards multiple different outcomes. In some cases, developers try to switch back and forth between two or three work items throughout the week without finishing any of them. There are all sorts of cases in between and outside these.

Examples

Let’s look at a couple of scenarios that might resonate with you.

Scenario 1

The developers work on enterprise applications in an IT department for a finance company. There are 20 different applications for which they are responsible. Every Sprint, a mix of critical items for the bookkeeping software, CRM, and mobile banking app are added for developers to work on. The plan has been "maximized" for the amount of work management thinks the development team can handle over the course of the Sprint.

Each developer has gained specialized knowledge of one of these applications and has taken “ownership” of the application. Alice specializes in the mobile banking app, and Chris specializes in the bookkeeping software. Both Alice and Chris also help the remaining developers work on the CRM. Management wants to see progress on each of the three applications every day for each developer.

By the end of the Sprint, nothing has been released. Small advances were made towards completing some of the work for each app, but it will take at least one or two more Sprints before a release can be made for each of the three apps.

Scenario 2

The developers work on enterprise applications for a global shipping company. They have several different applications they are responsible for, much like the team from Scenario 1. During their current Sprint, they have planned to work on a new feature for the inventory management application. The new feature will allow other employees of the organization to add images and details about faulty products in the inventory and report them to inventory management and operations teams for investigation. The feature is a small part of a much bigger tool they want to integrate into the application for managing and reporting faulty products. With that in mind, they have planned lightly, allowing for flexibility to add or remove items and still accomplish their goal.

Each developer on the team selects one item to work on at a time, all of which are related to the eventual release of this new feature. As developers get stuck, they ask others on the team for help and work together to remove blockers as soon as possible. They complete all their work for the feature halfway through the Sprint and are able to pick up additional work to fix some bugs in the application and pay down other technical debt.

Analysis

The team in Scenario 1 is likely familiar to most of us. I’ve worked at several places that take this approach. Management lets the team plan the work but says the team must work on more than one specific goal, they must maximize the amount of work planned, and they must demonstrate progress is being made on all the applications every day.

Having no singular goal encourages the team to break into specialist groups where some developers work on a specific application and everyone else gains little experience in the domain. Inevitably, when another developer gets stuck on their own work item, others on the team must pause their work—work that is in an entirely different application—and switch over to helping that developer. In this process, the developer(s) who have swooped in to help have to shift their mindset towards the new application and go through significant learning in order to familiarize themselves with the problem. By the time they switch back to their own work, they have lost track of what they were doing and have difficulty restarting.

Lastly, in this scenario, the original plan for the Sprint left no room for flexibility. If a team member gets stuck and takes longer than anticipated to complete their work, then there’s little chance of a release happening any time during the Sprint.

On the other hand, the team in Scenario 2 created a clear goal for their Sprint around creating a small, usable feature that was part of a much larger tool. They planned light to accommodate any issues that might arise or unplanned surprises. Their common goal and light planning meant that they could essentially eliminate multitasking, focusing entirely on moving one item at a time towards the bigger release, only having to switch contexts when offering assistance to a peer. Even so, the close relation between all the work in the Sprint implied the lagged time between each context switch was minimized as developers were able to share knowledge across the same domain.

Conclusion

To reiterate, it’s critical for the success to allow developers to focus. Three great starting points to accomplish this are:

1. Have a Sprint Goal: The Sprint Goal should be singular, clear, and concise.
2. Realistic Planning: Have a light plan that can accommodate more or less work as issues and surprises arise.
3. Eliminate Multitasking: Arguably, points 1 and 2 feed into making this possible. However, developers and managers must understand that multitasking involves context switching, and the lag time accrued in context switching causes a loss in productivity.

Let me know which of these two scenarios is most familiar to you or if you've encountered another type of workplace or management style that doesn't match up with either of the ones here. Thanks for reading!