Što znači biti Scrum Master
Moderni poslovi su prvenstveno misaoni (knowledge work) i zahtijevaju ponešto drugačiju organizacijsku strukturu od one koju smo navikli gledati u klasičnim, proizvodnim organizacijama. Aktivnosti i zadaci koje je imao neki mali šef (poslovođa) su sad prebačene na tim: organizacija zadataka, briga o kvaliteti itd. Istovremeno se pojavila i nova rola: coach, ili ako se radi o Scrumu, onda Scrum Master.
I sad smo u međuprostoru: organizacije (uglavnom) razumiju potrebu za novim načinom rada koji odgovara misaonim poslovima, ali često ne razumiju potrebu za coachom (Scrum Masterom).
U nastavku je tekst kojeg sam napisao za potrebe jednog svog korisnika, upravo s ciljem razumijevanja te role i vezanih aktivnosti. Isprike na engleskom jeziku, ali mi se čini da nema potrebe prevoditi 🙂
What Being a Scrum Master, and a coach in general, means The role of a Scrum Master is often misunderstood, especially in environments where no similar role already exists. We're not the first organisation facing this issue, and we should learn from a wider community and experiences of other people. How to see what a Scrum Master does? Scrum Master, and a coach in general, is often seen through activities which are easily observable, such as meetings facilitation. But, the main focus of a Scrum Master is not to teach a team to be better from a mechanical perspective (such as, to have short meetings). The main focus is to make the problems (impediments) visible and to teach the team to solve them. At the beginning, probably the biggest impediment is inefficient meetings, so SM could focus on that. After the team learn how to do the meetings well, next impediment is usually connected to the team’s tendention to take too much work at the same time, and to be late with the delivery as a consequence. Next, problems with people relationships will surface, or the environment will press harder on the team. The Scrum Master has to tackle those impediments as well. Then, personal development of the team members, as they would think they’re lagging in knowledge due to focus on deliveries. Next, inevitable technical debt will be the hottest topic, while the Product Owner still thinks it’s not worth it. The list goes on. It is not without a reason that Scrum is sometimes called "the problem finding framework". We’ll for sure encounter a number of problems which Scrum helped us to recognise. It’s up to us to solve them. However, if we want to look at the SM role from that 'observable' perspective, there’s a lot more Scrum Masters do: http://scrummasterchecklist.org/pdf/ScrumMaster_Checklist_12_unbranded.pdf It’s best if we actually don’t see a Scrum Master at all, but only the effects of their efforts, which are: [Product Development] Quality deliveries at the end of each sprint [Team Development] Self-sufficient and self-sustainable [People Development] People clearly express their views on products, their own knowledge, their career paths [Competency Development] Team works more efficiently in terms of technical excellence [Environment Development] Spreading of the agile views in otherparts of the organisation, better meetings, faster decision making [etc...] But also: Continuously growing list of impediments a team is encountering At the same time, growing list of solved impediments [etc...] If we have a SM working with a team in a good way, helping the team to get better each iteration, we can accept the idea that at some point in time, the team is "excellent enough" -- meaning that the value that particular SM brings to that particular team is not proportional to the value the same SM would bring to "still not excellent" team. In that case, that SM could take the second team, while still maintaining close relationship with the first one. We assume that the first team is mature enough to be able to recognise and solve their own impediments up to some level, above which they would still need a Scrum Master. That’s the state we want to achieve. To get there, we propose the following (rather optimistic) timeline: * We begin with Scrum Masters helping one team only * While launching new teams, we have one Scrum Master per team * Each SM stays with their teams for at least three months * At the end of that period, we assess how the teams are "mature" and stable, and if there’s some space to free for their SM, so that he/she could take another team. ** It is important to understand that that another team should not be completely new one, since such a team would require a full time SM * Each three months we repeat the exercise. At some point in time we will have: * A number of experienced Scrum Masters * A number of long-lasting, experienced teams * Every single team will have a Scrum Master * Most of the Scrum Masters will have only one team * Some experienced Scrum Masters might have two experienced teams