Člani teamov, nezadovoljni s Scrumom, včasih pravijo, da bodo “kar prešaltali na Scrumban”, ker tam ni potrebno planirati.
To je pogosto prepričanje. Scrumban bo nekako ohranil vse prednosti Scruma, rešil pa nas bo dolgočasnega ocenjevanja velikosti uporabniških zgodb in planiranja Sprintov.
Naslednje vprašanje sogovorniku je seveda, kaj Scrumban sploh je. Odgovorov na to vprašanje je toliko kot sogovornikov.
To nikakor ne pomeni, da so sogovorniki v zmoti. Viri, ki samozavestno opisujejo Scrumban in njegove “principe” so številni. Pogosto si tudi nasprotujejo, dodajajo lastne Lean interpretacije, vrivajo svoje ideje in na splošno poizkušajo delovati kar se da resno. Kaže da ima vsak (in njegova teta) svoj Scrumban.
Ko sem se spraševal, kako smo zašli v to situacijo, sem se od problema malce odmaknil in si postavil štiri temeljna vprašanja o legitimnosti Scrumbana kot agilnega/lean frameworka:
- Ali obstaja enotna Scrumban definicija?
- Ali obstaja Scrumban skrbniška organizacija?
- Ali za Scrumban obstaja referenčno gradivo?
- Ali obstajajo splošno priznane Scrumban certifikacije?
Poiščimo odgovore nanje. Na koncu članka bom tudi na kratko povzel ideje, ki v resnici tvorijo Scrumban pristop. Ni jih veliko, a so zanimive.
1.) SCRUMBAN DEFINICIJA
Uradne Scrumban definicije ni. Še najbližje ji pride avtor samega izraza Corey Ladas v originalni (2008) knjigi s skrajšanim naslovom: Scrumban.
V knjigi, Corey pravi, da bi Scrumban sistem MOGOČE (zares pravi mogoče!) lahko bil Kanban pull sistem znotraj iteracijskega timeboxa. Zanimivo, da je izraz Scrumban v pričujoči knjigi uporabljen le štirikrat (ne štejem naslovov).
Druga zanimivost pa je, da avtor nekje na sredini knjige, opusti timeboxing v korist kontinuiranega pretoka (continuous flow).
2.) SKRBNIŠKA ORGANIZACIJA
Skrbniška organizacija, ki bi skrbela za enotnost Scrumban pristopa, ga dopolnjevala v skladu z novimi trendi in služila kot referenca za praktike, ne obstaja.
Corey Ladas sam pravi, da Scrumban temelji na “moralnih temeljih svobodnega raziskovanja”.
Iz tega sklepam, da podobne organizacije tudi nikoli ne bo.
3.) REFERENČNO GRADIVO
Osnova iz katere je nastal Scrumban trend, je že omenjena knjiga s polnim naslovom: Scrumban – Essays on Kanban Systems for Lean Software Development: And Other Essays on Kanban Systems for Lean Software Development, ki jo je leta 2008 izdal Corey Ladas.
Knjiga je zbirka esejev, se pravi Ladasovih razmišljanj o Lean praksah v kontekstu razvoja programske opreme.
Zanimivo je, da je bila knjiga izdana, kar dve leti predno je David J. Anderson izdal prelomno knjigo Kanban, ki je postavila formalne temelje Lean pristopa v razvoju programske opreme, uveljavila izraz Kanban sistem in ga pozicionirala kot konkurenco Scrumu.
Poleg omenjene knjige, druge referenčne literature za Scrumban ni. Nekateri avtorji in organizacije so poizkušali monetizirati ta trend, a so rezultati zaradi neobstoja Scrumban frameworka precej porazni.
Poleg originalne Scrumban knjige sta bolj reklamirani še:
- The Scrumban [R]evolution, ki ne prinaša v svet Agila in Lean ničesar novega. Knjiga je le dolgovezno (380 strani) ponavljanje Kanban idej in je temu primerno tudi slabo ocenjena s strani bralcev. Na moji lestvici literature je postavljena malo pod 1988 telefonskim imenikom Slovenije.
- Scrumban A Complete Guide – 2021 Edition stane 103 EUR in je tako slaba, da so ocene zanjo na Amazonu izključene za vse izdaje. Večinoma postavlja vprašanja (vključno s self-assessment testom), na katera naj bi si odgovarjali in bi nas postopoma pripeljala do sedme stopnje Scrumban zrelosti (maturity level). Seveda so si te stopnje avtorji gladko izmislili.
Lahko torej povzamemo, da Scrumban nima referenčne literature v smislu PMBOK (Project Management Body Of Knowledge), Scrum Guide ali SAFe 5.0 Distilled.
Posledično niti popularna orodja kot sta na primer Jira ali monday.com ne poznajo Scrumban predlog. Zadostuje namreč kar Kanban vmesnik.
4.) CERTIFICIRANJE
Uradno certifikacijsko telo za Scrumban ne obstaja. Nekatere organizacije pa kljub vsemu poizkušajo svoje prste pomočiti tudi v ta kozarec marmelade.
Ena bolj reklamiranih organizacij, ki nudi Scrumban certifikacije je IBQMI. Kljub WEB strani, ki se trudi biti zelo prepričljiva (ali pa ravno zato), so se mi o organizaciji porodili dvomi. Google Earth odkrije, da so vse tri njihove lokacije bolj ali manj generične narave. V najboljšem primeru poštni nabiralniki. Iskanje po Wyoming secretary of state bazi pa odkrije, da je podjetje v ZDA registrirano preko masovnega registrarja. Osebno sem v dvomih. Mogoče se bom iz radovednosti odločil za polaganje njihove “Certified Scrumban Practicioner” certifikacije. Samo zato, da si ustvarim mnenje – o katerem bom seveda tudi kaj napisal.
KAJ JE SCRUMBAN PRISTOP?
Naredimo še povzetek knjige, ki je vse skupaj začela (Corey Ladas: Scrumban).
Predstavljajmo si idealni pretok funkcionalnosti skozi Kanban sistem. Funkcionalnost (use case) je enota, ki končnemu uporabniku prinese neko poslovno vrednost.
CFD v procesu idealnega pretoka bi izgledal tako:
Ne pozabimo, da govorimo o idealnem pretoku, kjer “use cases” nastajajo z enako frekvenco, kot je kapaciteta razvojnega teama, da jih prevzema v razvoj. Ker ni čakalnih vrst, je čas od iniciative do produkcije (lead time) enak času dejanskega razvoja funkcionalnosti.
Večje funkcionalnosti je priporočljivo razbiti na manjše, vse dokler ne postanejo neodvisne in še imajo poslovno vrednost (work item). Jaz jih bom imenoval kar kartice, ker so na kanban tabli tako tudi predstavljene. Na ta način zmanjšujemo variacije velikosti uporabniških zahtev (use cases), ki jih prevzemamo v razvoj.
V takšnem idealnem sistemu, so Kanban Done bufferji enaki nič. Takoj, ko določena razvojna faza zaključi z delom na kartici, jo naslednja faza potegne k sebi (ker je s posredovanjem svoje kartice v naslednjo fazo pravkar pridobila prosto kapaciteto). To se zgodi brez zadrževanja v buffer stolpcu samo, če so work items približno enako veliki, kar je seveda praktično nemogoče doseči. Tak Lean ideal se imenuje one-piece-flow. V njem se vse kartice premaknejo v naslednjo razvojno fazo istočasno.
Na sliki je ta proces prikazan za en “flow”.
One-piece-flow si lahko predstavljamo tudi tako:
Knjiga nas skozi serijo miselnih iteracij pripelje do nekaj končnih idej, ki jih lahko povzamem v par točkah:
- WIP limiti razvojnih faz v procesu naj bojo čim nižji in naj pokrivajo tako “In progress” kot “Done” podstolpca posamezne faze – ena številka za oba stolpca.
- Variacije velikosti kartic v procesu in posledično čakanje, da prejšnja faza zaključi z delom na kartici, se kompenzira z multidisciplinarnimi strokovnjaki (arhitekt/programer ali programer/tester). Ti namesto čakanja, da prejšnja faza zaključi delo na kartici, aktivno pomagajo pri njeni realizaciji (swarming).
- Classes of service (swimlanes) naj imajo lastne WIP limite, ki se uveljavljajo istočasno z vertikalnimi WIP limitami.
- Ozka grla, ki se razkrijejo na ta način se aktivno odpravlja.
- V Scrumban idealu one-piece-flow ni nobenih elementov Scruma.
To je Scrumban. Zbirka esejev, ki dodajajo globje razumevanje dobrim Lean praksam, Eseji ne prinašajo nič takšnega, česar nebi vsebovala novejša Kanban literatura.
Knjiga je zanimivo branje v smislu “Lean razgibavanja možganov”. Primeri so razloženi preprosto in razumljivo ter nas vzpodbujajo v razmislek o trenutnih praksah.
Če ste v časovni stiski, je knjiga pozicionirana pod knjigo Kanban od Davida J. Andersona.
Par primerov Lean procesnega pristopa, ki jih predstavi Scrumban knjiga, slušatelji spoznajo tudi na tečaju Agile & Lean for Developers.
