A Scrum Master’s Guide to Creating Self-Managed Teams

Any attentive Scrum master must have noticed a slight change in statements related to scrum teams in the 2020 Scrum Guide. One of the updated texts that stood out for me is –   

“Scrum Teams are cross-functional, meaning the members have all the skills necessary to create value each Sprint. They are also self-managed teams, meaning they internally decide who does what, when, and how.”

Previously, in the 2017 version, this statement was –  

“Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.” 

While little has changed in effect, there’s added emphasis on Scrum teams deciding on ‘what’ and ‘when’ work is done as well as the environmental considerations that can ensure their success.  

The latter may be a little tricky for some scrum masters. However, the following lines will guide you to achieve this.  

12 Tips to Create the Right Environment for Self-Managed Teams 

If there’s one lesson I truly learned in my eight years working as a scrum master, it’s the importance of creating the right environment and culture for teams. Without this often-neglected factor, teams may not effectively work together to achieve their goals.  

So, here are my 12 tried and tested tips to create this vital environment and ensure its success.  

1) Ensure that the Scrum Team Creates SMART Goals 

As a Scrum master, your goal is to guide the team to create SMART goals. That way, they can become self-organized around the goal.  

SMART stands for Specific, Measurable, Achievable, Realistic, and Time-Bound. These are the parameters you should define to ensure goals are achieved within a sprint. That way, self-managed teams can enjoy several benefits including –

• Being able to visualize specific goals by breaking them down into actionable steps and micro goals 
• Refining decision-making by evaluating which steps can help achieve certain objectives  

• Effectively managing tangible progress to determine which tactics should be used  
• Exposing weaknesses and roadblocks to success 

Without SMART goals, Scrum teams may lose their ability to focus and, ultimately, waste their effort. For instance, you can have all the time in the world to complete a project. However, to ensure that it matters and delivers value, it should be delivered within a set time frame.  

2) Empower Developers to Exercise the Responsibilities Given in the Scrum Guide 

The Scrum Guide defines certain responsibilities for each role. For example, Developers are accountable for creating a plan for the Sprint and the Sprint Backlog. They also need to determine and communicate estimations against each story.  

As a Scrum master, your goal is to facilitate developers by creating an environment where they can work. Neither you nor the Product Owner should be dictating how they can fulfill their responsibilities.  

3) Empower the Product Owner to Exercise their Responsibilities as Per the Scrum Guide 

Like the Developers, Product owner have their own set of responsibilities. They prioritize the product backlog, motivate team members by establishing clear goals, and answer their questions.  

Empowering POs entails ensuring they focus solely on their responsibilities and not be sidetracked by getting involved in other members’ responsibilities.

Also, the Scrum Master has to protect and ensure the Product Owner prioritizes the product backlog instead of other stakeholders. 

4) Mute Yourself During Scrum Team Discussions 

Discussion and collaboration are important in any and all Scrum events. Unfortunately, Scrum masters may choose to get involved in these discussions, pressurizing and preventing them from becoming self-managed. 

Your role is to flick your own ‘mute’ button, be it literally or figuratively. Any contribution you add to the discussion means you’re taking over their role or mind.  

So, let developers discuss their concerns and plans so they can reach a suitable conclusion. Your responsibility here is to create an environment where the team can have healthy discussions and positive conflicts to edge towards resolution. 

5) Don’t Act as a Project Coordinator, Dictator, Bridge or Secretary  

A Scrum master may wear multiple hats. However, four they should never have are that of a project coordinator, dictator, bridge, or secretary.  

When taking on the role of a project coordinator, you become in charge of communication between developers and the PO.  

Similarly, becoming a bridge between other Scrum Team members prevents them from connecting directly to get the work done.  

Your goal is to facilitate, not dominate. So, you can’t be a dictator, mandating the team to only follow your orders. That would go against being a servant leader for the team.

Moreover, you aren’t any role’s secretary. So, for example, if anyone needs a meeting scheduled, they can do so themselves.  

6) Don’t Provide a Solution; Let the Teams Find their Way to It  

If the Scrum Team faces an issue or a conflict arises, the best way to resolve it is by not becoming involved. Yes, it’s easier for you to just fix things yourself. However, that will prevent you from creating the culture self-managed teams need to thrive. 

For instance, if someone can’t communicate in English effectively, don’t become their translator. Instead, empower the team member to learn on their own to communicate effectively.  

So, bring teams towards a solution rather than delivering one on a silver platter.  

7) Educate Developers and POs on How to Resolve Impediments  

When an impediment rears its ugly head, developers and/or POs may request you to get involved. From the previous tip, you know that you shouldn’t be offering solutions on your own. Rather, you should guide teams to resolve any problem.  

For instance, if a developer faces a VPN issue, they may ask you to connect with a network administrator.  What you need to do is request that they consult with the required resource directly. Alternatively, you can ask the network administrator to explain how to resolve the issue to the team.  

Let’s have another example to explain this point further.  

Assume a Developer had to work on a task, but had to leave due to some emergency. The team may turn to the Scrum master for help. In this case, seat them down and let them list down possible solutions. You can guide them to assess each option accordingly. 

8) Educate the Team to Utilize Problem Solving Techniques Rather than Providing Solutions 

As we established above, a Scrum master doesn’t solve problems. They teach teams to do so themselves. Building on that, one aspect you should definitely teach is problem solving techniques.  

Two that I believe can do wonders are the Powerful Questions technique and Five Whys. These allow teams to focus on what’s important before collaborating towards devising a solution.   

Continuing the example from tip #7, urge the developers to come up with different solutions. One may recommend working overtime to deliver the solution. Another may highlight that the work won’t impact the delivery date, so the team can wait for a day. A third may recommend working with a fourth developer to get the work done.  

With these options in hand, you can have the team apply different problem solving techniques to choose the best one.  

As the team identifies the problem on its own and works to resolve it, it’ll gain an important element in self-managed teams: ownership. 

9) Guide the Product Owner to Use a Collaborative Approach Instead of a Directing Approach 

A directing approach is one where managers, instruct, guide, and oversee performance to achieve goals. Without these activities, planning and subsequent steps are considered of no importance.  

However, this goes against the Scrum guidelines and the role of a PO. Especially as collaboration is important for managing request changes, mitigating risks, improving efficiency, and fueling continuous improvement.  

So, let the PO know that a directing approach won’t help achieve the goals of a project. Instead, they need to collaborate with developers to learn their opinions. Only then will every member be self-managed.  

10) Neither the Scrum Master nor the Product Owner Should Assign Tasks to Developers 

You can’t have self-managed teams if you and the PO manage everything for them. However, this isn’t the only reason why this will backfire. 

By assigning tasks yourself, you may end up restricting them to specific tasks.  

For instance, you may always entrust a developer with everything related to databases. Since they handle this task every time, the rest of the team won’t be able to expand their skill set. Moreover, the usual resource may become a bottleneck if they aren’t around since no one can do their job.  

Another problem is that the PO may not have an idea of each developer’s strengths and weaknesses. This may add chaos to a project and even result in conflict.  

So, let the developers own their tasks and decide among themselves what they should do. You’ll actually be empowering them to embrace challenges and unleash their creativity and innovation in the process.  

11) Avoid Creating a Hero in the Team and Empower the Team as a Whole 

It’s definitely easier to have a specific person handle the same technical problems. However, having this ‘hero’ negatively impacts Scrum teams.  

For starters, it demotivates everyone else on the team. As one person is deemed the best, others may think they can’t reach their level of expertise. Their efforts may also be brushed off, ensuring they don’t work further towards improving themselves.  

The ‘hero’ too is affected since they’re stuck handling the same task every time. Not only does this prevent their horizontal growth, it deprives them from truly self-managing their work.  

12) Identify the Anti-Patterns of Self-Management and Break Them 

The 11 tips you just read have identified several anti-patterns that can hinder teams from becoming self-organized. So, keep your eyes open for any of these to be able to address and break them.  

Looking for a Scrum Master and a Great Team for Your Next Project? 

DPL’s teams welcome the challenge. Our consultants can also help you come up with a profitable solution or even an idea for one. So, connect with us via the form below and let’s get you started.