During your first year as a Scrum Master, you will be busy honing facilitation skills of the Scrum events and learning how Scrum applies to your unique agile organization and team. However, building your coaching competencies, while an integral part of your journey as a Scrum Master, is uniquely complicated and often gets overlooked. In this three-part series, take a deep dive into some core coaching and Scrum Master skills your organization needs from you.
In an ideal world, you would never see the clearest sign of dysfunction — when a team cannot deliver on its commitments — because your Scrum Master skills put you ahead of that problem. So, what are the signs your team is at risk of failing to deliver results?
Individualism. Though a strong product owner can provide a clear vision and help with tangible goals, it is common (especially on teams that are inexperienced with self-organization) for some or all of the members to develop an individualistic mindset. Look for sentiments like, “If my tasks are done and of unquestionable quality, I’m not the problem,” or “That’s not my job.”
As a Scrum Master, you must demonstrate the curiosity and openness your teams need to create a safe space to discover and diagnose these mindsets as a dysfunction. Observe who likes or does not like whom, the tone of and who participates in casual conversations, and who speaks or who does not, especially when conflict arises. In retrospective meetings, pay attention to whether or not your team is trying to solve interpersonal and communication challenges by implementing processes that never seem to work. Is anyone hoarding information or tasks? Ask them questions like:
If you diagnose challenges through this line of observation and questioning, you may find pairing people up to co-work to be an effective method for rebuilding relationships and shortening the shelf life of your team’s impediments. Not all personalities will take to such a solution, but when it is framed as an opportunity to cross train, even many reluctant team members will step up for a chance to develop and demonstrate an improved skill set.
Another option centers around coaching and developing your “star” team members to be team players. Though it’s often tempting to focus on strengthening your teams’ weakest links by coaching or directing them to do better, effective Scrum Masters know that often is not the most effective way to strengthen teams. Your retrospectives are designed to help your team solve weaknesses, but those meetings often let high-performers slip through the cracks with a harmful-to-the-team mentality. Encourage those individualists to identify their own growth areas, ask them to train others, and enlist their intellect in collaborative impediment removal opportunities. Help them become the helpers.
A self-organized team understands and focuses on the team and the organization’s vision and goals, so always keep those at the forefront of difficult conversations as a guidepost for collaborative success.
Indecisiveness. High-performing agile teams decide how work gets done, and it’s crucial for them to be empowered to make continuous decisions as often as questions and problems arise. Do team members struggle to provide updates and next steps for what’s in the backlog? With a clear vision and goals, teams tend to make better and more customer-oriented decisions than individuals, especially those individuals who are farther removed from the team, the problem, and the customer.
Agile teams should refine all of their work using a product backlog, or at least a sprint backlog. That way, work is prioritized for the customer’s needs, the sprint plan, the product owner’s vision, and the organization’s goals, based on team capacity, skills, and competing priorities. Teams struggle to meet their commitments or pursue goals without a product owner who has the time, skills and focus needed to groom the product backlog regularly or without a dedicated time for and approach to sprint planning.
Related: Scrum Anti-Patterns — Large Product Backlog
Often, agile teams also struggle if company leaders ask them to operate outside of their agile or Scrum-guided working agreements. Observe how much non-backlog work your team members pull in each sprint. Diagnosis (and ideally problem solving) in this area can dramatically improve your team member retention by reducing stress and confusion and, ideally, increasing clarity and autonomy.
Your teams will typically face two types of problems: Those of your customers and those that are impediments to serving your customers. Fortunately, you can use these techniques to analyze the root cause of just about any problem.
Value Stream Maps
Value stream maps in Scrum help your team view and socialize an entire process with a focus on efficiency in developing a product or delivering a service. With the flow of information, key players, and materials fully visualized, your team may discover waste, identify ways to reduce cycle times, and implement process improvements. If you’re wondering when to use a value stream map, remember it is designed to help you diagnose and reduce inefficiencies. Before you create value stream maps to show ideal workflows:
Talk to leaders and get clear on your stakeholders’ goals.
Familiarize yourself with the process and performance indicators. Important data points include capacity (employees and their working hours dedicated to this), the size of your deliverables, uptime, and downtime.
Accurately capture the current state of the process by creating a current value stream map. A value stream map includes: a process map, its timeline, and the flow of information.
5 Whys Exercise
When an unexpected event or impediment occurs, the five whys offer an effective means of diagnosing the root cause of a problem. Here’s how it works:
Invite everyone involved.
Put on your ScrumMaster hat.
Have the team roughly define what happened.
Ask “why” and have the team answer the “because” five times, each time questioning the previous answer. Your last “because” should have you pretty close to a solution.
Get buy-in and assign a solution owner.
Share it out. Storytelling does more than increase transparency, it helps increase trust and collaborative, team-driven problem solving across the organization.
Ishikawa, the “Fishbone” Diagram
Often, individuals struggle with focusing only on their perception of the problem or on how they believe that problem is best solved. Unfortunately, that leaves many stones unturned. Ishikawa breaks the cycle of our thinking patterns and opens the door for authentic and effective communication. Though the categories you use may be adapted to your needs, these are the basic guidelines:
Explain what you’re about to do and why.
Draw a simple fishbone diagram.
Clarify and solidify the problem statement.
Choose categories that best suit your team, problem, and organization.
Brainstorm possible causes of the problem, as those fit into the categories.
Identify sub-causes (root causes) for those problems you’ve identified.
Have the team choose where to focus by reviewing the diagram together.
Vote to prioritize what root cause gets solved or worked on first.
Agree on the priority order of the causes that received the most votes.
Save/document the exercise to use as a tool later if your team finds itself facing the same problems again.
About the Author
Brandy Emesal is a Scrum Alliance Certified ScrumMaster (CSM) with certifications in Agile Leadership Essentials (CAL-E) and Agile Leadership for Teams (CAL-T). With a bachelor's of science in news-editorial journalism and a background as a marketer and military public affairs sergeant, she works on the Leaders Team at Scrum Alliance, creating content to help agile leaders and aspiring agilists advance their careers and empower their teams.
Collection - Scrum Mastery: Building Blocks for Success