Nine Proven Ways to Make Your Scrum Team Hyper-productive

What can you learn from Scrum‘s origins to shift into overdrive?

Scrum is not a silver bullet. It does not provide solutions. Rather, it can only reveal problems. To modify your behavior and adapt to the obstacles Scrum reveals takes grit. 

Scrum is lightweight, simple to understand, and difficult to master.

—The Scrum Guide

Many teams start on the journey without much guidance and hit issues fast. In the product development world, issues encountered are typically commonplace, with responses stemming from old behavioral habits.

To name a few:

• Forcing an unrealistic date to motivate performance
• Using stretch goals to increase throughput
• Using unsustainable, heroic effort to reach goals
• Seeing functional specialization as efficient
• Deferring defects
• Keeping people busy
• Treating change and improvement as a cost
• Prioritizing work over people
• Elevating partial completion as progress
• Allowing interrupts to overrule your goals
• Moving team members to the work
  

We can’t solve problems by using the same kind of thinking we used when we created them.

—Albert Einstein

We need new habits and new behavior patterns. Instead of starting with a blank slate, we should stand on the shoulders of those that came before us.  Let’s journey back to the 1990s and revisit the origins of Scrum.

In the early days executing Scrum, Jeff Sutherland and Mike Beedle formed a set of proven patterns. They found when a Scrum team practices these patterns, the result is a state of hyper-productivity. Jeff Sutherland published these patterns in 2014 ¹. As defined, hyper-productivity equates to more than a 400% velocity increase over a team’s initial velocity.

Whether you achieve a 400% increase in velocity or not, hyper-productivity patterns will deliver. I have practiced and coached over sixty teams in the implementation of the patterns. The results are remarkable despite their simplicity. Teams are happier and more effective in their delivery. And they are better able to navigate the obstacles they face.

This post will introduce you to the nine patterns. If you are on a Scrum Team, these patterns are for you. They are also worthwhile for Agile Leaders to adopt as they will help them better support teams during pattern practice.

Let’s dive in.

---

The Nine Patterns of Hyper-Productivity

Together, the nine patterns aim to finish small work batches early as a crucial step to your effectiveness.

By practicing the nine patterns, you will learn behavior that supports finishing early to accelerate faster.

1 Stable Teams

A stable team is long-lived and small

Teams stay together and outlast their product. Workers pull the work to their team and build capabilities over time. This replaces the notion of sending workers to the work, changing the team for the skills needed. Unstable teams disrupt team cohesion and performance. A stable team continues to improve the longer it stays together. Stable teams stand behind what they build. They own their work end-to-end and support it when deployed to users.

Small teams are better. Scrum recommends three to nine as the ideal Development Team size. This size range becomes five to eleven if you include the Product Owner and Scrum Master. Research by Harvard Professor Richard Hackman² shows that the smaller end of this range, five members, is best. It allows for fast communication saturation and team alignment. And it provides adequate skill and perspective differentiation to complete the work.

Read more about stable, small teams here:

Agile Leader Pattern 2 for building awesome teams: Stabilize Teams

Agile Leader Pattern 3 for building awesome teams: Small Is Big

2 Yesterday’s Weather

Teams often have to forecast how fast they can deliver a backlog of work. It is best to take an average of the team’s recent performance to inform this forecast. This is the technique for “Yesterday’s Weather.”

Meteorologists use yesterday’s weather to predict today’s weather. As such, the team will use recent performance to predict future performance.

New teams have no past performance to consult. Resist the temptation to run simulations or guess about a new team’s ability to move through the work. If there is no past performance to consult, creating a forecast is meaningless. To forecast a team’s ability to move through the work, let the team start working. This will soon provide real historical and recent data to inform a forecast.

3 Swarming: One-by-one Production

Swarming provides a simple, comprehensive method to stop starting and start finishing. It enhances teamwork and supports cross-skilling.

At its core, swarming lowers the Story work-in-progress (WIP) limit to one Story in-progress at a time for the Scrum team.

A WIP limit of one requires all team members to work at the same time on the same high priority Story. The goal is to get this Story to “done” before anyone on the team moves on to the next story. This ensures the work finishes in increments throughout the Sprint in priority order. Everyone contributes to this focused goal.

Swarming is one of the most powerful techniques I have ever witnessed. It enhances all aspects of the team dynamic.

You can read more about swarming below:

Gain Control By Breaking Dependencies: Task Level

Out With the Old, In With the New

4 Interrupt Handling Pattern

Teams that plan for interrupts, even if no interrupts occur, perform much better than teams that don’t. The pattern has five steps:

1. The Product Owner, along with the team, sets aside a capacity for interrupts.
2. The team handles interrupts within the capacity.
3. When interrupt capacity is reached, the Product Owner decides how to address new interrupts. For example, scope may need to be removed from the Sprint if the interrupt is urgent. Or addressing the interrupt may need to be delayed until the next Sprint. 
4. The team aborts the Sprint if they exceed the interrupt capacity. The pattern uses this as a deterrent to exceeding the capacity. No one wants to abort the Sprint if they can avoid it. This helps the team and those outside the team observe the capacity limits.
5. The team consumes any unused capacity at the end of the Sprint.

This pattern is powerful when taken together with the Swarming pattern. When combined, teams uncover an ability to meet the Sprint Goal early and move work to “Done” faster.

You can read more about the Interrupt pattern here:

Limit What You Start to Go Faster: Swarming and Interrupt Handling

5 Daily Clean Code

Daily Clean Code is a solid, powerful pattern for building team excellence. It upholds the notion that disorder breeds disorder and slows you down.

At its core, its goal is to achieve “Done” at the end of every day. “Done” means tested, shippable code with no defects. If the team discovers a problem unrelated to the work while performing the work, they fix it too. They leave the codebase cleaner than the way they found it (Boy Scout Rule).

Also, the pattern includes keeping a clean workspace, ready for the next day of work. This means everything is in its place. All visual boards and electronic tools are up to date with the current state of the work. The team area is tidy.

The idea is to accomplish the daily cleanliness goal at a sustainable pace. It requires small batches, swarming, and teamwork. And the team must inspect and adapt to remove obstacles preventing daily clean code. The daily cleanliness goal drives incremental improvement.

You can read more about daily clean code here:

Customizing Coaching to a Team’s Technology Context

6 Emergency Procedure

You need an emergency procedure to perform if your Sprint Goal is in jeopardy at the mid-point of the Sprint.

When the Sprint Goal is in trouble, follow this emergency procedure without pause. Like a fighter pilot, don’t hesitate when facing trouble. Just act on the procedure. Achievement of your Sprint Goal depends on it.

The procedure is as follows:

1. Change the way the team is performing the work. Do something different.
2. Get help. For example, offload backlog to another team or ask an Agile Leader to help remove an obstacle..
3. Reduce scope.
4. Abort the Sprint. Replan and inform management of delays. This is an extreme measure. Use this only when there is no option to recover after exhausting all options in the first three steps and there is no value in finishing the Sprint. 

7 Scrumming the Scrum

The goal of Scrumming the Scrum is to use Scrum to improve scrum. The idea is to act on one high-priority improvement in each Sprint.

To do this, elevate improvements and treat them with the same urgency as the product work. Add the improvement to the Sprint backlog like any other story. Give it acceptance criteria, discuss it in the Daily Scrum, and progress it to “Done.”

This will eradicate impediments and make significant improvements over time in team delivery.

You can find more reading relevant to Scrumming the Scrum here:

Let’s put the “Continuous” in Continous Improvement

Agile Leaders Must Build a Problem Solving Culture

8 Happiness Metric

Happiness is a result of team autonomy, mastery, and purpose. Anticipated happiness is key leading indicator of future performance. A team that is happy about their future performs better. Teams that track their happiness level often do so throughout the Sprint on a big, visual board. They record salient events that impact anticipated happiness along the way.

The team tracks their Happiness Trend daily. They can reflect on this trend either during the Daily Scrum or outside of it. This allows them to adjust fast to address problems. And they use it in the Sprint Retrospective to solve thematic problems that impede anticipated team happiness. The team will also raise some improvements to their Agile Leaders to assist in correcting.

A happy team is a productive team. An unhappy team is not. Prioritize happiness as it is a bellwether for your future performance, sustainability, and longevity.

9 Finish Early to Accelerate Faster

Stretch goals and dates do not motivate a team. And they do not make them deliver faster. Using the other eight patterns will help teams finish work sooner. And this is how they accelerate.

The diligent practice of the hyper-productivity patterns will result in the team finishing a Sprint early. Then, they have an option to pull new work into the Sprint and deliver more. This is how a team increases its velocity in a sustainable way. They improve their team behavior and control disturbances. As a result, their productivity increases. And they can perform work as a team with increased effectiveness.

This is how a team improves their productivity over time. It is not forced. A team proves their way to better productivity. Finishing early is proof. Finishing early allows a team to reflect earlier on the value of what is produced. After all, increasing velocity is not the goal. Delivery of value is. 

Read more about avoiding date-driven behavior here:

Remove Date Driven Behavior to Achieve Agility

---

Yes, Scrum is not easy. But helpful tools from Scrum’s origins can guide us on our journey.

Teams that finish early accelerate faster. The nine patterns of hyper-productivity provide worthwhile behavior patterns for teams to try. If you struggle to prove the value of Scrum to your organization, these patterns will help. They ease the adoption of the Scrum framework into the organization. And with habitual practice, teams will continue to improve their productivity over time.

I encourage you to give these patterns a try. Try them one at a time to see how they improve your team. If you are willing, try several out at a time. Their strength increases exponentially when used together.

Your team will grow together and experience significant improvement through these patterns. I am confident your team will never want to turn back.

---

You can read more detail about these patterns and many others at Scrum Published Library of Patterns and in A Scrum Book: The Spirit of the Game by Jeff Sutherland, James O. Coplien, et Al.  

Also published in Serious Scrum on Medium.

---

References

1. Teams that Finish Early Accelerate Faster: A Pattern Language for High-Performing Scrum Teams. Jeff Sutherland, Neil Harrison, Joel Riddle 2014 ↩
2. Leading Teams: Setting the Stage for Great Performances. Cambridge: Harvard Business Review Press, J. R. Hackman, 2002. ↩