Focus in Scrum: Increase Throughput

Not all games are a waste of time. A recent defeat in a tower defense game taught me the importance of focus in Scrum.

What is Focus

Focus is one of the five core scrum values. The other four are openness, respect, courage, and commitment.

The scrum guide has this to say about the scrum team:

“Their primary focus is on the work of the Sprint to make the best possible progress toward these goals.”

-Scrum Guide

Merriam-Webster provides two applicable definitions of focus. The first as a noun and the second as a verb.

Focus is a state or condition permitting clear perception or understanding.

Focus is to concentrate attention or effort.

It helps me to triangulate the meaning of a word by reviewing its antonyms. Here are a few for focus:

• Inattention
• Neglect
• Disregard
• Apathy
• Disorder
• Confoundment
• Chaos
• Confusion
• Mayhem
• Disarray
• Indefiniteness
• Nebulousness
• Impulse
• Whim
• Vagary
• Aimlessness
• Insignificance
• Heedlessness
• Thoughtlessness
• Distraction

The Importance of Focus in Scrum

“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”

-Agile Manifesto

Focus is the single most crucial tool for frequently delivering working software. We cannot recognize value until the product is live.

Incremental delivery provides us with five primary benefits:

1. Business Value
2. Risk Mitigation
3. Adaptation
4. Visibility
5. Evidence

Business Value

Each development request has a presumed value. When we deliver in small increments, it allows us to realize portions of that value along the way.

Risk Mitigation

Project risk comes in a variety of flavors. Risks related to miscommunication and technical implementation are the most common.

Technical implementation risks are when we understand the requirements, but we’re fuzzy on the approach. We’re about as certain as death and taxes that we can do it, but we’ve never done it before. Until the team digs into the implementation, it’s hard to quantify the risk, much less mitigate it.

Miscommunication risks come in the form of misunderstood requirements. The tree swing story is my favorite depiction of this struggle. This picture demonstrates how the ask, the need, and the implementation can all be different.

Incremental delivery allows us to combat both types of risks. Issues are easier to solve when we decompose them into smaller, manageable parts.

How do you eat an elephant? One bite at a time.

The Scrum Team can decompose complex technical issues into smaller solvable units. It will be easier to correct miscommunications when we’re looking at a tangible deliverable.

Adaptation

Users are more inclined to recognize what needs to change when they have a tangible product they can interact with.

Even if it’s not feature complete, having a functional product can enable us to pivot.

Imagine we’re building a park. The plan calls for a two-mile walking track, a playground, and a picnic area. In 2019 we may have prioritized the building of the playground as a first feature of the park. During the 2020 pandemic, the outdoor track would have been the clear winner for value.

Delivering in increments allows us to make decisions at the last responsible moment.

In the case of the park, we might plan where each feature will eventually go. We could build the parking lot first, as it provides value for any of the future features. We can wait until we’re nearing the completion of the first feature to determine the next. If we happen to be in a pandemic, we can opt for the track over the playground.

Visibility

In the same vein as reducing miscommunication, incremental delivery increases visibility and transparency.

Some teams attempt to provide a percentage complete for work in progress. This issue here is that being 50% done will mean different things to different people. In the case of the cheesecake, I could argue that finding a good recipe and measuring out ingredients is half the work. Someone else might interpret 50% done as the cheesecake being halfway consumed. If I find a way to bake a cheesecake a piece at a time, 50% could indicate I’ve baked half the pieces. There’s a lot of ambiguity when I say it’s 50% done. But, looking at the same cheesecake together would eliminate that ambiguity. We’d both know exactly how much cheesecake is available and how much of it is consumable.

Evidence

Incremental delivery allows us to obtain evidence that users will adopt our idea. At some point, everyone has had what they believed to be a brilliant idea that turned out to be a flop.

The idea is to fail fast. If the product feature isn’t getting traction from our user base, let’s find that out as soon as possible. This allows us to reduce the effort wasted on the terrible idea. We can take our learnings and apply them to the next potential idea.

The Benefits of Focus in Scrum

My daughter recently got my husband and me sucked into this game called Rush Royale. It’s a tower defense game, a genre which I rather enjoy.

The goal of the game is to prevent waves of monsters from making their way to your gate. The baddies will spawn from a portal and progress toward their exit. To keep them from reaching their destination, you must destroy them.

You build an army capable of eradicating monsters using units you place in your deck. Units have different damage, attack rates, and target strategies. Various combinations of units will result in distinct attack strategies.

The game progresses in waves, with each wave of monsters getting harder to defeat. Every tenth wave, a boss enemy enters through the portal. These enemies have special abilities that negatively affect your team.

You can choose to play in co-op mode, where you team up with another player. In this mode, you attack your stream of bad guys that spawn from a portal on your side of the screen. As the monsters approach the gate, they will eventually merge onto a shared path. On this shared path, either player may attack the monsters.

So, what does any of this have to do with focus in Scrum? As it happens, there are a lot of parallels between tower defense games and Scrum. The following five fundamental discoveries are just as applicable in Scrum.

1. If you want to survive as long as possible, you need to have a logical strategy.
2. The only good monster is a dead monster.
3. Extending the time an enemy remains on the board has a hidden cost.
4. Downtime between waves provides an opportunity to strategize.
5. You’ll learn to measure the reliability of a co-op partner by their ability to cover their portal.

Logic

The units in the game have two main strategies. They either target the first enemy in line, or they target multiple enemies. My initial thought was to load my team up with units that targeted numerous baddies. Over time, I’d take out five guys instead of just one guy. It seemed like a good idea at the time.

I’ve worked with several teams that follow a similar strategy. When faced with a horde of initiatives, some Scrum Teams default to attacking as much work as possible. They make a little bit of progress on many things but don’t get any of the initiatives all the way done.

This is precisely what happened with my area damage team. I damaged a lot of monsters, but it didn’t matter. If any of them survived to make it to the gate, I still lost.

The logical way to survive as long as possible is to focus all your firepower on the first bad guy. This concept of limiting work in progress isn’t all that novel. We’ve known the benefits of WIP limits for quite some time. Yet, teams habitually attempt to contribute to multiple ongoing initiatives instead of focusing on the priority.

“The result of juggling elephants is that no one, including you, is thrilled with the performance.”

-James Loflin

As it turns out, there is a cognitive bias that contributes to this standard approach. Naive Allocation may influence our prioritization decisions when we view our work as groups of stakeholders, projects, or initiatives. Even when the course isn’t logical, we’re inclined to distribute our resources evenly across categories.

Being aware of this tendency and having prioritization policies in place can help combat this cognitive bias. We need to allocate work to our teams in a logical manner that aligns with the company goals.

Execution

In the game, I learned that the only good monster is a dead monster. If a baddie with one hit point remaining makes it to the gate, I’ll die just the same as if a fiend with 10M hit points made it to the gate. Scrum Teams need to have the fortitude to focus on elimination. Focus helps us stop starting and start finishing.

We have more time available to complete work when we limit WIP and prevent interruptions. We can make it across the finish line when we focus on doing so. If we take two steps forward and then meander off in a different direction, we’ll never make it to the finish line.

Awareness

I played one game with a partner who had the ‘Portal Mage’ unit in their team. This unit will randomly teleport some monsters back to their starting portal. This grants you twice the time to kill the monster.

This is also the same principle I believe some teams use when working on multiple priorities at once. If I can touch this work item and make a little progress, I can buy some time with the stakeholder. I can spend this time making progress on another work item making just enough progress to prevent another stakeholder from becoming irate.

The problem with this approach became evident to me once the boss enemies entered through their portals. In this wave, we were fighting the Gorgon. The Gorgon has a special ability to petrify two units on a defined interval. Effectively, the longer the enemy is left on the board, the more units it eliminates until eventually you have no more units left to attack, and the enemy is free to meander straight to your gate unchallenged.

Given that we each had our own Gorgon to fight, this combination created the perfect storm. The first Gorgon to make it to the shared pathway leading up to the gate was attacked and weakened by both teams and thus had the lowest health. Eventually, though, the Portal Mage triggered and teleported that Gorgon back to its origin portal.

Then, the second healthier Gorgon became both teams’ primary focus as it was closer to the exit gate. Both Gorgons continued to petrify two units every couple of seconds. Again, the Portal Mage activated teleporting the second Gorgon back to its origin portal, and now the first Gorgon became the primary target.

This juggling continued, and we were unable to finish off either Gorgon. Eventually, both our teams were completely petrified, and both Gorgons were able to continue to the gate attack-free.

Scrum teams are under a false assumption that they can juggle work without paying a hidden cost. The more work you keep in progress, the more it exhausts your team’s mental capacity and awareness.

You may have had the misfortune of experiencing this in your career. As work in progress grows unlimited, so do the number of meetings. Eventually, your calendar will be so full that there is no time left for work.

Then, a groundhog’s day theme will start to permeate your meetings. There will be a meeting to discuss a topic previously discussed. No one will remember the original discussion. Thus, they squander the timebox rehashing what happened in the first meeting. The facilitator will schedule a future meeting where the team is destined to repeat the pattern.

The mental taxation and overhead of keeping up with all the work in progress will petrify your team members. Eventually, people burn out andfind a saner place to work. We can avoid this hidden cost by limiting work in progress and focusing on a few priority initiatives at a time.

Reliability

When playing in co-op mode, I began to judge my partners on their ability to keep their hoard from turning the corner. The longer I held down my side of the board without needing the help of my partner, the more competent I felt. The sooner I had to help my partner eliminate monsters that spawned from their gate, the less confidence I had in their abilities.

This is the same way that Scrum teams build trust with their stakeholders. The Scrum Team builds trust with stakeholders when they do what they said they’d do. When they fail, that trust is reduced.

Strategy

As the waves continued, I found that the levels became more and more hectic. I noticed that the couple of seconds between waves became an opportune time to strategize for the next level.

Allowing slack is a tactic that all too many companies forgo. Leadership commonly strives for 100% utilization. If a team has downtime, we must fill it. Overutilization is one of the reasons we end up with so much work in progress. God forbid Harry has a chance to take a breath. We’re paying him for that breath; he must take it while working on our product.

This logic is flawed in two main ways. First, it falsely assumes that a person’s capacity split five ways will add back up to 100% with no loss of efficiency. Second, it allows no slack in a complex system.

In his book Meltdown, Chris Clearfield points out that systems reaching 100% efficiency become brittle without slack. Any small, unexpected thing can destroy the efficiency and lead to a meltdown.

Allowing slack gives us a chance to recover from unexpected events and innovate on better solutions.

How can each Scrum Role Exemplify Focus?

Scrum Team

The primary target, so to speak for the Scrum Team, should be the Sprint Goal. The team should stay focused and not let what might be necessary for the future distract us from what is essential now.

The Scrum Team strives toward incremental delivery because we know that will give the stakeholders the most value.

Developers

Developers can embody the YAGNI mantra. You Ain’t Gonna Need It. Strive to build the most straightforward thing possible to meet the need and accomplish the Sprint Goal.

Developers also exemplify focus by focusing on the Sprint Goal. No, seriously, focus on the Sprint Goal. Yes, I know I just said that above, but there is a non-zero chance that you didn’t grok the meaning.

I’ve worked with a lot of developers that severely stretched the essence of the Sprint Goal. If the Sprint Goal is to add a checkout button to the cart page, that doesn’t give you cart blanche to rewrite the entire cart UI while you’re in there.

Think about the work that you’re doing. Does it align with the essence of the Sprint Goal, or are you making an excuse so that you can do work that you find more fun? Could the Sprint Goal be accomplished without the code you’re currently writing?

Scrum Master

The primaryway the Scrum Master can exemplify focus is to provide air cover for the Developers. When you insert yourself between the stakeholders and the Developers, it isn’t about control or authority. It’s about maximizing the time available to build the product.

I once heard an anecdote about a team suffering excessive interruptions. They wanted to quantify the interruptions somehow to ensure the problem was real and not just their perception. Instead of making entries in a log, they opted to blow up a balloon each time someone dropped in to ask a question.

The Developer could quickly inflate the balloon while the information seeker explained their query. The activity brought more attention to the fact that the Developers were pulled away from their work. Leadership suddenly became interested in the source of the balloons filling the office. Management was appalled to learn that each balloon signified fifteen minutes of unfocused time on average. As a result, the Scrum Team eradicated a long-standing yet previously ignored situation.

Focus and the Scrum Artifacts

Increment

In Scrum, the increment is an artifact. At the end of each Sprint, the Scrum Team should deliver a potentially shippable increment. This entire concept hinges on getting work across the finish line.

Sprint Backlog

The Sprint Goal, which we’ve already discussed ad nauseam, is a piece of the Sprint Backlog. Therefore, this artifact contributes toward focus by setting the sole focus of the Sprint.

Focus in Scrum Events

Sprint

The Sprint is a timebox that focuses the team on a subset of the Product Backlog and the Sprint Goal.

There will always be more work to do, decisions to be made, and discussions to be had. We defer those activities to the last responsible moment. Deferring allows us to carve out some space and time to focus on getting the next product increment done.

Sprint Planning

Sprint Planning contributes to focus in two main ways.

1. Sets the focus for the upcoming Sprint
2. Provides an opportunity to communicate the deferment of work

During Sprint Planning, we will establish the Sprint Goal and select the portion of the Product Backlog that we’ll focus on during the Sprint.

The Scrum Team also develops a plan for how to accomplish the Sprint Goal. It may come to light that some of the work is not going to fit into the Sprint. In that event, the Product Owner is aware at the earlier possible moment. The Product Owner will have an opportunity to be open with the stakeholders about what is and is not likely to be accomplished in this Sprint.

Daily Scrum

My mind tends to wander. I often find myself going off on a tangent unrelated to the work I should be focusing on. I like to solve problems, and if I feel that I’m making progress on a problem, I will work on it indefinitely until I have an answer that I’m comfortable with. Therefore, it’s dangerous for me to get distracted from the work I should be doing. Once distracted, if left to my own devices, I may stay distracted.

I’m supposed to be working toward a deadline that is approaching in two hours. Suddenly, a thought pops into my head. I drop what I should be doing and begin to research this idea. I find an entire body of knowledge associated with this concept and begin to investigate books and certifications. The next thing I know, two days have expired, my deadline has come and gone, I’m dehydrated, and the pizza I had in the oven has long since turned to charcoal.

Over the years, I’ve experimented with different productivity techniques, and I’ve found that Pomodoro helps limit how far I stray from my intended goal. Every twenty-five minutes, I take a 5-minute break. I read, work some on my current jigsaw, or fold clothes. When those five minutes are up, I get back to what I should be working on and not what I had distracted myself with. In this way, I’m diverted for no more than twenty-four minutes (assuming I became distracted in the first minute).

The Daily Scrum should serve this same purpose for the Scrum Team. We meet as a team each day and see where we are on the Sprint Goal. We plan for the next twenty-four hours. If we wander from the established plan, we have an opportunity to course-correct in no more than twenty-four hours. This build-in course correction helps us maintain our focus.

Retrospective

The Sprint Retrospective helps us focus in a different way. In this event, we carve out time to focus on people, processes, and tools. Often teams would ignore these areas if we didn’t set aside time to discuss them and focus on improving.

Works Consulted

• Juggling Elephants: An Easier Way to Get Your Most Important Things Done—Now!
• Why Getting to Done Matters in Scrum
• You Are Not So Smart: Episode 180 -Meltdown
• Agile Uprising Podcast: The Cost of Organizational Multi-Tasking With Brandi Olson
• What Is Kanban? Explained in 10 Minutes
• How to Apply Scrum Values in the Day by Day?
• Understanding Scrum Values: Focus
• Understanding Scrum Values: Openness
• Deep Dive on Scrum Values With Sam Falco
• Head First Agile: A Brain-Friendly Guide to Agile Principles, Ideas, and Real-World Practices

TLDR

Strategize your next Sprint like a tower defense game. Prioritize what work to execute first. Focus all your damage on the first enemy in line before moving on to the next. This strategy should prevent work items from crossing the line into the next Sprint.