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
