UVOD
V prejšnjem delu članka smo spoznali fokus in intenzivnost coachinga glede na fazo iteracije in vlogo, ki jo pri tem igra Scrum Master. Pravtako sem spregovoril o navidezni razliki med Scrum Mastrom in Agile coach-em, pa še malo sem zaropotal glede tendence omejevanja pristojnosti “samo organizirajočih” teamov.
V tem članku bom opisal 10 učinkovitih pristopov, ki v Scaled Agile okolju teamom pomagajo pri medsebojni koordinaciji in širjenju znanja. Seveda se je po moji stari navadi planiran kratek članek precej raztegnil, mislim pa, da je iz njega nastalo koristno referenčno gradivo za organizacije, ki se soočajo z izzivi komunikacije v več teamskih okoljih.
Začnimo z najočitnejšim…
Začnimo z najočitnejšim…training
Spontana komunikacija
Scaled Agile frameworki, standardno Scrum ogrodje običajno razširjajo z dodatnimi ceremonijami, ki so namenjene med teamski koordinaciji.
- Nexus tako uvaja Nexus Daily Scrum kjer se med seboj koordinirajo predstavniki razvojnih teamov in Nexus integracijskega teama.
- Scrum@Scale dodaja dogodke Scrum of Scrums za Scrum Master in Product Owner cikle.
- SAFe dodaja vse polno koordinacij znotraj svoje navidezno Agilne hierarhije.
- LeSS dodaja dodatni nivo Sprint planiranja.
Te “uradne” ceremonije so koristne, a ne zadostujejo za uspešno koordinacijo več teamov, ki razvijajo isti produkt. Dopolnjuje jih spontana interakcija med teami. Ta mora biti konstantna tako na individualnem kot na med teamskem nivoju. Organizacija mora za spontano komunikacijo zagotoviti pogoje in dobro voljo. Mogoče se bo komu zazdelo, da tak ad-hoc komunikacijski šum lahko ovira koncentracijo razvojnikov v teamih. In delno bi imel prav. A vprašajmo se, kakšne so posledice podvajanja dela, neskladnih razvojnih standardov in “soliranja” posameznih teamov v smeri nestandardnih arhitektur, materialov ali APIjev.
Prekomerno koordinacijo med razvojnimi teami produktni manager in/ali Product Owner regulirata s pravilnim planiranjem, ki:
- Minimizira med teamske odvisnosti pri razvoju uporabniških zgodb
- Zagotovi pogoje za formiranje pravih multifunkcionalnih teamov, ki lahko določen feature od začetka do konca razvijejo z lastnim znanjem.
Spontana komunikacija ne nastane sama od sebe, ampak za to potrebuje pozitivne organizacijske pogoje.
Open Space (Technology) - OST
Metoda, ki jo je med letoma 1983 in 1985 razvil organizacijski konzultant Harrison Owen. Vprašal se je, zakaj so premori za kavo običajno produktivnejši kot sami sestanki. S časom je razvil metodo za organizacijo srečanj, kjer se večja skupina ljudi samoorganizira okoli pomembne, skupne teme. Namesto vnaprej določenega dnevnega reda, udeleženci sami določijo teme pogovorov, se razdelijo v manjše skupine in o njih razpravljajo.
Glavna načela OST:
Kdor pride, je pravi.
Karkoli se zgodi, se je moralo zgoditi.
Ko se začne, je pravi čas.
- Ko je konec, je konec.
Dodano je še ti. pravilo dveh nog: če udeleženec vidi, da se drugje lahko nauči ali prispeva več, naj enostavno vstane in gre.
OST je posebej uporabna za naslavljanje kompleksnih izzivov, kjer ni jasnih rešitev in je treba izkoristiti kolektivno znanje skupine.
Opomba: Izraz “Technology” v nazivu te tehnike je malce zavajajoč. Izraz naj bi pomenil “strukturirani pristop” in nima zveze s tehnologijo ali imenom kakšnega podjetja. Je samo nerodno poimenovana tehnika. Tako ali tako pa vsi uporabljamo le izraz Open Space.
Kako izgleda OST srečanje
Kontekst
Podjetje želi v več oddelkih implementirati Agile, obstaja pa veliko odprtih vprašanj kot na primer:
Kako bojo poslovne enote sodelovale z razvojem?
Kako prilagoditi poročanje in planiranje?
Kako se izogniti podvajanju dela?
Srečanje
Moderator odpre srečanje s krovno temo, recimo:
“Kako bomo kot organizacija uspešno prešli na Agilni način dela?”
Udeleženci (npr. 50 ljudi iz različnih oddelkov) sami predlagajo podteme, ki se jim zdijo pomembne. Par primerov:
Kaj Agile pomeni v financah?
Kako bomo napredek poročali vodstvu?
Kako se bo napredek vrednotil?
- Kako bojo razvojniki sodelovali s poprodajno podporo?
- Kako bomo merili izboljšave v logističnih procesih?
- Na whiteboardu tako nastane agenda, ki so jo oblikovali zaposleni sami.
- Vsaka tema dobi svoj prostor in čas. Udeleženci se razdelijo v skupine po interesu.
- Razprava se nadaljuje v skupinah, ki svoje ideje in predloge beležijo.
- Velja pravilo dveh nog – vsak se lahko premakne v drugo skupino, če misli, da drugje lahko prispeva ali zve več.
Rezultat
Na koncu dogodka, prispevki skupin postanejo “zbornik” idej, vprašanj in rešitev.
Vodstvo in teami tako dobijo nefiltriran vpogled v to, kar je zaposlenim resnično pomembno.
Dogodek krepi teamski duh in angažiranost v procesu, saj sodelujoči vidijo, da so njihove želje, interesi in strahovi upoštevani.
Rezultat OST srečanja niso nujno rešitve na licu mesta, ampak bolj zavedanje kaj je zaposlenim pomembno, kaj so njihovi strahovi in zadržki. V primeru, da je bil OST sklican z namenom iskanja rešitev kompleksnih problemov, pa je rezultat širši vpogled v problematiko in spisek možnih rešitev, ki morajo nato še skozi product discovery verifikacijo.
V praksi se OST uporablja za strateške razprave, team building, iskanje inovacij in reševanje kompleksnih problemov, kjer ni enostavnega odgovora od zgoraj in je potreben konsenz ter mobilizacija intelektualnega potenciala skupine.
World Cafe
World Cafe je podobno kot Open Space namenjen izmenjavi in bogatenju znanja v večjih skupinah. Osnovna ideja je, da udeleženci sedijo v manjših skupinah (kot v kavarni), kjer v sproščenem vzdušju razpravljajo o določeni temi. Ta tema je lahko iskanje rešitve za določen problem ali generiranje novih idej. Po določenem času se udeleženci premaknejo k drugim mizam in nadaljujejo razpravo v novo nastalih skupinah. Tako s seboj odnesejo ključne misli iz prejšnje skupine, ki se nato nadgrajujejo v novi skupini.
Po vsaj treh rundah takšne “migracije”, se udeleženci lahko vrnejo k “svoji” mizi/skupini in naredijo sintezo pridobljenega znanja in idej.
Skupine nato svoje vpoglede predstavijo na skupni debati. Poleg novih idej, se na ta način lažje identificira koristne vzorce, ki se jih nato vključi v različne vidike poslovanja.
Prakticiramo dve obliki World Cafeja:
Varianta 1 (najpogostejša): vse mize/skupine razpravljajo o istem vprašanju. Ko se ljudje selijo med mizami, ideje krožijo in se bogatijo.
Varianta 2: različne mize debatirajo o različnih a povezanih vprašanjih. Rotacije omogočajo, da se udeleženci dotaknejo več tem, ki so del istega širšega problema. Ta varianta je precej podobna Open Space.
Kako izgleda World Cafe srečanje
Skupno vprašanje za vse skupine (varianta 1): “Kaj bi lahko naredili, da bi se sodelovanje med oddelki v našem podjetju izboljšalo?”
- 1. krog (20 min): skupine začnejo razpravo in zapišejo svoje ideje.
- 2. krog (20 min): ljudje se (razpršeno!) presedejo k drugim mizam. V novi skupini vsak predstavi ideje iz prejšnjega kroga, ki jih nato nova skupina nadgradi ali na njihovi osnovi kreira popolnoma nove ideje.
- 3. krog (20 min): še ena menjava, nove skupine razširijo ali izzovejo že zapisane predloge.
- 4. krog (20 min): po potrebi…
- Zaključek (30 min): skupna debata. Skupine predstavijo svoje ideje, dognanja in vpoglede. Sledi skupno iskanje vzorcev in sprejemanje odločitev.
Dodatni bonus te tehnike je relativni konsenz glede končnih odločitev, ker te temeljijo na skupnem razumevanju vseh skupin in vseh sodelujočih posameznikov je nivo nasprotovanja nižji.
Bistvo World Cafe pristopa je inkrementalno bogatenje idej.
Lean Coffee
Je namenjen usmerjeni razpravi in hitremu pregledu trenutnih problemov brez v naprej določenega dnevnega reda. Zaradi svoje strukture se običajno izvaja za manjše skupine kot World Cafe ali Open Space.
Okvirni potek Lean Coffee:
Sodeluje kdor želi. Sodelujoči se zberejo pred Kanban tablo kjer na licu mesta sestavijo agendo. Udeleženci predlagajo teme, potem pa glasujejo, katere bodo obravnavali.
Teme se zapišejo v Kanban tabelo s stolpci:
Za razpravo
Razpravljamo
Smo razpravljali
Izglasovane teme se označijo in posamično premaknejo v stolpec “Razpravljamo“. Diskusijo se časovno omeji (timebox cca. 8 min.). Po poteku timeboxa udeleženci glasujejo, ali nadaljujejo z isto temo še en timebox, ali nadaljujejo z naslednjo temo.
Značilnost Lean Coffee je fokus na samoorganizaciji in prioritetah skupine. Pogosto se zgodi spontano.
Scout
Preprosta tehnika za sodelovanje in informiranje med teami je, da team pošlje izvidnika (ne Scrum Mastra!!!) na izvidnico v drug team, da tam izve kaj koristnega in potem poroča nazaj. To je enostaven način komunikacije, ki je koristen kadar je treba kaj minimalnega sporočiti ali ugotoviti, s kom v drugem teamu se je smiselno pogovoriti o določeni temi.
Najprimernejši čas in kraj, da gre izvidnik “na teren”, je Daily Scrum drugih teamov, kjer nastopa kot tih opazovalec.
Katerih teamov? Najpogosteje tistih, s katerimi je imel matični team skupen Sprint Planning ali backlog refinement.
Dodatni bonus izvidnika je, da ta vidi kako potekajo Daily Scrumi (in dinamika) ostalih teamov. Če se v teamu začne pojavljati odpor do te ceremonije, lahko Scrum Master predlaga izvidnico na Daily Scrume ostalih teamov. Na ta način člani utrdijo zavedanje o pomembnosti te ceremonije in/ali pridobijo nove ideje za njeno izvedbo.
Izvidnik je hitro in zabavno low-level orodje za izmenjavo manjšega volumna informacij med teami.
Traveler
Kadar imamo v organizaciji strokovnjake s specifičnimi znanji, ki jih občasno potrebujejo vsi razvojni teami, lahko ti postanejo ti. popotniki. Stanje, ko določeno znanje obstaja le v izoliranem “silosu” seveda ni zaželeno, je pa popotnik lahko prehodna rešitev, ki omili takšno situacijo.
Popotnik dela kot običajni član teama za en Sprint. Z rednimi člani teama si tudi deli odgovornost za rezultat dela. Pomembno pa je, da ima popotnik tudi sekundarni cilj – zmanjšati odvisnost od sebe, navadno z učenjem drugih. Opozoriti velja, da so teami, ki v tem Sprintu nimajo popotnika, prepuščeni sebi in morajo sami ugotoviti, kako doseči svoje cilje brez podpore omenjenega strokovnjaka. Tudi to je del samo organizacije teamov.
Popotnik se torej med Sprintom izogiba pomoči drugim teamom. To je pomembno, ker spodbuja dinamiko trenutnega teama, da se posveti učenju od popotnika, ki je na obisku le ta Sprint. S tem se odpravlja odvisnost od redkih strokovnih znanj, ki jih premorejo le določeni posamezniki.
Posledice nedostopnosti popotnika za druge teame med enim sprintom niso tako hude kot se morda zdi na prvi pogled. Product manager/Product Owner namreč v večteamskem okolju tako ali tako planira Product Backlog z mislijo zmanjševanja med teamskih odvisnosti.
Popotnik (traveler) je prehodni ukrep s katerim organizacija v večteamskem okolju olajšuje negativne posledice “silosov” znanja.
Traveler community
Zaradi širokih izkušenj, ki so jih pridobili z delom v različnih teamih, popotniki lahko formirajo lastno skupino. Na teh srečanjih si izmenjujejo informacije, znanje, ideje in čenče. V končni fazi se lahko celo odločijo za organizacijo Open Space kamor so vabljeni vsi zainteresirani.
Zakaj nebi popotniki delili znanja in izkušenj tudi med seboj?
Communities of interest / practice
V Agilu so Communities of Interest (CoI) prostovoljne skupnosti ljudi, ki jih druži skupen interes ali tema, ne pa nujno skupno delo na istem produktu.
To so neuradne in samoiniciativne skupine, kjer člani iz različnih teamov (včasih celo izven podjetja) delijo znanje, izkušnje in dobre prakse o področjih, ki jih zanimajo. Na primer:
Skupnost o UX/UI oblikovanju,
Skupnost o testni avtomatizaciji,
Skupnost o DevOps orodjih,
Skupnost o Scrum Master praksah.
Obstajajo tudi Communities of Practice (CoP), ki so bolj formalne in trajne, vezane na določen profil (npr. Scrum Master CoP, UX CoP, CAD CoP, Animation CoP).
CoI in CoP so samoorganizirane skupine zaposlenih, ki jih druži skupen interes. Srečanja se idealno izvajajo med delovnim časom, pogosto pa tudi izven (pivo pomaga).
Component community with component mentor
Praksa izvira iz Large-Scale Scrum (LeSS) okolij. Namen component community je podoben kot od popotnikov. Poizkuša odpraviti “silose” znanja, ki so običajno ozko grlo v procesu, in omogočiti prenose znanja med teami.
Component community
Je skupnost ljudi, ki se ukvarjajo z isto tehnično komponento (npr. baza podatkov, UI framework, API gateway, MFA…). Člani prihajajo iz različnih feature teamov, a jih druži to, da se pri svojem delu pogosto dotikajo iste komponente.
Namen skupnosti:
- usklajevanje smernic, arhitekture in dobrih praks,
- deljenje znanja o dotični komponenti,
- reševanje skupnih problemov,
- izogibanje podvajanja rešitev po teamih.
Component mentor
Je oseba z največ izkušnjami na določeni komponenti (nima pa lastništva nad njo).
Njegova/njena vloga je bolj mentorska kot operativna:
svetuje teamom, ki se srečujejo s komponento,
uči druge in s tem zmanjšuje odvisnost od sebe,
spodbuja dobre prakse, tako da komponenta ne postane ozko grlo procesa.
Component community se po potrebi lahko odloči, da bo organizirala Multi-Team Design Workshop (nižje), kjer bo svojo komponento predstavila širši organizaciji.
Namen component community je ciljno zmanjševanje in postopno odpravljanje silosa znanja o določeni produktni komponenti.
Multi-Team Design Workshop
Agilna praksa, kjer se več teamov zbere, da skupaj oblikujejo rešitev za prihajajoče delo.
Namesto da en arhitekturni team ali nekaj seniorjev pripravi dizajn, vse ekipe sodelujejo pri določanju, kako realizirati neko kompleksno funkcionalnost.
Namen je zagotoviti:
- usklajenost arhitekturnih in tehničnih odločitev,
- skupno razumevanje zahteve,
razdelitev dela med teame na smiseln način,
- hkrati pa pustiti teamom dovolj svobode za inovativno izvedbo.
Multi-Team Design Workshop srečanje
Izvedba Design Workshopa izgleda takole:
- Priprava: Product Owner in deležniki predstavijo planirano funkcionalnost ali večji backlog item.
- Iskanje rešitev: Teami se pomešajo v manjše skupine in predlagajo možne dizajne/rešitve.
- Skupine predstavijo svoje ideje.
- Konsolidacija: Teami izberejo ali združijo najboljše pristope, identificirajo odvisnosti in jih čim bolj zmanjšajo.
- Razdelitev dela: Z enotnim razumevanjem celote, teami v realizacijo prevzamejo posamezne funkcionalnosti.
Namen Multi-Team Design Workshop je, usklajevanje več razvojnih teamov pri realizaciji velikih funkcionalnosti, tako da ne prihaja do med teamskih odvisnosti in podvajanja dela. Dogodek se lahko izvede kod del več teamskega Sprint Planninga.
ZAKLJUČEK
S tem smo zaključili mini serijo člankov, ki so nas popeljali od formiranja teama, prilagajanja pristopa zrelosti teama in ne nazadnje do coachinga in komunikacijskih pristopov znotraj samega razvojnega cikla. Želim vam uspešno delo in veliko razvojnih teamov.
