V seriji treh člankov se bom posvetil prihajajočemu trendu združevanja Scrum in Kanban pristopov (frameworkov*).
Teme bojo razporejene približno tako:
1. DEL:
- Zakaj je združevanje Scrum in Kanban frameworka zaželeno.
- Kako izgledajo prvi poizkusi združevanja.
2. DEL:
- Verjetne različice združenega frameworka.
- Posledice implementacije združenega frameworka na pretežno Agilna in pretežno Lean okolja.
3. DEL:
- Antagonizem med dvema Kanban strujama.
- Posledice “državljanske vojne” v Kanban skupnosti.
- Primerjava obeh Kanban struj.
* Framework v slovenščino lahko prevajamo kot okvir, ogrodje, vodilo ali pristop. Ker je v kontekstu projektnega vodenja vse to, bom večinoma uporabljal kar angleški izraz.
ZAKAJ ZDRUŽEVANJE?
SCRUM
Scrum je framework. Izraz framework poudarja, da je to minimalno preskriptiven in istočasno maksimalno ohlapen organizacijski pristop.
Scrum se osredotoča na učinkovitost in z njo povezane organizacijske aspekte. Zaradi tega se ga da dobro kombinirati z drugimi frameworki kot na primer Extreme Programming (XP). Po raziskavi State of Agile 2022 je Scrum/XP hibridni pristop uporabljalo 5% razvojnih teamov, čisti XP pa samo 3%. V tem hibridu se Scrum osredotoča na procese in produktivnost, XP pa na tehnično odličnost.
Zaradi svoje odprtosti je Scrum tudi idealna osnova za scaled Agile pristope. Praktično vsi scaled Agile frameworki, ki so preživeli tržno sito, za svojo osnovo uporabljajo Scrum (Nexus, Scrum@Scale, LeSS, SAFe). Po State of Agile Report 2024 Scrum in njegove scaled izpeljanke uporablja 63% razvojnih organizacij.
KANBAN
Dojemanje Kanban sistema je zelo različno. Nekateri ga imenujejo strategija sprememb (change-management strategy), drugi ga definirajo kot aplikacijo WIP limit in Lean konceptov v razvoj programske opreme.
Kanban Guide 2020 ga opisuje kot:
“Kanban is a strategy for optimizing the flow of value through a process that uses a visual, pull-based system.”
Cilj Kanbana je optimizacija pretoka funkcionalnosti skozi razvojni proces in s tem doseganje predvidljivosti omenjenega procesa. To dosega na različne načine, ki v Kanban Guide niso predpisani in so izven obsega tega članka.
Sekundarni cilj Kanbana je vzdržnost razvojnega tempa. Torej ravnovesje med delom in zasebnim življenjem.
Opomba: Združeni Scrum in Kanban framework nikakor ni (in nikoli ne bo) tisto kar mnogi razumejo pod izrazom Scrumban. Scrumban kot framework ali metodologija ne obstaja, kar sem pojasnil v tem članku.
STIČNE TOČKE
Scrum smatramo za “push” sistem, ker se na osnovi predvidene teamske kapacitete (velocity) v razvoj (Sprint Backlog) potisne določena količina funkcionalnosti*.
* Obstajajo debate ali je to res push ali pa je v resnici pull, a za naš primer to ni ključno. V eni potezi namreč zapolnimo celotno kapaciteto teama (push v Sprint Backlog).
Kanban po drugi stani smatramo za pull sistem, ker se funkcionalnosti prevzemajo (pull) v razvojni proces individualno, ko se zanje sprosti kapaciteta. Iz tega razloga govorimo o pretoku funkcionalnosti skozi razvojni proces (flow). Seveda je naš interes, da je ta pretok čim hitrejši. Da v njem torej nimamo ozkih grl, blokiranih funkcionalnosti in odvečnega čakanja na prevzeme med fazami.
Ko v Scrumu funkcionalnosti enkrat potisnemo v Sprint, lahko rečemo, da jih razvojniki od te točke dalje, vlečejo iz Sprint Backloga v razvojni proces. To se dogaja skladno s prostimi kapacitetami v prvi razvojni fazi oz. sproščenimi kapacitetami med fazami.
Neželena alternativa temu, bi bil linearni (waterfall) razvojni proces znotraj Sprinta. Podrobneje sem to težavo opisal v tem članku.
Pull sistem (Kanban), znotraj push razvojnega cikla (Sprint), nam nudi možnost optimizacije pretoka funkcionalnosti znotraj Sprinta, kar do sedaj ni bila pogosto upoštevana možnost.
Ne samo, da nam Scrum pomaga optimizirati celoten razvojni proces, Kanban znotraj Sprinta nam poleg tega pomaga optimizirati učinkovitost dela razvojnikov in povečati predvidljivost izhodne kadence (output).
ZAČETKI ZDRUŽEVANJA
Zaradi določenih težav v vodilnih Kanban organizacijah, ki jih bom opisal v tretjem članku, je razvoj Kanban sistema rahlo zaostal za tekočimi trendi in praksami. Še posebej so se pokazale njegove pomanjkljivosti pri scalingu ter kontinuiranem zagotavljanju povratnih informacij s strani naročnika.
Trenutno najresnejši poizkus združevanja obeh frameworkov je s strani scrum.org, ki je izdal priporočila opisana v Kanban Guide for Scrum Teams.
Priporočila pazljivo ohranjajo strukturo Scrum razvojnega cikla, dodajajo pa nekaj dodatnih elementov.
Metrike
- Work in Progress – Sledenje številu funkcionalnosti (uporabniških zgodb*), ki so trenutno v razvojnem procesu, nam nudi transparentnost glede uspešnosti prilagajanja WIP limit in posledične optimizacije pretoka skozi proces.
- Cycle Time – Povprečni čas, ki ga uporabniška zgodba preživi znotraj razvojnega procesa. Ta vključuje tudi čakanje na prevzeme med fazami v razvojnem procesu.
- Work Item Age – Koliko časa se nezaključene uporabniške zgodbe že nahajajo znotraj razvojnega procesa.
- Throughput – Produktivnost teama oz. koliko uporabniških zgodb team povprečno zaključi na časovno obdobje.
* Kanban teami namesto izraza uporabniška zgodba pogosto uporabljajo izraz work item ali PBI (Product Backlog Item). Pomen je enak, s to razliko, da tehnično pogojenih funkcionalnosti teamu ni potrebno zapisovati v formatu uporabniških zgodb.
Definition of Workflow (DOW)
To so pravila in pogoji pod katerimi delo napreduje skozi razvojni proces, ter kdaj se za pričujoči team razvojni proces začne oz. konča.
V širšem smislu DOW lahko vključuje tudi povezane procese. Na primer kako se delo prevzema od nadrejenih procesov (marketing, produktni management) in kako se predaja podrejenim procesom (operations, sistemska integracija). Torej procesi, ki niso pod neposrednim vplivom razvojnega teama.
Cilj organizacije, ki je stopila na pot Agilne transformacije, je širjenje Agilnega pristopa preko meja organizacijskih silosov. S tem procesom se širi tudi DOW. Ali je širitev DOW katalizator omenjenih sprememb ali pa njihova posledica, je odvisno od spretnosti v procesu organizacijske transformacije.
Vizualno je širitev DOW opazna na Kanban tabli kot dodajanje procesnih stolpcev.
Service Level Expectation (SLE)
Napoved s kakšno verjetnostjo bo uporabniška zgodba/PBI/work item zaključena v nekem časovnem obdobju. SLE je sestavljen iz dveh delov. Verjetnosti izražene v procentih in časovnega obdobja (običajno izraženo v dnevih). Pri identifikaciji trenutne SLE si team pomaga s scatterplot diagramom.
Spodnji scatterplot vzet iz aplikacije Nave, nam glede trenutnega SLE pove, da imamo:
- 85% verjetnost, da bo uporabniška zgodba razvita v 29 dneh. Oziroma:
- 95% verjetnost, da bo razvita v 57 dneh.
Kakšno vlogo naj bi igral SLE znotraj časovno omejenega Sprinta (timebox) trenutno še ni znano. Konflikt trajanja SLE in časovno omejenih Sprintov se da rešiti na par načinov, ki jih bomo spoznali v drugem delu tega članka.
Scrum ceremonije
Njihov namen, trajanje ali način izvedbe se ne spreminjajo. Se pa vanje vključi tudi razmislek o optimizaciji pretoka.
Nekaj primerov:
- Sprint Planning: Throughput metrika teamu pomaga pri oceni količine dela, ki ga bo prevzel v Sprint.
- Daily Scrum:
- Ali smo prekoračili WIP limite?
- Ali imamo v procesu blokirane uporabniške zgodbe?
- Ali smo v procesu identificirali ozka grla?
- Ali v procesu obstajajo uporabniške zgodbe, ki so presegle SLE oz. jim to grozi?
- …
- Sprint Review: Na osnovi SLE deležniki lažje ocenijo verjeten čas za release.
- Sprint Retrospective:
- Kako je zadnja prilagoditev WIP limit vplivala na produktivnost (throughput)?
- Ali je razporeditev članov med razvojnimi fazami optimalna in ne ustvarja zastojev v procesu?
- …
ZAKLJUČEK
Proces združevanja Kanban in Scrum frameworka je šele na začetku. Je posledica dobre volje na obeh straneh nekdanjih okopov in iskrene želje po izboljšanju razvojnega procesa (ter delno tržnih pritiskov).
Po mojem mnenju je sinergija obeh pristopov mogoča in lahko odpravi pomanjkljivosti posamičnih pristopov. Kako se bo združevanje v resnici odvijalo žal ni odvisno samo od potreb razvojnih teamov, ampak tudi od ekonomskih interesov vpletenih skrbniških organizacij.
Svoje videnje mogočih smeri razvoja združenega frameworka bom opisal v naslednjem članku.
