Take the problem to team

Self-organizing team is an essential element in Scrum. ScrumMaster has the responsibility to help team become self-organizing. Agile coaches often give the suggestion that you should take the problem to team. While this is a good suggestion, it is too much simplified thus not used effectively in practice. I'd like to elaborate the key aspects and ScrumMaster's role in this approach.

• Define the problemIt is too often for us to quickly jump into solutions, while it is much more effective to sell the problem than to sell the solution. Slow down to first define the problem. At which boundary should the problem be defined? That is the same boundary you want to enable team's self-organizing. Why does the problem matter to the team? Make the problem clearly seen by the team.
  
• Who is "the team"?

When taking the Scrum context, it is the team who is self-organizing. That's the target we bring the problem to. However, it's beyond that if we think of self-organizing as a different thinking paradigm than command and control. What if the problem relates to two teams? Then "the team" is two teams combined. Therefore, it's really the group of people who should self organize to solve the problem.
The problem and the team are coupled. Let me give you one example from my recent coaching experience. The organization was fighting for getting the release out. The overall situation was challenging. The number of bugs found in system testing, which is still not part of their Scrum team's definition of Done, was high, and system testing was still in progress. Different Scrum teams were working separately to fix bugs, and system testing team was executing test cases according to the plan. I observed that those teams, Scrum teams and system testing team, did not sufficiently work together. Only few people had the idea about where the release was heading. The problem in this situation was the challenge to get release out, while all teams were the people who should work together to face this challenge.

• Take the problem to team

After you define the problem and find the team to work on it, the next step is to enable them to work together. It could be as easy as sending out an invitation. Or you have to first get their buy-in for the problem and the need to collaborate with others in solving the problem. It is worth the time to gradually build the shared understanding and agreement about the problem among the people, before taking it to them for solutions.

• Facilitate collaboration

Once the whole team is ready to work on solutions, your job is to facilitate the collaboration. Try simple collaboration process as described in the book "Stand Back and Deliver", and study books such as "Collaboration Explained" and "Facilitator's Guide to Participatory Decision-Making" for skill development in this area.

• Coaching for depth and breadth

During the whole process, ScrumMaster plays a coaching role. In the beginning, you may see the problem, define it and bring it to the team. Gradually, you coach more people in seeing and defining the problems by themselves. When they start to collaborate, the greatness of the solutions still depends on their capability in problem solving. You coach them in analyzing root causes and designing experiments to verify. There are two main focuses in the coaching - understand the problem within the broader system, and analyze the deeper causes. PDCA, systems thinking, root cause analysis techniques, even scientific method are the great sources of learning.
Self-organizing is not only a team element, but also at the organizational level. Therefore, the approach is actually not only for ScrumMasters, but also for managers in Agile organization. Yes, managers as coaches!