As working as a Scrum Master is quite possible you have to manage a lot of problems of different nature.
Your team calls them “impediments”, other teams call them “you misunderstood what I said”, other people call them “a work that takes only 5 minutes”, but in your own world they are just another problem to manage.
When I begun, 3 years ago, I was very focused on problem solving and I felt very frustrated when I wasn’t able to solve them in the best way.
Day after day I understood that sometimes my real problem was not to find the solution, but to understand the problem.
Let me explain.
Commonly someone comes to me with a problem, something like this
and sometimes with a suggestion about the solution that I should apply:
“…It may seem like an exaggeration, but you know, just to be sure…”
The solution is perfect, I love it, and in his shoes I’d ask for something similar, but sadly it’s not in my power or it’s totally out of time/cost.
So what I have is a problem and a bunch of credible options:
And when I finally realized this, here it is my typical reaction:
Analyzing the thing in this way, the point seems quite obvious: I hadn’t the correct tools to solve the specific problem.
Maybe sometimes it’s just so, but to be honest I would have first to work on my reaction because the real problem started with that.
Panicked I started to find a solution frantically using a lot of energy and time.
Assuming I chose this solution:
When I got close to the problem, or at the end the problem showed itself, the situation was:
Or worst:
The result: in the best case a waste of time and resources.
The point is that in general I have to solve different problems that are not directly mine, so I have to be sure first of all to understand the problem and be sure that the people involved have the correct vision of it.
When someone is under pressure it is very common that he misunderstands the real nature of the problem (i’m the living proof!), the magnitude and even the cause itself, so I have to be calm and sure that he explains to me a problem more close as possible to the reality.
This is why the Agile framework has a lot of games about “how to drill down to the root cause of the problems” and it is focused on problems more than on solutions.
I learned that it is easy that I won’t have the tools to solve a problem in person, but what I can do is to be sure what the problem is and to know which person/team has the best tool to solve the problem.
Today I think it is more useful to focus my energies to understand problems instead of find solutions.
I think is more useful to know and understand key roles and the key people to whom to present the problem to be sure to have a solution that fits perfectly and in very short time.
Summarizing
Pingback: No problems means Problems | Agile. Angular/Js. Asp.NET & TDD
Pingback: Clarifying the expectations. | Agile. Angular/Js. Asp.NET & TDD