6 Potent Power Patterns Every Scrum Master Can Use Today

Great Scrum Masters understand team development and intentionally coach and improve their team’s performance over time. A Scrum Master can equip Team Members with helpful tools and best practices by learning and using power patterns.

Power Patterns help the Scrum Master build happier teams that can work more efficiently, remain stable over time, and continue developing and expanding their skillsets. Power patterns should be incorporated throughout the Sprint and reaffirmed frequently.

If you are unfamiliar with power patterns, we’ve selected 10 essentials to illustrate the importance of coaching and development within a Scrum Team.

Happy teams are better performers over time

Most would agree that an engaged worker is more productive and generally better for the team and organization as a whole.

Less discussed is the subtle link between engagement and happiness that exists within individual team members. However, this is an important discussion because the happiest employees also tend to be the most loyal and engaged.

In Scrum, The Scrum Master should be intentional about measuring, analyzing, and improving happiness amongst the team even though it is difficult to attribute an increase in happiness to one specific change. Instead, the Scrum Team’s working agreement, communication, and activities are constantly iterating over time to increase this metric.

Quantum entanglement means forming a bond among team members

An interesting quirk of quantum physics is that it is possible to link together two particles to essentially make the two parts of the same whole. Once complete, these particles can be separated far apart, and still, one change will instantly reflect on the other.

In Scrum, we talk about quantum entanglement in the context of forming bonds with team members. Practically speaking, this means teams should work collocated as much as possible, especially in the beginning.

This power pattern has become more relevant than ever today as many teams find themselves working remotely, either temporarily or permanently. Without face-to-face meetings, it can be difficult for individual team members to form close bonds. In cases where some team members work remotely while others are collocated, negative ‘us and them’ behavior can develop.

To address this issue, consider following this three-step process when creating teams or adding team members to an existing team:

  • Initialize – establish a bond by encouraging team members to work together locally
  • Inspecting – The Scrum Master should intentionally watch for signs of team degradation and dysfunction
  • Adapting – If dysfunction is found, work should be done to repair the damage and reestablish face-to-face working experiences.

Stable teams provide more predictable results

Scrum Teams should be autonomous, empowered, and dynamically changing to meet the demands of the product they are creating.

At the team level, dynamic change can cause volatility in performance during the short term but will lead to stronger, more predictable performance increases over time. As a result, Scrum Teams thrive when they are kept small and stable because they can capitalize on the long-term benefits of doing good Scrum over time.

These stable teams tend to communicate better, work more efficiently, and continue to improve their performance over time incrementally.

At the organizational level, predictable results and reasonable expectations about the future allow leadership to make better decisions and achieve greater success.

Swarming helps complete PBIs more efficiently

The best Scrum Teams can prioritize working on one Product Backlog Item at a time as a team in a process known as ‘swarming.’

Swarming helps minimize the amount of work in progress by allowing the team to be creative as a group during production while also reinforcing the necessity of testing the product before moving on to another task. This behavior also helps teams avoid the compounding negative effect of task switching and multitasking.

As a best practice, allow one team member to take the lead on each PBI – everyone on the team must then help the leader complete the work until it is finished. Once complete, a new team member can take the lead on the next task.

Teams that finish early accelerate fast

The Scrum framework exists to help improve performance over time, and much of that work involves addressing the negative tendencies that many teams develop.

One such negative tendency among Scrum Teams is that they simply take too much work into their Sprint and cannot finish it. While occasional failure is expected and even healthy in some cases, frequent failure is demoralizing and leads to inconsistent or low performance over time.

Teams should focus on finishing a smaller amount of work early rather than a larger amount just in time to combat this issue. Extra time within the Sprint can sharpen skills amongst team members, pay down technical debt, and generally create opportunities for work multipliers to develop.

Fortunately, using Yesterday’s Weather and a powerful system for handling Interrupts helps keep the Scrum Team honest about their capabilities, allows them to celebrate successes, and contributes to faster acceleration over time.

Emergency procedures salvage work from a failed Sprint

Although the term ’emergency procedure’ sounds more appropriate for a fighter jet manual or a plant’s safety department, any team doing important work needs a system in place to protect them when things go wrong.

In Scrum, the Emergency Procedure Power Pattern exists to salvage a Sprint that is unable to be completed successfully due to the following reasons (or something else entirely):

  • A loss of personnel or equipment
  • Technical issues
  • Emergent and unavoidable interruptions
  • Overestimated work capacity
  • Underestimated work

Despite their best efforts, any one of these issues could cause a team to fail a Sprint. When the team realizes that the current Sprint cannot be completed, they should ‘push the red button’ and activate their emergency procedure.

Importantly, anyone on the team should feel capable of pushing this button and having a conversation as a team.

Typically, a Scrum Emergency Procedure will include:

  • Doing something different – changing the way the team does work or who is doing the work
  • Getting help – offloading backlog items to another team or accepting external help
  • Reducing the Sprint Goal to exclude a portion of the accepted work
  • Aborting the Sprint completely and replanning
  • Discussing the issue with management and stakeholders

Does Agile Scrum Kill Innovation? (Iterative Problem Solving)

Scrum is designed to solve interrelated problems common – but not unique – to software development projects: project scope and estimation.  

Do these problems also exist in innovation projects? Will the Scrum solutions work for innovation projects as well? Short answers: Yes and Yes. 

Applying Agile Scrum methodology to the process of Innovation allows the product team to define the scope of the project more clearly, identify emergent work more easily, estimate the work to be done more accurately, and demonstrate value to customers and stakeholders more frequently.

Let’s walk through what Scrum looks like within traditional software development and then pair it with common problems faced by innovative teams.

How Scrum uses emergent prioritized work to solve problems

Scrum developed ways to address the problem of project scope (the total amount of work needed before the project can be considered done). Since software can do so many things, it is hard to limit our needs. Therefore, project scope in software development has always been a huge problem.  

In software development projects, project scope usually starts out too big and only increases as the project progresses. Without understanding the project scope, it is hard to know when a software development project is ‘done.’ Therefore, projects often end when they run out of money or time, rather than being declared ‘done.’

Scrum addresses the project scope problem through ’emergent prioritized work,’ collectively referred to as the backlog. The backlog starts with currently known work and collects emergent work as the effort proceeds.

In Scrum, one person (the product owner) prioritizes the backlog; this makes the backlog manageable. In each iteration, the team faces a limited set of high-priority work and understands what it means to declare that set of work ‘done.’

When an iteration is completed, the project must always be functional so the users can touch and feel it for flaws or errors. Each time, the product owner shows the results to the users and asks their opinion on business value created or development errors (often some version of ‘what do you hate most’). In this way, the biggest possible mistake or waste of time is limited to a single iteration. If the project is off the rails, it can be reoriented before too much damage is caused. Thus, the process creates ideas for additional, emergent work which can be added to the backlog. 

The product owner prioritizes the backlog items according to business value. In this way, the product owner can compare the business value created by an iteration to the cost of that iteration. If there is no combination of work items with a total business value larger than the cost of an iteration, then the project is finished. 

Innovation projects have similar problems.

How do we decide what the most pressing problem is?

How can we know when we’re done (or even when we will be done)? 

Why Agile Scrum is best for innovation 

We build the result a little bit at a time, ensuring the work we’re doing fits within the whole idea of done and to make sure we’re also collecting any emergent work. This incremental approach helps solve scope problems in innovation projects, just like it does in software development projects.  

Another problem iteration can help solve is estimation. Everyone wants to know how much a solution will cost and/or when it will be done.  

Any time we discuss something in the future, we engage in estimation. Given what we understand in the present, we make predictions on how the future will play out. Unfortunately, the only truth we can predict is that humans are terrible predictors of the future (flying cars, anyone?).

In fact, we are so terrible at prediction that our only defense is to think small. Scrum helps solve this by using an iteration small enough that it allows:

  1. Product backlog items to be estimated reasonably well
  2. The risk of an estimation error to stay at a manageable size. 

Over a handful of iterations, the team’s productivity per iteration (velocity) becomes apparent. The product owner can then estimate the completion of the known backlog with a reasonable level of accuracy. If this estimate is over budget or schedule, the backlog can be pruned, and/or the organization can (carefully!) work to increase the team’s velocity. 

When you’re involved in innovation efforts, consider a lightweight Scrum process involving:

  1. A backlog of needs
  2. Iterations of work focused on a few specific needs from the backlog
  3. Regularly showing how your solution actually works (even if it works poorly).

This way, you can focus on the most valuable work while effectively collecting emergent work and managing costs and schedules.