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

Photo by Christopher Burns on Unsplash