Hello, I’m Yana Obach, I work as a Scrum Master at TSK Insurance House. I want to share my professional story. So, there were several personal events in my life that motivated me to create a self-organized team that could independently follow Scrum, adhere to all events, work efficiently and complete all incremental tasks without involving a PO to solve ongoing problems. It is precisely in such cases that we can talk about the Scrum Master as a service. That is, a Scrum Master, as a service, is when you come to the team for some request, help it and leave. And the team remains alone, completely alone, and it should be absolutely fine with that. That’s how everything works in a perfect world, or at least it should.

In general, the idea of ​​a Scrum Master as a service appeared in large companies such as Raiffeisenbank, Oschadbank, Dodo and others. There are a lot of Scrum Masters and even more teams, and really all teams are mature, independent and simply turn to Scrum Masters with requests to conduct a retro, pro-facilitate a certain event, create a thematic workshop. Talking with Scrum masters in other organizations, I realized that many can lead 2, 3, and even 4 teams at the same time, and even bypass half of the company in six months. But how? – Creating a self-organized team. My goal was to make my team work without me.

Let’s imagine the situation that you are leaving the team, can you answer affirmatively to 4 questions:

• Does the team understand what processes you have already set up?

• Does the team understand why you set up your processes this way?

• Can the team do it again without you?

• Can a team improve on what you’ve done on your own?

If you answered NO to even one point, then you will clearly face problems, just as I faced them, rapidly moving towards creating a self-organized team.

When I was somewhat convinced that my team was strong enough and self-organized, I decided to go on my first vacation, thinking that everything would work without me as well as with me. What did I face? My team immediately canceled the Sprint Retrospective!

Conclusion 1: Just because you think the team already has processes, doesn’t mean they actually do! Everything can work only because you do it as a team. The team can accept the process if it is clear why it is for them, and also own it, because today we brush our teeth every day and do not think about it anymore. In my case, the guys simply did not start gathering, because the nearest release was not far away and everyone unanimously decided that the retro would wait for a better moment, or when the Scrum Master would be in place. By the way, the guys really believed that if there is a Scrum Master, that is, all activities and our processes, if there is no Scrum Master, then everyone is free. But it doesn’t work like that, and I’ll tell you what we did next.

Conclusion 2: Diagnose the command. In order for the processes to work, diagnostics are needed. I clearly understood that the work should be large, we held several retrospectives, where the team answered various questions, diagnosing our processes, culture, relationships, measures, quality, including taking radar retrospective. The model also helped us a lot Squad Health Check, to which we also devoted some time. Considered team growth with help models of team dynamics according to Tuckman and, having determined our level of development, made action plans for improvement. Next, we met separately with the development team, the analyst team, and the tester team, where we went even deeper into the team’s current issues and how to fix them. Reviewed and discussed separately the process of analysis (documentation requirements, DoR and DoD), development (code style, unit tests, refactoring, technical responsibility, etc.) and testing (eg test cases) in the team. With this proposal, I want to highlight that we looked at complex problems, and not just relationships and culture in the team.

Then she communicated with the team through one-to-one meetings, where they discussed personal problems that the guys, for various reasons, could not raise at joint meetings. As a result, I had a huge list of how to continue working with the team, and most importantly, what the team wanted to change right now, so I came to the third conclusion.

Conclusion 3: Contract with the team. The team and I created some kind of document in a few meetings (only at Sprint Retrospectives) that we placed in our space on Confluence, where we wrote down all our commitments, and we did it in such a way that everyone was OK with it. This document was created from all the points I wrote about above. “We all signed with blood” and went our separate ways, the miracle did not happen immediately. We didn’t have enough motivation, I understood that we needed booster boys who could support the whole team and borrow the processes that I was doing in the team at the moment.

Conclusion 4: Immediately give to the team what it can do independently. How we did it: there are people in the team who can somehow drag Scrum processes, I asked them to stop doing it. Fortunately, one of those people is our analyst, who at some point went on vacation. While he was not there, we worked out a lot of problems in the team, agreements and solved difficult issues. As a result, we were able to cope with everything that the team had already carried out all the Scrum processes on its own.

So, we diagnosed, contracted, introduced changes, and in the future it remained to transfer the processes to the team. I found volunteers, they are not the people who dragged all the processes to this, they are other ambitious guys who are not indifferent to the fate of the team. I don’t try so hard to take care of them, I don’t try so hard to stick to the processes and I try to pretend to be a lazy Scrum Master and I always repeat the phrase that I won’t do teamwork for you. Now I have another team and new responsibilities at the organizational level, so in such conditions the first team has grown a lot and can be called as such a self-organized team.

Conclusion: I knew that Scrum Master as a service has been in Russia for a long time. There are videos and articles on the subject where guys describe the process, but I’ve never tried it on myself or my teams. I want to say that this is a cool thing. First of all, visibility: when working in one team, you see only its cases, only its problems, and if you work “Scrum Master as a service”, then in a year you can go through about 3-4 teams in order to change and implement something there , adjust processes, and therefore three times more cases, tasks. You can see clear patterns of behavior, and somewhere, on the contrary, unique situations.

Secondly, you are constantly collected and focused on a quick result, you don’t have time to create some cool process, because his guys will never repeat it without you anyway!

With my experience, I urge you not to be afraid to experiment with the format of your work, if the company allows it. In any case, each approach is worth studying and trying for yourself. Now back to the very beginning of my article, can a Scrum Team work without a Scrum Master? Maybe when the Scrum Master works as a service.