Neki bi rekli da je uloga Scrum Master-a krajnje nezahvalna. Metodologija nam govori da Scrum Master ne bi smeo predlagati rešenja i preuzimati zadatke drugih kako bi mogao da se posveti timu. Scrum Master nije rešenje problema, već svetionik koji čini probleme transparentnim i povezuje eksperte da rade na rešavanju istih. Završavanje i rešavanje jednog zadatka ili problema koji nije u okviru uloge, vodi ka završavanju sledećih, i tako u krug. Scrum Master ne treba da organizaciji daje ribu kako bi je nahranio i ostavio u životu, već treba da je nauči kako da peca kako bi bila sama sposobna da preživi. Zadatak Scrum Master-a je da trenira i uči organizaciju o metodologiji, a ne da završava zadatke koji su odgovornost nekih drugih uloga. Iskustvo mi je pokazalo da su to najčešće zadaci Product Owner-a.

U većini organizacija Product Owner-i su osobe koje imaju mnogo iskustva u oblasti u kojoj rade, dobro poznaju i definišu nove proizvode i  procese. Takođe su jako i dobri prodavci, i imaju u sebi izražen instikt preživljavanja. Kao takvi oni su alfa mužjaci ili ženke. Ovo ne mora nužno značiti da alfa momenat dolazi iz ličnih osobina, ali njihova uloga i odgovornost da osiguraju povraćaj investicija ih dovodi da ispolje ove karakterne osobine.  U velikim korporacijama, izazov je pronaći Product Owner-a koji je 100% posvećen trenutnom projektu i koji ne radi na strategiji i planiranju novih.  Ukoliko se nađete ili ste se već našli u ovakoj situaciji, vrlo verovatno će Product Owner-imati izraženu želju za delegiranjem zadataka kako bi postigli sve svoje ciljeve koje izlaze i van okvira projekta na kojem zajedno radite.

Ovaj tekst nije namenjen iskusnim Scrum Masterima koji lako prepoznaju ove situacije , već početnicima, koji bi trebalo da nauče da nije strašno reći ne, ukoliko razumete metodologiju i Agilni Projektni Menadžment. Iz svog ugla i iskustva koje je još sveže, pokušaću da podelim par saveta koji su meni pomogli da izbegnem da postanem sekretar Product Owner-a. To nije lako, ima mnogo zamki, ali neke možete prepoznati na početku, na osnovu pitanja i zahteva:

Da li znaš kakvi su nam kapaciteti za naredni Sprint?

Pošto se angažovanje kvalitetnih stručnjaka u velikim korporacijama radi van agilnih timova, veoma često postoji jedna osoba koja se bavi potrebnim veštinama i kapacitetima development tima. Ovo nije idealna situacija po metodologiji, ali neke stvari se ne mogu tako lako promeniti. Pitanje koje sam najviše puta dobio od Product Owner-a je, “Kakvi su nam kapaciteti za naredni sprint, da li mogu da planiram više User Story-ja?”. Prvo pitanje koje sam tada postavio sebi, zašto ne bih pozvao odgovornu osobu i proverio to u ime mog Product Owner-a? Naravno potrebno je dva minuta samo, meni može dati sve informacije koje mi nedostaju za Sprint Planiranje. Okrećem telefon, dobijam informaciju, distribuiram je dalje, i dobijam novo pitanje, “A zašto je tako malo, prošli put je bilo više?” Kada se ovako nešto desi, znajte da ste  ušli upravo u “razmenu vatre” između ljudi koji plaćaju uslugu i koji naplaćuju uslugu. Momenat je odmah da se izvučete posle prvog pitanja, i da ih pustite to da reše između sebe.

Predlog kako da rešite situaciju:

1. Ukoliko prihvatite da postavite pitanje, napomenite da mu/joj činite uslugu samo ovaj put. 
2. Ukoliko dobijete dodatna pitanja i od jedne i od druge strane, recite im da pozovu drugu stranu, kako ne bi gubili vreme na ping-pong komunikaciju.
3. Recite NE na početku. To nije zadatak Scrum Master-a, Scrum Master radi sa podacima za kapacitete i ciljeve za razvoj koji su dostupni od drugih odgovornih osoba. Uvek je lepo zaključiti celo obrazloženje, da morate da poštujete metodologiju.

Dodatne informacija: Kompanije koje tek usvajaju Agilnu projektnu metodologiju i Scrum kao framework, koriste dostupnost članova tima, da formiraju kapacitete izražene u stori poenima. Ovo nije pravi pristup po metodologiji, već tranzitna faza ka isporučivanju biznis vrednosti, a ne sati koji su provedni na projektu.

Pisanje User Storija: Da li možeš da dodaš za mene ovaj Story u sistem?

Svaka tužna priča Product Owner-a počinje sa: “Eh da imam više vremena da napišem dobre User Story-je”. Koliko puta ste čuli ovo pitanje? Da li vas je nateralo, da kažete, “E, ja ću ti pomoći!”. Ako jeste,  sedite i sačekajte da vas ta želja prođe. Tendencija naših Product Owner-a je da zadatke koje oduzimaju mnogo vremena kao što je pisanje User Story-ja, prebace na Scrum Mastere. Činjenicu da poznajete sistem koji koristite za praćenje projekta (npr. JIRA), je savršen izgovor da biste to trebali vi da uradite, jer ako vi to radite nećete uništiti strukturu. Ukoliko to uradite jedanput, uradićete i drugi i treći put. Zašto? Zato što ste razmazili vašeg Product Owner-a. Ovo je prvi korak da postanete sekretar i to dobar!

Predlog kako da rešite situaciju:

1. Predložite da uradite jedan stori zajedno, kako bi pokazali kako je jednostavno da se unese u sistem.
2. Ukoliko dobijate word ili PPT za User Story, pitajte ga/nju da li bilo pametnije da se odmah promene zabeleže u sistemu, a ne u nekim drugim alatima.
3. Recite da niste Copy Paste Master, i da vam trebaju dodatne veštine za to.
4. Jasno komunicirajte da to nije zadatak Scrum Master-a, i da je backlog odgovornost Product Owner-a.
5. Recite NE, vaš prioritet je da radite sa timom.

Ukoliko dozvolite da se ovo desi, ovo će biti uvod da Scrum Master može objasniti User Story-i timu u izostanku Product Owner-a, jer Scrum Master poznaje backlog koliko i Product Owner. Pored sekretara, sad ste postali i glasnik.

Backlog Grooming Sesija: Da li možeš da otvoriš User Storije sa svog računara?

Pali ste na pitanju iznad. Uneli ste sve unapred. Ciklus (vremenski raspored) sprintova je unapred poznat, zadatak Scrum Master-a je da rezerviše Scrum sastanke za ovu sesiju unapred za vreme trajanja celog projekta. Sigurni ste da će ova dva ili tri sata Product Owner biti samo vaš, i da ćete uspeti da pripremite User Story-je a sledeći Sprint.  Dolazite u sobu, zajedno sa njim, i Product Owner vas ljubazno zamoli da otvorite User Story-je sa svog računara. Krećete se kroz sistem, pronalazite ono što je bitno za ciljeve koje ste definisali. Pitate ga za komentar i kako dalje bi trebali da formulišete korisnički zahtev, a u međuvremenu Product Owner je u punom zaletu i kuca mejl koji nema veze sa projektom. Nestrpljivo ga čekate da završi, ali govori kako je to bitno i da mu date 3 minuta. Nekako ste iznenađeni što ovo nije jedina situacija, već se ponavila najmanje pet puta. Izlazite sa sastanka, i Product Owner vas pohvaljuje kako ste uradili sjajan posao sa njim. Naravno da jeste, jer ste mu izvlačili klještima reči iz usta i upisivali u sistem, dok je on završavao sebi brisače, letnje gume i letovanje u Paraliji za dvoje.

Predlog kako da rešite situaciju:

1. Uzmite mu računar i ponudite mu da piše sa vašeg, ili se dogovorite da pišete sa računara Product Owner-a. Projektujte sliku na zid.
2. Ne zaboravite moblini telefon, danas su kao računari, uzmite i vaš i njegov i sklonite ih sa strane.
3. Uzmite mu i lični telefon, da ne počne da igra SIMS 2.
4. Jasno mu komunicirajte da kvalitet Sprinta i šta će development tim isporučiti zavisi od ove sesije i kvaliteta User Story-ja za koje je on odgovoran.

Verovatno se pitate zašto da upotrebljavamo dečije metode? Ukoliko im to uradite dvaputa, osetiće se glupo, pa će na sledećim sesijama, dolaziti spremni, i sami će ostavljati telefone i laptove sa strane. Meni je uspelo sa dva različita Product Owner-a, tako da probajte uz osmeh i dobru šalu. Ne može puno da vas košta 🙂

Product Owner-i će uvek imati tendenciju da kažu da je backlog spreman za sledeći sprint jer imaju sve informacije u svojoj glavi. To ne znači nužno da će ostalima biti sve jasno na osnovu siromašnih informacija koje se nalaze unutar svakog storija.

Da li sam vam potreban u projektnoj sobi ove nedelje?

Prošli ste olujnu fazu i tim konačno manje više radi bez problema. Product Owner je primetio da postoji prostor i vreme da se posveti drugim zadacima i konceptima van projekta, umesto da sedi sa timom i radi na njihovom razumevanju User Storija za trenutni sprint. Ponedeljak ujutru, zvoni vam telefon i prvo pitanje je: “Da li sam vam potreban/a u projektnoj sobi ove i sledeće nedelje?” Vi pitate zašto, a Product Owner kaže da imaju jako kul i strava konferencije u Hamburgu i Kopenhagenu. Takođe ove nedelje su posete regionalnih direktora, pa bi im valjalo posvetiti malo pažnje. Odgovor naravno želi odmah, jer kalendar mu je/joj ionako pretrpan. Vi bojažlijvo na osnovu ličnog osećaja u stomaku, kažete “pa ne baš, mislim da smo…”, a dok ste počeli sa drugom rečenicom, već ste dobili zadatak da mu budete zamena i da prikupite sve informacije i da mu ih distriburate. Ova rečenica vrišti na “Dobro jutro sekretaru moj, sažvaći mi sve u petak, da mogu na vikend bez čitanja 100 mejlova.”

Predlog kako da rešite situaciju:

1. Stavi  mu/joj do znanja da odustvo može dovesti do toga da je feature pogrešno implementiran, jer zahtevi nisu razumljivi i ispravljeni pre same implementacije.
2. Svako odlaganje odluka za jedan pa i više dana, može dovesti do kašnjenja i  neisporučivanja feature-a koje su predviđeni za Sprint.
3. Pitajte da li je ok da tim sam donosi odluke i menja korisničke zahteve ukoliko postoje signali kašnjenja.
4. Poručite da ukoliko je prisutan/a, tim može brže da razjasni sve nejasnoće i da isporuči rešenje i vrednost koje odgovaraju korisničkim zahtevima za planirani Sprint.

Nemojte se bojati da kažete da Product Owner treba da postavi prioritete ka proizvodu pre svega ostalog, ako želi proizvod koji će korisnici koristiti i koji će ih učitniti srećnim, a njega/nju dovesti u situaciju da ostvari ROI za projekat.

Kasniću na Sprint Planiranje, da li možeš timu da opišeš User Storije i ciljeve?

Tim nestrpljivo čeka da vidi šta su ciljevi za sledeći Sprint.  Sprint Backlog  je spreman. Dolazite u sobu za planiranje, ali Product Owner još nije stigao. Zvoni vam telefon, a Product Owner kaže “Kasniću dvadeset minuta, sastanak za drugi projekat se odužio, da li možeš da prestaviš ciljeve članovima tima”. Kažete zašto ne, ali posle toga sledi gomila pitanja, na koje ne možete da date odgovor. Tim postaje nestrpljiv, jer ne razume šta su ciljevi i kako će ih dostići. Čak iako znate odgovore, postoji velika šansa da ih loše interpretirate, jer ih vi niste definisali.  Odlučujete da pređete na objašnjavanje User Story-ja, ali tu se suočavate sa još većom lavinom pitanja, sa kojom ne možete da se izborite. Bravo, da, upravo ste dostigli funkciju senior sekretara Product Owner-a,  jer tim očekuje da po njegovom/njenom dolasku, saopštite sva pitanja koja su oni postavili.

Predlog kako da rešite situaciju:

1. Objasnite mu/joj da odustvo može dovesti do toga da je feature pogrešno implementiran jer zahtevi nisu razumljivi i ispravljeni pre same implementacije.
2. Svako odlaganje odluka za jedan pa i više dana, može dovesti do kašnjenja i  neisporučivanje feature-a koji su predviđeni za Sprint.
3. Pitajte da li je ok da tim donosi sam odluke i menja korisničke zahteve ukoliko postoje signali kašnjenja.
4. Poručite da ukoliko je prisutan/a, tim može brže da razjasni sve nejasnoće i da isporuči rešenje koje odgovara korisničkim zahtevima.

Miks ovih pitanja proizilazi iz same metodologije i odgovornosti različitih uloga u okviru Scrum framework-a.

Da li bi voleo/la da se pridružiš sastancima sa eksternim agencijama?

Na početku karijere ste znatiželjni da prisustvujete na što više sastanaka, kako bi pokušali da naučite što više o različitim temama. Takođe ove prilike koristite da kreirate svoju vidljivost unutar i van organizacije. Ako ste baš “velike” sreće da vaš Product Owner to oseti, često ćete dobiti pitanje: “Da li si možda zainteresovan/a da se pridružiš sastancima sa eksternim partnerima?” Cilj sastanka je naravno da adresirate probleme tima, ali ubrzo postanete notar koji vodi računa o minutima sastanka i temama koje su bitne za Product Owner-a. Ako dobijate ovako pitanje, recite slobodno da nema potrebe, i predajte listu pitanja koja su bitna timu i koju Product Owner ili neka druga osoba treba da razjasni, jer je vama bitnije da budete sa timom, a ne na sastancima.  

Nije cilj uvek samo reći ne, cilj je naučiti da za prave stvari kažete ne, i da shvatite šta je vaša uloga i prioriteti kao Scrum Master-a. Samim tim vašem okruženju će biti jasno koja je vaša uloga, jer vaše NE će uvek doći iz metodologije. Product Owner će shvatiti da vi niste sekretar, već šraf u pozadini koji nije vidljiv i koji omogućava da sistem funkcioniše bez zastoja. Shvatiće da svako pomeranje ovog šrafa može da uzrokuje na usporavanje nekog dela sistema.