“Common sense is not so common.”

— Voltaire, Dictionnaire Philosophique (1764)

Većina stvari koje obrađujemo i jesu zdrav razum (osim možda “push vs pull“, no i to je OK ako se malo razmisli), a svejedno nekako izostaje primjena.

Naprimjer, sasvim je razumno prihvatiti da su današnji poslovi toliko kompleksni da ih ne može odrađivati samo jedna osoba, bar ne dovoljno brzo i u razumnom roku, a svejedno se ne radi na izgradnji multifunkcionalnih timova.

Također je sasvim razumno očekivati da ljudi razgovaraju o svom poslu i sinkroniziraju se o zajedničkom cilju bar jednom dnevno, ako ne i češće, a opet to nekako rijetko viđam. Čak štoviše, ni pravi timovi nisu tako česti.

Ili preskakanje prostora za poboljšanje: razumno je očekivati da i organizacija i ljudi žele raditi bolje (produktivnije, efikasnije, brže – umetni svoju omiljenu poštapalicu), a onda se čude kad treba odvojiti sat vremena tjedno za retrospektivu. Kao, pa nemamo vremena, toliko je posla. Da, jače lupanje po tipkovnici će riješiti sve probleme.

Adding human resources to a late software project makes it later.

— Brooks’s Law

Ili meni omiljeni prigovor, kasnimo (jer nam komunikacija u timu i prema vani ne valja, ali ovaj dio se prešuti), pa ćemo dodavanjem ljudi u tim riješiti problem, jer još više ljudi koji loše komuniciraju će sigurno jače tipkati pa će sve biti brže gotovo. Zdrav razum da treba učiti na prijašnjim iskustvima očito ne pali ovdje, jer je još prije 40 godina primijećeno, i zakucano u Brooksov zakon, da dodavanje ljudi na projekt koji već kasni ustvari čini da će projekt kasniti još više. Ljudi koji su pročitali Mythical Man Month jednostavno ne govore takve stvari. Pro tip: poboljšaj razmjenu informacija a ne brzinu tipkanja. Molim lijepo

Dobro, i kako dalje?

Probajte razumjeti osnovne agilne vrijednosti i principe.

Probajte Scrum, koji jako dobro stavlja “agilno” u okvire koji se mogu primijeniti na razvoj i održavanje kompleksnih proizvoda (i usluga).

Uključite mozak i pomozite drugima da ga uključe.

Redovito stanite na loptu, udahnite duboko i pitajte se prevodite li taj “common sense” u “common practice”.

Uzmimo za primjer 3 aktivnosti, zbog jednostavnosti računice neka budu potpuno jednake: angažman, trošak, trajanje, prihod nakon dovršetka – sve je isto. Također, trošak odlaganja početka (Cost of Delay) je identičan, što znači da ne ulazi u matematiku.

Svaka aktivnost traje 5 mjeseci i nakon što je dovršena donosi po 20k eura mjesečno.

Prvi slučaj, radimo svaku aktivnost od početka do kraja, bez prekida.

Tako se treba raditi. Dovrši jednu stvar, pusti je u rad i uživaj benefite – prihode od prodaje proizvoda, korištenja usluge, uštede zbog riješenog problema.

Prva aktivnost se već isplaćuje dok radimo na drugoj, prva i druga se isplaćuju dok radimo na trećoj itd. U našem primjeru, 5 mjeseci nakon dovršetka treće aktivnosti imamo ukupno 600k eura na računu.

Drugi slučaj, mijenjamo fokus svakih mjesec dana.

Ovakve situacije su česte u organizacijama gdje se više cijeni ‘nešto raditi’ nego stvarno dovršiti posao. Glavno da se gurka sve pomalo, da svaki direktor(čić) bude sretan. To što organizacija gubi ozbiljne novce nije njihov problem. Takvi valjda žive od zelene boje u izvještajima u excelu

Svaku aktivnost radimo po mjesec dana. Ako zanemarimo trošak promjene konteksta rada (koji nije zanemariv, i tema je za svoj blog post), prva aktivnost će biti gotova tek nakon 13 mjeseci! Druga nakon 14 i sve skupa nakon 15 mjeseci. 5 mjeseci nakon dovršetka sve tri aktivnosti prihodi u našem slučaju će biti 360k eura.

Razlika između ova dva pristupa je značajna.

Trošak multitaskinga iznosi 240k kroz tih 20 mjeseci!

Još je gore ako gledamo samo trenutak dovršetka.

Fascinantno, zar ne?

Izronilo je i nekoliko pitanja.

“Ne možemo se kladiti samo na jednu aktivnost, moramo raditi više stvari istovremeno.”

Istina, ponekad treba gurkati više stvari istovremeno, ali treba i uključiti mozak: razmišljajte u kontekstu dovršavanja stvari koje se mogu početi naplaćivati.

Naprimjer, imate tri aktivnosti, svaka traje po godinu dana, morate ih tjerati u paraleli? Podijelite ih u manje cjeline koje možete isporučiti, recimo svakih mjesec ili dva, i primijenite princip iz gornje ilustracije.

BTW, to je klasični inkrementalni pristup, nešto što u agilnom načinu rada cijenimo i promoviramo.

“Što ako neka aktivnost zaglavi, hoćemo li započeti sljedeću dok se ta prva ne odglavi?”

Klasična zamka, ide ruku pod ruku s onim “glavno da se nešto radi”. Započinjanje aktivnosti ne donosi novce, završavanje donosi. Najbolje bi bilo uložiti napore u odglavljivanje, dovršiti aktivnost i onda nastaviti dalje.

“Što ako nije moguće odglaviti prvu aktivnost?”

Tu svakako pomaže inkrementalni pristup, odnosno do trenutka zaglavljivanja neki dijelovi proizvoda su već u upotrebni i vraćaju uloženo. Mali inkrementi su super!

Znači, ne treba nam Daily Standup? Upravo suprotno! Kako ste samo izvukli takav zaključak?

Pa… Ok. Što sada? Znate za one tri rečenice koje svi izgovaraju: – Što sam radio jučer; – Što ću raditi danas; – Imam li kakvih prepreka?

Naravno. Što s njima? Samo malo. I znate da se svi nešto trude i prijete kako sve mora stati u 15 minuta?

Znam. Hmm… Imam osjećaj da slijedi ali. Nema ali, to je odličan početak. Tri pitanja će vam pomoći da svi u timu dobiju pregled zbivanja, a ograničenje od 15 minuta je tu da ostanete fokusirani.

I dalje imam osjećaj da se tu nešto krije… U pravu ste. Krije se opasnost da se takvi sastanci pretvore u izvještavanje Product Owneru, ili još gore Scrum Masteru. Uz to, tim ionako sjedi i radi zajedno (zar ne?) pa već znaju tko je što radio jučer.

Da, nekako naginje na tu stranu. A ponekad izgleda i kao ispitivanje u policijskoj stanici. Mda Probajte preokrenuti priču i razgovarati o tome što je napravljeno jučer, a ne što je tko radio.

U čemu je razlika? Razlika je ogromna. Tako ćete imati fokus na posao kojeg tim radi, na cilj sprinta ako radite u iteracijama. Bolje nego slušati tko je išao na koji sastanak ili tko je programirao koju funkcionalnost. Vrijedi samo ono što je napravljeno!

Ali dobro je da ljudi pričaju o tome što je tko radio, zar ne? Širenje znanja i sve to… Apsolutno! Svaki put kad je neki komad posla gotov, odvojite nešto vremena nakon daily standupa i popričajte što je bilo zanimljivo, što je tim naučio i kako će se to znanje iskoristiti u budućnosti. 

Zvuči dobro! Može još malo detalja? Naravno Krenite od desne strane ploče (vizualizirate posao, nadam se) i prvo prodiskutirajte sve što je prešlo u kolonu ‘Gotovo’, odnosno na ono što je tim dovršio od posljednjeg ovakvog sastanka i spremno je za isporuku. Zatim se pomaknite jednu kolonu u lijevu stranu; to su poslovi kojima nedostaje još nešto da bi biti gotovi. Fokusirajte se na blokirane stvari, popričajte zašto su u tom stanju, tko treba odraditi nešto da bi se dovršio i taj komad posla. Polako se pomičite prema početku ploče. Idite ulijevo onoliko koliko ima smisla. Naprimjer, vjerojatno ne treba baš svaki dan pričati o poslovima koji nisu ni započeti. Ako nisu započeli, a trebali su – e to je već tema za razgovor.

Znači, postoji mogućnost da jedan član tima više puta tumači što je radio, ako je radio na više poslova? Tako je, da – i  dobra primjedba: vidjet ćete tko je možda preopterećen, ili možda o tom članu tima ovisi previše posla, ili je taj član tima usko grlo pa puno stvari čeka na njega.

A istovremeno ćemo vidjeti i ako netko nije ništa rekao tokom standupa. Da, no oprezno ovdje: to ne znači da ta osoba nije ništa radila već je radila posao koji, izgleda, nije dio tog sprinta. Tu se otvaraju razna pitanja. Krenite od ‘što se događa, kako da i taj posao uključimo u redovni’. Vjerojatno tim trpi udarce sa strane i troši kapacitete na neplanirane stvari.

Eto nešto i za Scrum Mastera. Istina.

A tim cijelo vrijeme ostaje fokusiran na posao kojeg treba napraviti! Upravo tako, i to je vrlina koja se cijeni.

Ima li ta tehnika neki naziv? Ne bih baš ovo nazvao tehnikom, više kao prirodnom sljedećom fazom u unapređenju timskog rada, pa tako i dnevnog sinkronizacijskog sastanka. No, nismo prvi koji o ovome razgovaraju. Zaguglajte pojam “Walk the board” ili pročitajte ovaj članak.

Svaki tim koji sazrijeva vodi ovakav razgovor, prije ili kasnije.

Photo by Margarida CSilva on Unsplash

Snimajući ovaj film nije ozlijeđen niti jedan Post-it.

Sve vam izgleda kao drama, ali ustvari nije. Čak vam treba biti pomalo toplo oko srca jer se ovakve situacije događaju u stvarnom životu i dobro je imati stav kako pristupiti rješenju problema.

Kako vam je izgledao sprint?

Recimo da ste od planirane količine posla napravili jednu trećinu (vizualizirate posao pa se sve lako vidi), a ostatak vremena je otišao na ad-hoc zahtjeve i pomoć drugim timovima i okruženju jer:

• Drugi dio organizacije lansira ogromnu produkciju, a vaš tim može pomoći u nekim detaljima.
• Korisnik koji je do prije 2 tjedna znao što želi je potpuno promijenio priču zato što se kod njih interno nešto dogodilo.
• Sustavi koji su do jučer radili stabilno su se počeli ponašati jako čudno pa ste morali pomagati operativi, restartati servere i još koješta.
• Hakeri su vam napali IT i većinu vremena ste proveli stavljajući zakrpe na postojeće aplikacije i servere.
• Poplava u sistem štali, svi kante u ruke i ajmo.

Ne izgleda lijepo. Što dalje?

Najčešće pitanje koje se ovdje postavlja je treba li održati sprint change (review, retrospektivu i planiranje) ili jednostavno preskočiti sve.

Pročitajte čemu zapravo služi Sprint Review.

Iz moje perspektive agilnog coacha odgovor je vrlo jednostavan i jednoznačan (da, treba), ali prije nego što se pokunjite i primite posla, probajte razmisliti o situaciji u kojoj se nalazite. Standardni coaching pristup analizi problema i okruženja je primjenjiv i ovdje. Zapitajte se: što ćemo (kao tim i cijela organizacija) dobiti ako imamo sprint change, a što ćemo izgubiti ako nemamo.

Dobit ćemo ako imamo sprint change

Benefiti su više nego jasni.

• Svi stakeholderi imaju jasnu sliku što se radilo i napravilo tokom sprinta, bez obzira je li to iz backloga ili ad-hoc. Vidljivost tima i njihovog posla je pola uspjeha. 
• Svi znaju koliko je kapaciteta otišlo na neplanirane aktivnosti, što je vrlo korisna informacija za buduće slične situacije ili druge timove i inicijative.
• Članovi tima će komentari sprint, što su naučili u datoj situaciji, kako im je izgledalo raditi u takvom okruženju, možda skupa s drugim timovima, imaju li neka saznanja kojih recimo okruženje nije svjesno i slično.
• Svi – članovi tima, PO, stakeholderi – imaju ideju što će se događati dalje, što sa zadacima iz backloga, očekuju li se i dalje slične situacije, i drugo.

Ograničite review na 30 minuta, ili koliko zaključite da vam treba: 20, 45… Vrlo je bitno da review bude fokusiran i ograničen! Najavite o čemu će se govoriti i pozovite sve zainteresirane strane, uz naznaku da prisustvo nije obavezno ali može biti korisno.

Ograničite retrospektivu na 45-60 minuta. Trebalo bi biti jako zanimljivo i korisno jer ste upravo doživjeli sudar dva svijeta – vašeg idealnog kojeg je jednostavno planirati i stvarnog koji je nepredvidljiv i zbunjen, a iz toga se može jako puno naučiti.

Planiranje odradite kao i do sada, s tim da možda već unaprijed znate da ćete imati manje kapaciteta za backlog pa sukladno tome ni planiranje neće trajati predugo.

Ako je baš panika, napravite pauze između reviewa, retrospektive i planiranja da se možete vratiti u stvarni svijet (i pomoći drugima ako treba) ali svakako sve ugurajte u jedan dan.

Izgubit ćemo ako nemamo sprint change

Ako ne napravite sve ovo gore, odnosno počnete rastezati i razvlačiti po danima i terminima, onda se može dogoditi da se neke stvari nikad ne odrade u cjelini, već u nekim dijelovima, automatski sljedeći sprint neće imati smisla, propustit ćete priliku osvrnuti se na trenutni način rada, što može biti korisno već od sljedećeg dana i tako dalje. Više problema nego koristi.

Dobro, nakon svega ovog, što mi je činiti?

Iz mojeg iskustva kao SM i coach, bez obzira na uspješnost ili neuspješnost sprinta, uvijek smo imali review u zakazano vrijeme, retrospektivu odmah nakon toga a zatim planiranje. Naša je sugestija da i vi uradite tako.

Photo by Andrej Lišakov on Unsplash.

Svi detalji su dostupni na službenim stranicama meetup grupe Agile Hrvatska.

[Foto: Darko Špoljarić]

Odmah da razjasnimo na početku, ne postoji pravilnik ponašanja u ovakvim slučajevima, niti će vam na vrata doći Scrum policija ako nešto napravite mimo regula. Ipak, mogu se dati neki iskustveni savjeti kako pristupiti problemu.

User Story nije niti započet

Najlakši slučaj, vratite US u backlog i ponašajte se kao da se ništa nije dogodilo (osim što trebate o ovome popričati na retrospektivi). Ako je bitan, uzet ćete ga u sljedeći sprint tokom planiranja i to je to. Ako nije bitan (možda je to razlog zašto nije niti započet?) onda se ne bi trebao pojaviti u sljedećem sprintu. Ne može jednostavnije.

User Story je započet, ali nije dovršen

Najčešći slučaj. Bitno je shvatiti zašto se ovo dogodilo:

• US je prevelik pa niste stigli?
• US je bio nejasan pa ste potrošili vrijeme na razjašnjavanje?
• US je ovisio o nekom vanjskom događaju (ili pojedincu, timu, entitetu)?

U svakom slučaju, problem nije u nedovršenom user storyju već u nedovoljno dobroj analizi tokom planiranja sprinta. Probajte napraviti bolju analizu tokom sljedećeg planiranja kad ćete već unaprijed odgovoriti na gornja pitanja.

Što se tiče samog US-a, vratite ga u backlog, vjerojatno cijelog pa onda tokom sljedećeg planiranja analizirajte što je još ostalo od posla i dopunite ovaj ili napišite novi US, a ovaj bacite u smeće.

User Story je dovršen, ali je otkriven bug

Kad je otkriven bug, tokom testiranja u okviru sprinta? Pa popravite ga, i dopunite svoj Definition of Done tako da uključuje i testiranje. US nije gotov dok testiranje ne potvrdi da ne može naći bug. Bez obzira je li bug trivijalan ili ozbiljan, potrudite se riješiti ga tokom sprinta jer tako ne ostavljate repove za sobom već dovršavate stvari a to se cijeni.

Otkrili ste bug tokom reviewa? Odlično! Bolje nego u produkciji. Zapišite ga i stavite u backlog. Ako je drama (npr. našla ga je direktorica financija pred svima ili je bloker) vjerojatno će biti na vrhu liste za popravak, inače ide u redovnu proceduru.

Bug je otkriven nakon što je sprint dovršen? Ide u backlog i u redovnu proceduru prema nekom SLA (service level agreement) kojeg već imate.

Važnije je što radimo nakon “incidenta”

Svi repovi nakon sprinta su ustvari poziv na razgovor i analizu problema, vjerojatno već tokom sljedeće retrospektive. Pitajte se zašto se dogodilo pa da sprint nije dovršen i ideje za rješenje ugradite već u sljedeće planiranje. Kao tim želite biti predvidljivi (ma kako to dosadno zvučalo) tako da i vi sami, ali i okruženje oko vas može računati na termine isporuka.

Dobro i precizno planiranje je i pokazatelj zrelosti tima.

Što nije pametno raditi

Nepametna ideja #1: US (ili razlika) automatski ide u sljedeći sprint

Iako će US vjerojatno na kraju i dospijeti u sljedeći sprint, podrazumijevati da će tako biti je greška.

S druge strane, ako je ostalo “još samo malo”, možda vrijedi dovršiti US i skinuti ga s vrata jednom i zauvijek. Neka PO odluči

Nepametna ideja #2: Produživanje sprinta

Ovo je ustvari glupa ideja. Produživanjem sprinta poništavate metrike o kapacitetu tima, brzini rada ili broju US-a koje tim može isporučiti tokom sprinta, a time kvarite i svoju predvidljivost isporuka.

Broj riješenih bugova? Ova je odlična Kako je u jednom Dilbertu napisano, do kraja dana ću si isprogramirati novu kamp kućicu.

Najbolje bi bilo mjeriti koliko neka razvijena funkcionalnost donosi novaca, ali to je realno jako teško.

Koje su onda stvarno dobre mjere u tvornici softvera?

Dobro je tražiti one koje omogućavaju predvidljivost: isporuke, potrošnje kapaciteta, kvalitete krajnjeg proizvoda. Dobro je, dakle, mjeriti koliko vremena protekne od inicijalne ideje za neki proizvod ili funkcionalnost pa do trenutka kad ih krajnji korisnik može koristiti, i onda raditi na skraćivanju.

Dobro je i mjeriti koliko funkcionalnosti tim dovršava po iteraciji pa imati sliku kad će nešto biti gotovo; ovo je vrlo korisno kod planiranja marketinških kampanja, prodaje i, u konačnici, prihoda. Dobro je i brojati koliko bugova imamo po isporuci pa raditi na smanjenju tog broja.

Kako god bilo, mjerenja treba usmjeravati ka poticanju produktivnosti i stvaranju vrijednosti, a ove površne ignorirati ili prepustiti konkurenciji.

Bus factor ili kako se riješiti voditelja tima

Mnoge agilne prakse poput dijeljenja odgovornosti u timu, zajedničkog rada cijelog tima na poslovnim zahtjevima, suradnje developera i poslovnjaka na testiranju, na papiru i ekranu zvuče super sve dok se ne spustimo u rovove i probamo sve to implementirati u stvarnom životu i u stvarnom okruženju.

Darko Špoljarić Špula  nas je na našem petom meetupu poveo na putovanje kroz šumu problema, nejasnoća i zbunjujućih ponašanja koristeći živi primjer projekta na kojem sada radi. Meetup je bio glavolomka (jel’ se tako kaže?)! Darko nam je koristeći Causal Loop Diagram koji nam dolazi iz systems thinking domene nacrtao uzročno posljedične veze svih svojih problema (onih poslovnih dakako), a mi ostali smo u grupama razgovarali, tražili rješenja i prezentirali prijedloge.

Od mnogih prijedloga, par stvari koje smo zapamtili:

• Ne zaboravimo na bus factor – tim koji se raspadne ako X pregazi autobus, nije dobro posložen tim – neovisno o tome da li je X voditelj tima, developmenta, jedini analitičar ili bilo koji čovjek/rola. Puno praksi nam tu može pomoći, jedna od njih je rad u paru, od početka razrade zahtjeva do popravka zadnjeg buga. Izbjegnimo “to radi samo x” situacije.
• U nekim (svim!) timovima dobro dođe Scrum tečaj da bi razumjeli zašto nešto ne radimo.
• “Ček ček, što je ono točno rečeno na sastanku za ovaj zahtjev?” situacija – ako klijenta i Product ownera vidimo rijetko, trebamo li razmisliti kako dokumentiramo te razgovore?
• Komunikacija mora biti konstantna, eksplicitna i zadatak svih članovi tima. Ako netko ima veći autoritet u timu, makar bio zasnovan na znanju, ne smijemo dopustiti da se ostali zbog toga povuku. Vraćamo se na bus factor, ali i na smisao kolaboracije i timskog rada.
• Respect the WIP! Ili se izgubi u multitaskingu.

A tu su i slike koje je Kele uslikao krumpirom kroz bocu osušenog balzamika, tako da je i kvaliteta istih odgovarajuća.

Scrum je metoda kojom tim implementira neki proizvod primjenjujući agilne principe rada. Sav posao kojeg tim radi planira se na razini jednog sprinta i vidljiv je na timskoj ploči. Ne postoji dodatni posao sa strane, niti postoji posao za nekog određenog člana tima.

Za više detalja pogledajte Može li Scrum tim raditi na više projekata i Što s redovnim poslom koji je van “agilnog” projekta

Stvarni svijet

Posebno je česta pojava u novoformiranim timovima da se zadaci upućuju pojedinim ljudima (imenom i prezimenom). Razloga može biti više:

• prije formiranja tima ljudi su radili neke poslove koji nisu gotovi pa ih treba dovršiti
• netko u timu ima specifično znanje kojeg nitko drugi nema
• nečiji šef želi da baš ta osoba odradi zadatak

Sigurno će se pronaći još koji razlog, no zajedničko svima je očito ignoriranje elementarne postavke Scruma:

Posao dolazi u timski backlog, tim povlači (preuzima) zadatke, ljudi sami u timu određuju tko će konkretno odraditi posao.

Dodjeljivanje zadataka nekom određenom članu tima je znak da okruženje još uvijek nije prihvatilo agilni način rada, i to je svakako nešto na čemu treba poraditi.

Kako u međuvremenu odgovoriti na gore navedena ponašanja?

Konkretni zadatak je iz “prošlog života” određenog člana tima

Osim ako nemamo tim sastavljen od potpuno novih ljudi, sigurno će neki od članova imati zaostatke iz prijašnjih projekata. Ponekad se takav posao naziva i “Business as Usual” (BAU), što je vjerojatno znak da organizacija nije do kraja prihvatila agilni način rada. U svakom slučaju, cilj je osvijestiti da takav dodatni posao postoji i da ga treba napraviti, a da istovremeno odvlači koncentraciju i krade vrijeme za izvršavanje zadataka zbog kojih je tim i formiran.

Najzdraviji pristup je, kao i u cijelom nizu sličnih situacija, vizualizirati taj dodatni posao, naprimjer u posebnoj koloni na timskoj ploči.

Na retrospektivi se može napraviti analiza takvih zadataka gdje će se provjeriti koliko ih je, je li baš bilo nužno da svaki dođe u tim, koliko su utjecali na redovni posao i prema tome reagirati.

Netko u timu ima specifično i jedinstveno znanje

Ništa lakše, uparivanje! Na prvi pogled zvuči nelogično i neefikasno ako dvije osobe rješavaju isti zadatak, ali praksa pokazuje se u našem poslu, koji se temelji na kreativnom radu, uparivanje itekako isplati: podiže se kvaliteta isporuke, posao se napravi brže i manje je repova nakon isporuke. Uparivanjem ćemo također proširiti i znanja koja pojedini ljudi imaju u timu i sljedeći put kad dođe tako specifičan zadatak bit će ga lakše odraditi.

Čak i IKEA preporučuje uparivanje.

Ukratko, uparujte ljude!

Nečiji šef želi da baš ta osoba odradi zadatak

Ovo je vjerojatno najozbiljniji problem od svih navedenih i ovakvo (šefovo) ponašanje je znak ili nepoznavanja načina rada po Scrumu ili namjerno kršenje dogovora o formiranju tima, njegovoj stabilnosti i neovisnosti.

U prvom slučaju pomaže direktna edukacija (tečajevi, coaching) a vjerojatno je još učinkovitija popularizacija Scruma preko odgovarajućeg ponašanja samih članova tima.

Naprimjer, tim može predložiti da će uzeti zadatak, riješiti ga na timski način i šefu isporučiti rješenje uz objašnjenje kako se radilo.

Kvaliteta i brzina isporuke će vjerojatno biti na višem nivou, što je svakako benefit timskog rada.

Drugi slučaj je puno ozbiljniji. Stav “Moj čovjek je moj čovjek i radit će ono što mu ja kažem” se ne mijenja preko noći, pa i pripadajući odgovori moraju biti pomnije osmišljeni. Često je dobra ideja napraviti eksperiment: naprimjer dogovoriti se da svaki drugi ovakav zadatak ide u tim umjesto pojedinom članu tima i poslije dva ili tri sprinta usporediti rezultate — kvalitetu i brzinu isporuke, utjecaj na redovni timski posao i slično.

Ljudi su razumni i fokusirani na rezultate.

Ako možete pokazati da tim radi bolje od nakupine pojedinaca, onda će i takav način rada vrlo brzo biti prihvaćen.

Ako imate nerazumnog šefa s druge strane onda… što reći, nemate sreće.

Kako god, ovo je tipična situacija u kojoj Scrum Master priprema teren i rješava problem.

Nevidljivi posao

Posebno je opasan posao koji se ne vidi u timskom backlogu. Ovakav posao najčešće dolazi određenom članu tima od njegovog šefa (nadređenog, linijskog voditelja ili koju već hijerarhiju pronalazimo u organizaciji) i jedini savjet kojeg ovdje mogu dati je: vizualizirajte baš sve.

Vizualizirajte baš sve!

Baš svaki posao treba biti vidljiv na timskoj ploči tako da se na kraju sprinta može pokazati koliko se radilo na kojim stvarima i sukladno tome reagirati.