• Jer ćemo tako biti brži, ili
• Jer ćemo tako biti efikasniji, ili
• Jer ćemo tako s manjim brojem ljudi napraviti više.

Pa krenimo redom.

Kad radiš agilno onda si brži

Znači, kad radiš agilno onda… brže tipkaš? brže pričaš? brže… misliš? Sumnjam.

Agilno raditi znači, između ostalog, i fokusirati se na najbitniju stvar, riješiti je, i pitati se treba li dalje. Ako treba, onda ćete uzeti sljedeću najbitniju, riješiti i nju, pa se pitati treba li dalje i tako koliko treba.

U jednom trenutku ćete shvatiti da… ne treba dalje.

A to je gotovo sigurno prije nego što ste riješili baš sve. Onda ćete pogledati ostatak backloga i reći si “E za ovo bi nam trebalo još X mjeseci, ali nećemo jer su to nevažne stvari.” Dakle, gotovi smo X mjeseci ranije, zato što smo radili pametnije, a ne brže.

Brzina je posljedica pametnijeg načina rada.

Kad radiš agilno onda si efikasniji

Ovdje treba priznati da se kod nas često izjednačuje efikasnost (raditi nešto na pravi način) i efektivnost (raditi pravu stvar). Moj komentar je obično ovakav, s tim da umjesto gluposti koristim jednu prostu riječ, no kako je ovo blog za pristojne ljude…

Ako radite efikasno, a radite gluposti, onda ćete brže napraviti tu glupost i imat ćete vremena za još jednu glupost.

Savjet je gotovo pa nepotreban: Nemojte raditi gluposti. Radite pametnije stvari. Složite backlog tako da su na vrhu oni poslovi koji u tom trenutku donose najviše vrijednosti. Naprimjer, smanjit će rizik od nepoznatog, pokrit će najveći broj korisnika, izaći ćete na tržište prije konkurencije, postavit ćete arhitekturu na noge i tako otvoriti vrata za niz drugih stvari, itd, itd, itd.

Priznajem, odabrati najpametniju stvar nije uvijek jednostavno, i prepoznavanje kriterija za taj odabir je vještina koja se uči.

Kad radiš agilno onda s manjim brojem ljudi napraviš više

Da, sigurno, jer ljudi dobiju super-moći kad im na čelo napišeš A-G-I-L-E. Besplatan savjet: ne dobiju. Molim lijepo.

Ljudi ne dobiju super-moći kad im na čelo napišeš A-G-I-L-E.

Raditi agilno znači, uz druge stvari, i raditi u timu gdje ljudi komuniciraju često i direktno.

To znači da najvjerojatnije sjede skupa, imaju dnevne sinkronizacije i redovne kontrolne točke gdje pričaju o napretku u rješavanju poslovnih zadataka.

Također, imaju i redovne termine za razgovor o svom načinu rada (dakle, ne o proizvodu; to je pokriveno ovim gore spomenutim), gdje uz svoj “pravi” posao dodaju i aktivnosti na poboljšavanju timskog rada, komunikacije itd.

Pa umjesto da se vrijeme troši na slanje mejlova, čekanje odgovora, umiranje po sastancima i slično, članovi tima se direktno dogovore što treba i prime se posla.

Znate li da je komunikacija licem u lice 34 puta uspješnija od slanja emaila?

Zanimljivo, zar ne?

A ustvari pravi odgovori trebaju biti…

• Jer tako smanjujemo rizik, ili
• Jer nam je ROI bolji, ili
• Jer tako brže i lakše razumijemo potrebe korisnika, ili
• Jer je takav pristup poslu humaniji, zanimljiviji i potiče angažiranost u ljudi, ili
• Bilo koji drugi odgovor koji u fokus stavlja “pametnije” a ne “jače”.

Ljudi, ne mašine.

No o tome ću pisati nekom drugom prilikom. Ili mi dođite na tečaj

“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”.

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ć]

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.

Prijavite se u grupu i dođite na meetup!

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.

Kako sam već pisao u nekoliko navrata, tranzicija na agilni način rada se ne događa preko noći. Tokom tog procesa se organizacije sjete primjenjivati različite hibridne modele, od kojih su većina rezultat nedostatka znanja i nedovoljnog promišljanja, a viđao sam neke koji su čak i besmisleni.

Tako se ponekad pokušava primijeniti model parcijalnog rada na agilni način, a ostatak vremena na “tradicionalni” ili “uobičajeni”. Ovakve kombinacije nisu dobre jer se prema agilnom načinu rada postavljaju kao prema metodologiji, što takav način rada svakako nije.

Potrebno je stoga prebroditi taj prijelazni period tako da se čim prije vide benefiti agilnog pristupa, a to je moguće ostvariti na nekoliko načina.

Posao je posao

Agilne metode rada, pa tako ni Scrum, ne razlikuju ‘agilni’ i ‘redovni’ posao (business as usual), niti propisuju kako se ponašati u tom slučaju. Realno, često članovi tima imaju posla koji nije vezan uz projekt, dakle ne pripada produktu kojeg tim razvija, već je njihov redovni posao ‘iz prošlog života’. Aktivnosti koje tim poduzima u takvim situacijama se mogu svesti pod smanjivanja štete i širenja principa rada van tima i treba ih početi primjenjivati od prvog dana.

Sve je u timskom backlogu

Donesite posao u tim i stavite ga u timski backlog. Ponašajte se prema “vanjskom” poslu kao da je sastavni dio timskog.

Ovo je najbolja opcija jer sad posao postaje odgovornost tima, koji će brže i bolje riješiti zadatak nego netko pojedinačno. Dodatno će se i znanja o tom specifičnom tipu posla proširiti i više će ljudi znati riješiti zadatak. Također će se vidjeti i koliko je tog redovnog posla, koliko kapaciteta tima uzima, kakve su vrste poslova koje dolaze, koliko su ti poslovi “važniji” ili “prioritetniji” od timskog rada na odabranom proizvodu i tako dalje.

Skraćeni timski radni tjedan

Tim radi fokusirano na projektu određenu količinu vremena, recimo 3 dana tjedno, a ostatak tjedna tim ne postoji; članovi tima se vraćaju na svoja stara radna mjesta.Dobra strana ovog pristupa je fokusiranost članova tima u odabranom periodu, ništa ih ne ometa i mogu se u potpunosti posvetiti. S druge strane, kapacitet tima je osjetno smanjen što značajno utječe na planiranje, interakciju s vanjskim svijetom kad naprimjer i korisnici moraju biti dostupni u isto vrijeme i tako dalje.Ako se već odabere ova opcija, onda je bitno da timski dani budu zaredom, naprimjer ponedjeljak, utorak i srijeda, kako bi se zadržao kontinuitet rada i izbjegao multitasking.

Vrlo loša ideja #1: Dijeljenje dana na agilni i uobičajeni posao

Do ručka agilno, poslije ručka na stari način, smiješno i neučinkovito cijelo vrijeme.

Cijepanje dana na dijelove nije funkcioniralo ni prije agilizacije pa neće ni sad, pogotovo ako se očekuje da se članovi tima i fizički vrate na stara radna mjesta. Ako će se ipak svi zadržati na okupu onda se tim vrlo lako može prebaciti na prvu opciju navedenu ranije, odnosno treba i “vanjski” posao staviti u timski backlog i nastaviti raditi kao i to tada.

Vrlo loša ideja #2: Ljudi sami određuju kad su u timu

Loša je opcija da članovi tima sami određuju dane kad su na projektu a kad rade redovni posao, bez usklađivanja s drugima. Ovako praktički nemamo tim već neke ljude koji neovisno rade poslove koje bi trebali raditi kao tim. Postaje nemoguće išta smisleno planirati, i istovremeno se gube svi benefiti izgradnje tima (dijeljenje znanja, povećanje produktivnosti kroz vrijeme itd.)

Vrlo loša ideja #3: Prekratki radni tjedan

I tri dana tjedno za timski rad je prekratko, a da ne spominjem dvodnevne ili čak jednodnevne grozote koje sam tu i tamo vidio. Ako se razmišlja o ovakvim kombinacijama onda se treba zapitati je li organizacija uopće spremna za prelazak na agilni način rada. U takvoj konfiguraciji dodatna je poteškoća i trajanje ceremonija (planiranje, review, restrospektiva) koje sad odjednom oduzimaju previše vremena ljudima za rad.

Tu se organizacije pokušavaju dovijati problemu pa obično razvuku sprint na 3 ili 4 tjedna, no četverotjedni sprint s po jednim fokusiranim danom tjedno je upravo apsurdan koliko i zvuči.

Gdje je stvarni problem?

Stvarni problem je u stavu da je agilni način rada, pa time i Scrum, ustvari skup nekih obrazaca ponašanja. “Stavimo ljude skupa u sobu i agilni smo” ili “Stojimo ujutro 15 minuta i sve će biti super”. Pravi je pristup posvetiti jedan ili više timova ovakvom načinu rada, kroz ciljane i organizirane eksperimente, i nakon nekoliko sprinteva pogledati koji su benefiti, što se očekuje na organizacijskom nivou i mogu li se ta očekivanja ispuniti.

Implementacija agilnih principa temelji se na multifunkcionalnim timovima koji su stabilni, samostalni i imaju sva potrebna znanja i vještine kako bi obavili svoj posao. U takvim se timovima znanje kvalitetnije dijeli, posao se bolje balansira, ovisnost o vanjskim resursima je minimalna, a različiti profili ljudi i različita mišljenja potiču nove ideje i inovacije.

Puno teorija opisuje proces razvoja tima, a vjerojatno najpoznati je Tuckmanov model. Imajući na umu sve faze Tuckmanovog modela kroz koje tim mora proći te da je potrebno između 6 i 12 mjeseci da nakupina ljudi uistinu postane tim, čini se razumnim da im u tome nekako pomognemo. Odličan poguranac razvoju svakog tima daje kickoff radionica.

Na kickoff radionici sudjeluje cijeli tim, a cilj radionice je propuhivanje komunikacijskih kanala, bolje međusobno upoznavanje članova tima i dogovaranje oko načina kako će kao tim funkcionirati. Kao i za sve ostale radionice svojstvene agilnom načinu rada, i za ovu vrijedi da ne postoji jedan jedini ispravan način kako se radionica provodi. Ranije navedeni cilj radionice ujedno predstavlja i tzv. enabling constraints, odnosno ograničenja unutar kojih tim ima slobodu realizacije sve dok je cilj ispunjen.

Ipak, postoje dobre prakse provođenja kickoff radionice, odnosno ima aktivnosti koje su se pokazale korisnijima od drugih.

U domeni “dogovaranja oko načina kako će tim funkcionirati” korisnima su se pokazale aktivnosti zajedničkog definiranja:

• pravila ponašanja/funkciniranja tima (Working Agreement)
• kriterija kad je neki komad posla spreman za realizaciju (Definition of Ready)
• kriterija završenosti posla (Definition Of Done)

U domeni “boljeg međusobnog upoznavanja članova tima” posebno su korisne aktivnosti:

• definiranja imena i slogana tima – potiče zajedništvo i stvaranje timskog identiteta
• Market of Skills – aktivnost u kojoj članovi tima prezentiraju svoja znanja, vještine i afinitete prema područjima u kojima bi se htjeli usavršavati i sl.
• Star Skill Map – aktivnost u kojoj članovi tima identificiraju znanja i vještine koje će im trebati na konkretnom projektu i samoocjenjuju se u tim kategorijama. Svrha ove vježbe je provjera ima li tim uistinu sve potrebne vještine te kreiranje baselinea prema kojem možemo pratiti usavršavanje članova tima.

Dobro je u okviru kickoff radionice odraditi i upoznavanje tima s opsegom posla kojeg će raditi te inicijalno razrađivanje backloga (backlog refinement) i planiranje prvog sprinta. Na taj se način timu daje kontekst i spremni su za prvi sprint.

Ako vam se čini da je ovo puno posla, u pravu ste. Kickoff radionice su tipično dvodnevna događanja, ali vrijede svake minute. Razina međusobnog razumijevanja članova tima i razumijevanja budućeg posla na kraju ovakve radionice ne može mjeriti ni sa kakvim drugim ad-hoc prezentacijama. Imajući u vidu da stvarate dugoročan i stabilan tim, investicija od dva dana se zaista ne čini velikom.