The Flying Scrum doctor
28 april 2019
In your organization, some problems seem to recur, they are difficult to fix using the tools, tricks and practices you developed over the years as a manager. Maybe this problem is different and the perspective of an expert-outsider might help?
At Agilix, we regularly get asked by companies “to discuss some challenges with Scrum”. This is a great compliment for us and it is exciting to submerge into these unknown worlds, being totally blank, without prejudice and mandate; simply bringing knowledge and experience. It feels like being a “Flying doctor”, and yes, we love it!
Let me tell you a bit more how the “flying Scrum doctor” operates….
The first conversation a Scrum doctor usually has is a one on one with the manager. She starts with giving the context of the problem. It’s time to listen and try to build a mind-map of the problems, company structure, their product and customers, the teams, processes, solutions they tried before but did not work, etc. Towards the end of the conversation questions are asked to verify stuff, because we need to validate the collected data. To get a clearer picture of the problem, data has to be collected from the people in the teams and from management above the hiring manager.
We need to talk to lots of people, remembering their names and roles, smiling, listening carefully, trying to store everything that can be captured. Especially the things that are not so obvious; like the people not talking and nonverbal communication. It’s a bit like you are the new employee and you must meet the whole company at your first day at work. The difference is that we are on a mission: There is a pain that needs to be diagnosed and these people need help to find a cure. My personal preference is to work my way through the organization bottom-up, i.e. I want to talk to the teams first.
The problems we investigate are always systemic, if not, they would have been solved easily by the hiring manager. This also implies the intervention will probably not be found in the area where the manager thinks the problem lies. We observe the company as if it were a system, a living organism and try to understand what is really going on. Therefore, we need to collect input from different angles and layers across organizational boundaries and share all the things we learn and ask a lot of open questions. By doing this, people discover themselves how their system works and which part they play to keep the system in its current state. With the right people communicating at the right level (management and team representatives), good insights emerge and decisions to start or stop doing things to intervene in the system are easily taken. A condition for this approach to work is that all participants can communicate in a safe and transparent way. If not, we would not be addressing the true root causes.
Preparing the teams
Once an intervention has been identified and agreed we need to inform the teams and get them on board for a change. We all know from experience that change is difficult. Well is it? Really? I have learned it is not. Think about it: Did you ever move? Or did your get a new haircut? That is change too, and you did not mind at all! But if your wife tells you you must change your hairdo, it becomes a whole different ball game. Conclusion: Change is not difficult at all as long as it is voluntary.
Therefore, we need to get the change emerging from within. For this we need to ensure everybody gets the space and time to discover the system dynamics themselves and to contribute to the solution. Voluntary participation creates ownership of the change. This empowerment increases the chances of a successful change. We get all people involved by organising one or more discovery sessions in which teams go through the same motions we experienced when unraveling this mystery ourselves.
Some managers automatically assume that once a solution has been discovered, they need to communicate it to the teams. We need to ensure this knee-jerk reaction is gently suppressed. In other cases, management fears that the teams will not come up with good solutions and team empowerment is seen as a possible threat. In such cases it requires persuading management and informal leaders to agree on the principle of voluntary change. They need to learn that the solution they crafted so far will get better when it is discussed with all people involved.
To solidify empowerment, we want to find people to facilitate the discovery sessions with the teams. These are not the managers, but volunteers from the teams (might be the informal leaders). In order to facilitate well, they need to know what the key principles are of the solution, for example: more flexibility, fulfilling work, learning, etc. By understanding the key principles, they will be able to guide discussions that will emerge during the discovery session(s). The details of the final solution less important than everybody understanding what is needed to fix the problem.
When you try to unravel and solve complex systemic problems, gather lots of data, be curious, cut across organizational boundaries. Understanding that problems are systemic and therefore that there are multiple root causes is essential. Involve all people that appear to be related to the problem and make those who are in power aware of their possible contribution to both the problem and the solution. This awareness is what people lack. Change is easy as long as it is voluntary, so engage people in the change by offering them the opportunity to discover how their system works. Remember to love the problem, not the solution. The solution will become better when more people contribute to constructing it.
Besides coaching and writing blogs, I also teach Scrum. Maybe you want to join my upcoming PSM-2 class.
Roland works as a consultant on scaled Scrum adoptions. He is a certified Profesisonal Scrum Trainer and teaches PSF, PSM-I and PSM-II and he is a candidate LeSS trainer.
Roland speaks at international conferences, is the creator of Scrumcards (the elements of Scrum) and produces comedy movies (related to agile).