Primjer liste savjeta za ScrumMaster-aMichael James(mj@seattlescrum.com)
14. septembar 2007
Posljednja prerada 2. februar 2016
http://ScrumMasterChecklist.org
Prevod : Dubravka Widmer-Kljajo

Potpuno posvećen ulozi?
Pristojan ScrumMaster može pokrivati potrebe dva do tri tima istovremeno. Ukoliko vašu ulogu svedete na
organizaciju sastanaka, pažnju fokusirate na pridržavanje vremenskih ograničenja njihovog trajanja (time-boxing)
i uklanjanje prepreka (impediments) koje vam tim eksplicitno podnosi, možete pokriti ove aktivnosti part-timeangažmanom. Vaš tim će vjerovatno pokazati znakove napretka i vaša organizacija će uočiti razliku u odnosu na
period prije usvajanja Scrum-a i neće se ništa katastrofalno desiti.
Ali ukoliko je vaša ambicija i vizija da pomognete izgraditi izuzetan tim u tranformisanoj organizaciji, tim koji ćepostići ono sto je do ranije smatrano nedostižnim, razmotrite mogućnost da postanete izvrstan ScrumMaster.
Izvrstan ScrumMaster može pokrivati potrebe jednog tima.
Preporučujemo da se kao ScrumMaster na početku posvetite jednom timu sa oko 7 članova.
Ako želite otkriti čime se ScrumMaster koji je potpuno posvećen jednom timu svakodnevno bavi, posvetite se uokviru vašeg tima Product Owner-u i inžinjerskim praksama, a van vašeg tima organizaciji/firmi za koju je vaš tim
aktivan. Iako ne postoji jedan jedinstven recept za svaki poseban slučaj, ovdje sam iznio tipične stvari koje
ScrumMaster-i zaboravljaju ili previđaju. Molim vas da svako pitanje označite jednim od znakova √, ∆, ? ili N/A,
značenje znakova je pojašnjeno na posljednjoj stranici.

Lista I – Kako Poroduct Owner funcioniše u svojoj ulozi?
ScrumMaster poboljšava efikasnost Product Owner-a tako sto joj/mu pomaže da pronađe i usavrši načine zavođenje Product Backlog-a i release plan-a. (Bitno je primijetiti da je Product Owner zadužen za definiranje
prioriteta u Product Backlog-u).
☐

Da li su prioriteti u Product Backlog-u definisani na osnovu najnovijih saznanja Product Owner-a?

☐

Da li Product Backlog sadrži zahtjeve (requirements) i želje svih stakeholder-a? Zapamtite: Product Backlog
je emergent.

☐

Da li Product Backlog ima dobru, praktičnu veličinu i dubinu? Da bi Product Backlog imao podobnu veličinu,nastojte da Product Backlog Items na vrhu Product Backlog-a (stavke sa najvećim prioritetom) budu
detaljnije definisane (manje veličine) i konkretnije formulisane. Stavke sa nižim prioriteteom trebaju biti
smještene dublje u Product Backlog-u, te grublje opisane, bez mnogo detalja. Kontraproduktivno je ulagati
vrijeme u detaljnu analizu tema koje nisu pri vrhu Backlog-a. Potrebe stakeholder-a mogu se vremenom
promijeniti kroz konstantni razvoj proizvoda i kroz kontinuiranu kommunikaciju sa stakeholder-ima.

Copyright © 2007-2016 Michael James. All Rights Reserved.

☐Pregledajte vaše Product Backlog Items, osobito one pri vrhu Backlog-a. Postoji li mogućnost da se jošbolje formuliraju prema sljedećim tzv. INVEST-kriterijima1: nezavisan (independent), formuliran tako da se onjemu može razgovarati i pregovarati (negotiable), smislen (valuable), podoban za procjenu veličine(estimable), malen (small) i definiran na način da se može testrirati (testable).

☐

Da li ste vašem Product Owner-u pojasnili pojam tehničkog duga (technical dept) i kako ga izbjeći? Jedna
mogućnost je da vaš tim proširi definition of done, time što će listi dodati razvoj automatiziranih testova, tepo potrebi refactoring aktivitete.

☐

Da li Product Backlog služi kao radijator informacija, uvjek je vidljiv svim stakeholderima?

☐

Ukoliko koristite elektronsku alatku za Product Backlog management, da li svi članovi tima znaju kako da jejednostavno koriste? Alatke za management Backlog-a nose sa sobom opasnost da se pretvore u“frižidere/hladnjake informacija” ukoliko se ScrumMaster ne portudi da obezbijedi njihovu funkciju zračenja
informacija.

☐Možete li pripremiti odštampane plakate, kako bi važne informacije učinili još dostupnijim i prisutnijim?

☐

Da li je moguće grafički vizualizirati važne podatke i informacije?

☐

Da li ste pomogli Product Owner-u da organizira i grupira (kategorizira) Product Backlog Items po releaseterminima ili kategorjama prioriteta kako bi na osnovu njih mogao napraviti release plan?

☐

Da li je svima poznato da li je release plan još uvijek realističan? Možete li u okviru Sprint Review sastankanakon što su Product Backlog Items proglašene odrađenim/zavrsenim (“done”) svima pokazati aktuelne“burn down charts” 2. Grafike koje prikazuju volumen odrađenih Product Backlog stavki, te volumen novih
koje su rezultirale kroz razgovor sa stakeholder-ima, ukazuju na aktuelno stanje i pružaju mogućnost da seranije ustanove implikacije na termine i promjene opsega release-a.

☐

Da li je Product Owner aktualizirao release plan nakon svakog Sprint Review sastanka? Većina Product
Owner-a koji redovno izbacuju nove funktionalitete proizvoda za upotrebu korisnicima, ne aktualizira releaseplan nakon svakog sprinta. Formulisanje novih funkcionaliteta i želja sa visokim priritetom implicira
pomijeranje postojećih na niži prioritet u Backlog-u, što automatski utiče na promjenu release plan-a.

Lista II – Kako funkcioniše moj tim?
Dok se od vas u ulozi ScrumMaster–a očekije da vodite dobrim primjerom i da redovno i intenzivno sarađujete sa
timom i bavite se konkretnim temama koje tim zaokupljaju, prijeti opasnost da ćete se izgubiti u svakodnevnim
tehničkim zadacima. Zato vas podsjećamo na vaše primarne zadatke koji se odnose na tim:☐

Da li je vaš tim u flow stanju, u stanju toka? Evo par karakteristika po kojima mozete prepoznati ovo stanje3:
Jasni ciljevi (očekivanja i pravila su vidljiva, a ciljevi su dosežni, na odgovarajući način usklađeni sa
vještinama i sposobnostima članova tima).



Koncentracija i fokus, visoki nivo koncentracije na ograničeno polje aktivnosti.

Gubitak osjećaja samosvijesti, svijest je potpuno usmjerena na akciju.

1 http://xp123.com/articles/invest-in-good-stories-and-smart-tasks/
2 Mike Cohn, Agile Estimation and Planning.

(2005).

3 Mihaly Csikszentmihalyi, Flow: The Psychology of Optimal Experience (1990).

Copyright © 2007-2016 Michael James. All Rights Reserved.



Direktan feedback (uspjesi i neuspjesi u toku rada su očigledni, tako da se ponašanje i sljedeći koraci
mogu prilagoditi po potrebi).

Ravnoteža između nivoa sposobnosti i izazova (aktivnost nije ni laka, a ni previše teška).



Osjećaj osobne kontrole nad situacijom ili aktivnostima.

Rad pruža osjećaj direktne gratifikacije i zadovoljstva, pa shodno tome nije naporan.

☐Čini li se da se članovi tima međusobno slažu, da im godi društvo, te da zajednički slave uspjehe jedni
drugih?

☐Smatraju li se članovi tima uzajamno odgovornim za visoke standarde i motivišu li jedni druge da se dalje
usavršavaju?

☐

Postoje li problemi ili teme koje tim ne raspravlja, jer su previše neugodne4?

☐

Jeste li isprobali različite formate i lokacije za Sprint Retrospective sastanke5?

☐

Je li tim fokusiran na ciljeve Sprinta? Možda biste sredinom sprinta mogli ponovo zajednički pogledali
Product Backlog Items u Sprint-u sa fokusom na acceptance criteria.

☐Odražava li Sprint Task Board ono što tim zapravo radi? Posebno obratite pažnju na aktivnosti koje nisu
vidljive na Task Board-u i sve zadatke koji zahtijevaju više od jednog dana rada. Zadaci koji se ne odnose
na Sprint commitment su prepreke (impediments).

☐

Da li vaš tim ima 3-9 članova sa adekvatnim vještinama za izgradnju potencijalnog inkrementa vaseg
proizvoda (potentially shippable product increment)?

☐

Da li je Sprint Task Board vašeg tima ažuriran?

☐

Da li su artefakti za samoorganizaciju u timu vidljivi i praktični za upotrebu?

☐

Jesu li ti artefakti adekvatno zaštićeni od osoba van tima? Prekomjerno praćenje svakodnevnih aktivnosti od
strane osoba izvan tima može ometati internu trasparenciju i sposobnost samoorganizacije tima.

☐

Da li članovi tima pokazuju samoinicijativu i volontiraju za izvršavanje zadataka tima?

☐

Je li potreba za tehničkim otplatama duga (technical dept) izričito definirana u definition of done, što bi
postupno trebalo doprinijeti ugodnijem radu.

Lista III – Kakav je nivo inžinjerskih praksi (Engineering Practices) u mom timu?
☐

Da li vaš sistem za razvoj software-a ima dugme/gumb "push to test" koje omogućuje da bilo ko (vaš tim ili
drugi tim) praktično i jednostavno ustanovi, da je novi kod ugrozio postojeće testove? To se tipično realizuje
kroz pisanje testova baziranih na xUnit framework-u (JUnit, NUnit, itd.).

☐

Posjedujete li odmjerenu relaciju automatiziranih End-to-End testova ("funkcionalni testovi") i
automatiziranih unit testova?

☐

Da li tim piše sistem testove i unit testove u istom programskom jeziku u kojem razvija software? Saradnja utimu je ugrožena ukoliko samo dio tima vlada alatima za razvijanje, održavenje I izvođenje testova.

4 Marshall Rosenberg, Nonviolent Communication: A Language of Life: Life-Changing Tools for Healthy Relationships (2003).

Also consider enlisting a professional facilitator who can make uncomfortable conversations more comfortable.
5 Derby/Larson Agile Retrospectives: Making Good Teams Great (2006).

Copyright © 2007-2016 Michael James. All Rights Reserved.

☐Je li vaš tim otkrio optimalnu “sivu zonu” između sistem testova i unit testova6?

☐

Da li CI/CD Pipeline automatski oglašava alarm7 kada novi kod uzrokuje “pad” testova? Da li se vrijeme
potrebno za ovaj feedback moze reducirati na sate ili munute? ("Daily builds are for wimps." -- Kent Beck)☐

Da li se svi testovi imaju utjecaj na rezultat, status i flow u CI/CD pipeline-u?

☐

Jesu li svi članovi tima shvatili vaznost i otkrili prednosti kontinuiranog dizajna i stalnog refactoringa8, kao
alternativu za Big Up Front Design (detaljno dizajniranje unaprijed)? Refaktoring ima strogu definiciju:
mijenja unutarnju strukturu bez promjene vanjskog ponašanja koda. Refaktoriranje bi se trebalo prakticirati
nekoliko puta na sat, kad god postoji duplikat koda, složena logika uslova, loše imenovani identifikatori,
prekomjerno povezivanje objekata, itd. Refaktoriranje je moguce samo uz postojanje automatiziranih
testova koji pokrivaju sve funktionalitete, jer u suprotnom nije moguće ustanoviti, da li se ponasanje koda
promijenilo. Kontinuirano poboljšanje koda zahvaljujuci redovnom refactoring-u je od ključne važnosti za
kvalitet i čitljivost koda, te za dalji razvoj. Teško je pronaći dobre programere spremne raditi na lošem kodu.

☐

Da li vaša definition of done za svaki Product Backlog Item podrazumijeva automatizirane testove koji
potpuno pokrivaju kod, te refactoring? Edukacija u cilju TDD-a (Test Driven Development) povećava
vjerovatnoću da se to postigne.

☐

Da li članovi tima vecinom programiraju u parovima (pair programming)? Ovaj način rada dramatično
olakšava održavanje koda i smanjuje stope bugova. Ponekad se čini da pair programming iziskuje visevremena, ako to mjerimo brojem linija napisanog koda umjesto funkcionalnošću koja se može realizovati.
Vodite primjerom i inicirajte dane kada se kod piše iskljucivo u parovima. Vremenom će to motivisati kolege
u timu da se i sami tako organiziraju.

Part IV – Kako funkcioniše moja firma?
☐

Da li timovi međusobno dovoljno komuniciraju? Scrum of Scrum je samo jedan od načina da se uspostavi
ova komunikacija i to je rijetko najbolji način9.

☐

Da li je svaki tim sposoban da samostalno relizuje funkcionalitet na cijeloj liniji razvoja, preko granica
arhitektonskih slojeva10 (end-to-end)?

☐

Da li se redovito sastajete sa kolegama ScrumMater-ima i zajednički rješavate prepreke sa impediment liste
vaše firme?

☐

Da li se za ScrumMaster-e nerješive prepreke sa impediment liste firme prosljeđuju na više nivoe u
managementu organizacije i tamo otklanjaju? Da li troškove koji su vezani sa ovim preprekama možete
kvantificirati (monetarnom sumom, gubitkom vremena, gubitkom u kvaliteti ili izgubljenim šansama natržištu)?

6 http://blogs.collab.net/agile/junit-is-not-just-for-unit-testing-anymore
7 http://www.martinfowler.com/articles/continuousIntegration.html
8 Martin Fowler, Refactoring: Improving the Design of Existing Code (1999).
9 See http://less.works/less/framework/coordination-and-integration.html for alternatives.
10 http://FeatureTeamPrimer.org/

Copyright © 2007-2016 Michael James. All Rights Reserved.

(Pri tom učite iz Ken Schwaberovih gresaka: "Mrtav ScrumMaster je beskorisatan ScrumMaster."11)☐Da li je ljestvica karijere12 u vašoj firmi kompatibilna sa kolektivnim ciljevima vašeg tima? Odgovorite sa “ne”
ukoliko vaša firma nagradjuje i više poštuje arhitekturu ili programiranje od testiranja, automatisiranih
testova ili pripremanje korisničke doukumentacije.

☐

Kakav ugled vaša firma uživa u poslovnim medijima ili nezavisnim medijima po pitanju uslova rada za
zaposlene ili po pitanju kvaliteta koji nudi svojim mušterijama?

☐

Da li biste vašu organizaciju ili firmu označili firmom koja je sposobna da iz iskustva uči?

Zaključak
Ukoliko na gotovo sva gornja pitanja možete dati pozitivan odgovor i jos uvijek imate slobodnog vremena na
raspolaganju, molim vas da mi se javite.
Ne postoji jedinstvena čarobna mješavina svih sastojaka za kreiranje ljudske genijalnosti. Ova lista se sastoji odsavjeta koji mogu, ali ne moraju biti od koristi u vašoj situacji.
Kad počnete shvatati koje promjene biste mogli poduzeiti, može se desiti da ćete osjetiti strah ili nesigurnost. Toće biti znak da ste na dobrom putu.

11 Ken Schwaber, Agile Project Management with Scrum (2004)
12 Alfie Kohn, Punished By Rewards: The Trouble with Gold Stars, Incentive Plans, A's, Praise, and Other Bribes (1999)

Copyright © 2007-2016 Michael James. All Rights Reserved.

Formular za prepreke (Impediments) na nivou firme

Prepreka u formi kako se ispoljava:

Problem koji je u korijenu - primijenite metodu koja se zove “Pet puta ZAŠTO” (“5 Why’s”) da biste došli dopravih razloga koji uzrokuju problem:

Uticaj na biznis:

Uticaj na emocije / odnose:

Jasno formuliran zahtjev za promjenom:………………………………………………………………………………………………………………………...
Formular za prepreke (Impediments) na nivou firme
Prepreka u formi kako se ispoljava:

Problem koji je u korijenu - primijenite metodu koja se zove “Pet puta ZAŠTO” (“5 Why’s”) da biste došli dopravih razloga koji uzrokuju problem:

Uticaj na biznis:

Uticaj na emocije / odnose:

Jasno formuliran zahtjev za promjenom:

Copyright © 2007-2016 Michael James. All Rights Reserved.

Formular za prepreke (Impediments) na nivou firme

Prepreka u formi kako se ispoljava:

Problem koji je u korijenu - primijenite metodu koja se zove “Pet puta ZAŠTO” (“5 Why’s”) da biste došli dopravih razloga koji uzrokuju problem:

Uticaj na biznis:

Uticaj na emocije / odnose:

Jasno formuliran zahtjev za promjenom:………………………………………………………………………………………………………………………...
Formular za prepreke (Impediments) na nivou firme
Prepreka u formi kako se ispoljava:

Problem koji je u korijenu - primijenite metodu koja se zove “Pet puta ZAŠTO” (“5 Why’s”) da biste došli dopravih razloga koji uzrokuju problem:

Uticaj na biznis:

Uticaj na emocije / odnose:

Jasno formuliran zahtjev za promjenom:

Copyright © 2007-2016 Michael James. All Rights Reserved.

Formular za prepreke (Impediments) na nivou firme

Prepreka u formi kako se ispoljava:

Problem koji je u korijenu - primijenite metodu koja se zove “Pet puta ZAŠTO” (“5 Why’s”) da biste došli dopravih razloga koji uzrokuju problem:

Uticaj na biznis:

Uticaj na emocije / odnose:

Jasno formuliran zahtjev za promjenom:………………………………………………………………………………………………………………………...
Formular za prepreke (Impediments) na nivou firme
Prepreka u formi kako se ispoljava:

Problem koji je u korijenu - primijenite metodu koja se zove “Pet puta ZAŠTO” (“5 Why’s”) da biste došli dopravih razloga koji uzrokuju problem:

Uticaj na biznis:

Uticaj na emocije / odnose:

Jasno formuliran zahtjev za promjenom:

Copyright © 2007-2016 Michael James. All Rights Reserved.

UPUTSTVO
Ukoliko ste dobili ovu listu kao zadatak u toku obuke / tečaja i vas poslodavac
trenutno nastoji da primjeni Scrum, odgovorite na pitanja na osnovu iskustva koja
ste stekli. Označite svako pitanje jednim od sljedećih znakova:√(za “tako to radimo”)∆(za “mogli bismo poboljšati i imam ideju kako da počnem”)?

(za “mogli bismo poboljšati, ali ne znam kako?”)N/A (za “ne može se primijeniti na nas” ili “ne donosi nam
poboljšanje”)………………………………………………………………………………………………
Ukoliko vas trenutni poslodavac jos ne pokazje interesovanje za usvajanje
Scrum-a, odgovorite na pitanja jednim od sljedećih znakova:√(za “tako to radimo” ili “mogli bismo jednostavno to tako raditi”)∆(za “to bi bio izazov, ali znam kako bih počeo/počela”)?

(za “to bi bio izazov, ali ne znam kako bih počeo/počela”)

N/A (za “ne može se primijeniti na nas” ili “ne donosi nam
poboljšanje”)
Nakon što ste odgovorili na sva pitanja, odaberite 2-4 prepreke na nivou vašeorganizacije / firme i unesite ih u priloženi formular za impediments/prepreke na
nivou firme. Sa ove liste odaberite prepreke za koje postoji bar 1% šanse da ćeteih uspjeti promijeniti i adresirajte ih.

Copyright © 2007-2016 Michael James. All Rights Reserved.