Uncover the Hidden Priorities that Make You Ineffective

Many organizations and teams mistakenly justify context switching as both parallelization and talent resource optimization. Although their goal is efficiency, unknowingly these “hidden priorities” result in not only loss of efficiency (accomplishing things quickly), but also loss of effectiveness (accomplishing the most valuable things).

Strategic & Tactical Prioritization

Prioritization is at the heart of agility. We make tough business prioritization decisions every day in order to deliver what’s most valuable to our customer. The Manifesto for Agile Software Development itself is a set of four values in priority format (“we value X over Y”). The final phrase in the manifesto is especially useful in understanding prioritization: “That is, while there is value in the items on the right, we value the items on the left more.” Prioritization is valuing a particular thing over something else and deciding in what order to address them. Unless your business has infinite bandwidth and resources, it must choose priorities. Not every feature can be implemented today, or even tomorrow. Only one thing at a time can be the next most valuable and deserving of your time, talent and resources.

This is true not only of high-level strategic initiatives but also of the daily tactical task level. Often at the tactical level, if we forget to keep a strategic perspective (i.e. forest for the trees), we end up choosing to do something sub-optimal at the expense of what would have been more optimal. These decisions are based on what we might call “hidden” priorities—hidden somewhere in our subconscious or in habit or in our fears. Bringing these hidden priorities to light can help us determine if they are desirable and, if they aren’t, what actions we can take to overcome them.

This article will examine the hidden priorities in one such decision: context switching vs. parallelization.

Context Switching is NOT Parallelization

At the tactical or task level, context switching is when you start on an item of work before finishing another item of work that is already in process. Agile teams call this practice “thrashing” and avoid it due to the costs of delay it incurs. Parallelization at the task level is multiple team members working on one strategic item of work—they may each be working on different tasks, but collectively are working towards one end-to-end piece of user functionality from the product backlog (many agile teams call these “user stories”). For agile teams, this is often referred to as “swarming,” and they do it to optimize flow and delivery of completed, shippable functionality.

Many organizations mistakenly justify context switching as both parallelization and talent resource optimization. Both involve a one-to-many relationship involving people and items of work but have significantly different outcomes.

Computers (& Humans) Swarm Better Than They Thrash

Computers give us an easy analogy to understand the difference. With a single core machine (back in the day), our PCs would essentially run only one program, one command at a time. So, if you were to start up a program with a long calculation, your mouse would stop responding as the calculation finishes. To remain responsive to the user, the computer frequently paused the existing program to respond to the mouse. To pause a program and start another requires unloading and loading memory, which takes time, and doesn’t directly benefit either program. This is context switching.

In 2001, IBM released the first processor with multiple cores. This allowed the computer to truly run multiple programs at once, since they could each be given different cores. Even better, this allowed one program to split up its work to run on multiple cores, speeding up the work of the program. This is task parallelization. This is one of the main reasons we can do so much with computers today.

What humans can learn from the machines they’ve created is having one worker working concurrently on multiple items of work incurs significant costs. With scrum teams, we have found that the velocity of a sprint without context switching is at least 25% more than a sprint with context switching. Broader scientific and industry research shows that the negative effects of context switching are often even greater:

• Context switching can cost up to 40% of someone’s productive time (American Psychological Association)
• Errors increase in complex work involving a sequence of steps (National Center for Biotechnology Information, U.S. National Library of Medicine)
• Stress is increased (University of California, Irvine)

Gerald Weinberg quantifies the cost of task switching in his book ”Quality Software Management: System Thinking” as follows:

Siloing

Another devious side effect of context switching is “siloing”—when one person takes an entire piece of work on their own, they keep the knowledge independently. That same person will often end up taking all other items that are in that domain moving forward. Down the road, you’ll hit the day where that person is sick or on vacation (no, they don’t even need to get hit by a bus), and the blocking issue in that area can’t be resolved. In addition, team members learn less from each other, aren’t as versatile, and the focus on the sprint goal becomes diluted as people focus on “their own items” and even gold-plating.

Task parallelization, or swarming, generally improves the rate of delivery of a scrum team, as well as their ability to take advantage of the collective and collaborative intelligence of the whole team to adapt when things don’t go according to plan.

Exposing and Removing Hidden Priorities

So, what are the hidden priorities that cause teams and businesses to inappropriately justify context switching? Let’s look at two.

Responsiveness Can Be an Illusion

The first reason for context switching is the same reason computers did it: to give an illusion of responsiveness. Someone wants to be able to tell a customer, “We’ll get right on that.” Unfortunately, ‘getting right on’ something only implies it will get started. It says nothing of finishing it. In other words, in the name of satisfying the customer early, getting work into the system is valued more than getting value out of the system, the latter being what the customer actually wants. This is what most teams actually want as well, but full utilization is that hidden priority that causes them to behave differently.

With the team taking on more work than is sustainable, this overloaded system increases variance in outcomes each sprint and limits their ability to estimate and forecast in the long term. This can lead to hasty and unreasonable commitments, which in turn leads to more schedule overruns and unmet expectations.

Context switching also leads to an increase in defects. With team members having to split their attention between multiple backlog items, nuances and corner cases can fall through the cracks. The team’s definition of done (i.e. what it means to be shippable at the end of a sprint) can get overlooked, cutting corners to make up for lost time. These quality issues turn into more customer requests (sometimes urgent ones) that distracts from innovation and exacerbates the pressure on the team and business expectations.

To combat this, it requires a diligent product owner to be able to work with customers to find the appropriate place in the backlog for new items (or even shuffling older ones), instead of reverting to the “we’ll get right on that” mentality. A good product owner knows how to manage customer expectations so that the team can be allowed to finish the work they started. The scrum master should also watch out for when context switching is occurring and make the issue visible.

Full Utilization Is A Myth

The second reason context switching is used is pressure to show full team member utilization. Utilization is prioritizing individual team member effectiveness over value produced by the team as a whole. Many poor decisions are justified in the name of “100% utilization,” which is a very misleading metric. It doesn’t measure product delivered to the user. It doesn’t measure quality. It doesn’t measure anything that your customer is paying you for. What utilization measures is how many hours a week someone is working, regardless of whether it’s the most valuable work they could be doing. If 100% utilization is your goal, it means that you can justify any behavior as long as people are working 40 hours (often more, unfortunately) a week. You can’t increase delivered product or quality by measuring utilization.

Pursuing utilization often sounds like, “All our remaining work in the sprint is testing, so this developer should just get started on the next sprint.” Or “Bob is a GUI guy, so we’ll have him work ahead on something else that has GUI in it.” The sprint backlog should be the next highest priority items from the product backlog. So, by definition, when team members are working on something outside of the current user story, they are now working on something that isn’t the next highest priority for the business. Utilization devalues business and customer priority. Ironic, isn’t it?

Swarming Isn’t Easy

Teams that are new to swarming may not believe it can be practically done. Common objections include:

• “I don’t know how to do that.” Or, “That’s Megan’s responsibility.” — This can be reflective of an unwillingness to learn, or to do something that someone considers beneath them. In today’s world, learning new skills every day is how we keep up with changing technology and marketplaces. Good teams are constantly learning. The focus should be on contributing to the team’s current goals.
• “I don’t have time to teach John about this.” — This may be trying to establish job security by withholding information. Team members need to understand that job security is really about making the team indispensable, not the individual.
• “There would be too many cooks in the kitchen.” — While sometimes true, the number of people who can work on a user story is often more than originally thought.

Let’s examine how a scrum development team (in the software industry, in this example) might effectively swarm:

• The team elaborates the user story together, which might include the initial design exercise
• One person writes the code
• A second can be writing the unit tests—that’s a separate file, so no stepping on toes there
• A third can be writing integration or system tests —that’s three people already working on one user story
• A fourth can be writing automated user acceptance tests
• Two classes to write? You can add two more people to write code and unit tests
• Documentation updates (wiki, training, user, etc)
• Consider pair programming to front-load peer review for quality
• Writing database upgrade scripts
• Maybe you can think of others…

Development teams are between 3 and 9 people, ideally somewhere in the middle of that range. There is plenty for everyone to do on a single user story.

Yes, this requires collaboration daily during development. That is why scrum is called scrum—a rugby metaphor for team collaboration. Yes, this may mean that sometimes you have a developer working on something that isn’t their strongest area. But what you get is a focus on delivering the highest priority work, earlier and more often, instead of making sure that a worker can show they are busy 100% of their day doing something. And the collaboration ensures that you don’t get siloing, but a team of versatile developers.

The best teams have T-shaped members—individuals with depth or expertise (not the same as specialization) in at least one skill or knowledge area, but have some breadth in multiple areas.

T-shaped developers have versatility and are eager to learn, and the goal is the sprint goal, not utilization. T-shaped members are constantly increasing their ability to contribute to delivering value to the customer.

Escaping “The Thrash”

Consider a few metrics that may be useful to help you avoid the hidden priorities behind context switching. These, as well as others can encourage behaviors that contribute to value delivered instead of rationalizing utilization and individual siloed contributions. Each of the following are outlined in more detail in our “Be Careful What You Measure…” blog:

• Return on investment (ROI): Is desired and intended value actually realized when you deliver new functionality? How early and often is new value delivered to generate a return on your investment?
• Defects in production: If defects are landing in production, do you know why? Is thrashing the reason you’re not satisfying your definition of done to actually mean “shippable”?
• Sprint goal success rate: Are you delivering busy work, getting lots of work started, but not finished? Are you working towards customer goals or on disparate tasks?
• Lead and cycle time: Are you starting more than finishing?
• Skill versatility: Are developers continually increasing their ability to contribute to the sprint goal?

These can all help keep the focus on delivering work, not starting it. In choosing between context switching and swarming, it is important to remember that context switching is about getting work started, swarming is all about getting work finished—delivering value early and often.

By and large, customers are focused on work finished. They don’t care about a feature that they can’t use. They don’t care about utilization. And, they don’t care about how quick you can start. Your customer cares about how quick you can finish and deliver quality. As Steve Jobs purportedly said, “real artists ship.”

If you want help to uncover your hidden priorities to be as effective as you can be, contact an adviser today.