V drugem delu serije člankov, razmišljam o verjetnih oblikah združevanja Scrum in Kanban frameworka. Zanima me tudi, kakšen vpliv bo združeni framework imel na organizacije, ki so do sedaj pretežno izvajale Scrum in kakšnega na tiste, ki so prakticirale Kanban.
CEREMONIJE
Primerjajmo ceremonije, ki se izvajajo v Scrum in Kanban okolju.
Paradoksalno opazimo, da organizacije, ki prakticirajo Kanban, čeprav te niso predpisane, v praksi izvajajo več ceremonij kot jih predvideva Scrum. Razlog za to je, da se Kanban, Agilne transformacije loteva inkrementalno. Pri tem z namenom zmanjševanja nasprotovanja spremembam, ohranja obstoječo hierarhično strukturo organizacije. Ceremonije so odraz te strukture. Nekateri dogodki kot na primer Queue Replenishment v osnovi sploh ne predvidevajo sodelovanja razvojnikov. Po drugi strani vsi Scrum dogodki vključujejo razvojnike. Večino aktivnosti, ki posegajo izven teama, v Scrumu izvajata za to predvideni vlogi Scrum Mastra in Product Ownerja. S tem se razvojniki razbremenijo odvečne koordinacije in se lažje posvetijo svoji primarni nalogi.
Glede na zgoraj napisano se zdi, da je Scrum glede ceremonij optimalnejši od Kanbana in bo združeni framework verjetno posvojil njegove ceremonije.
VENDAR – Scrum v svoji polno funkcionalni obliki zahteva organizacijo, ki je vsaj delno že izvedla Agilno transformacijo ali pa vsaj lastni organizacijski “mehurček”, ki je izoliran od ostale organizacije. Vezni člen je v tem primeru Product Owner z dovolj visokimi pooblastili znotraj hierarhičnega dela organizacije.
V združenem frameworku torej Product Ownerji brez sponzorskih pooblastil odpadejo.
Vloge Kanban ceremonij se bojo v združeni framework verjetno integrirale na naslednji način:
Kanban ceremonije se bojo zlile s Scrum ceremonijami oziroma prenesle na neformalne sestanke relevantnih deležnikov.
Scrum praksa se bo morala prilagoditi v toliko, da bojo razvite funkcionalnosti ob zaključku Sprinta resnično tehnično pripravljene na release. To pomeni, da bo DevOps postal del razvojnega cikla in bo pogoj “release ready” zajet v Definition of Done (DoD). Go DevOps! 😊. Dokler ne bo tako, bojo razvojniki prisiljeni sodelovati na Release Planning sestankih in po možnosti morali izvajati dodatne release Sprinte, kjer bojo že “razvite” funkcionalnosti tehnično pripravili na release. Ti Sprinti bojo ekstremno moteči za pretok funkcionalnosti, ki so že v razvojnem procesu. Release planning Sprint v flow okolju bi bil namreč enakovreden plazu prioritetnih (expedite) zahtev, ki bi popolnoma porušile predvidljivost razvojnega procesa.
TIMEBOXING
Iz tabele vidimo, da Kanban skoraj ne postavlja omejitev glede trajanja ceremonij.
Prvi razlog za to je verjetno načrtno izogibanje omejitvam z namenom, da se sodelujočim deležnikom pusti čim več svobode. Žal tukaj naletimo na paradoks Parkerjevega zakona, ki pravi, citiram:
“Work expands so as to fill the time available for its completion”
Drugi razlog je ponovno hierarhične narave, saj je odločitvena latenca preko hierarhičnih nivojev tradicionalno višja kot v bolj egalitarnem okolju. To velja tudi, če so na ceremoniji prisotni vsi potrebni hierarhični nivoji.
Časovna omejitev ceremonij je po mojem mnenju zaželena, saj zagotavlja energičnejše sodelovanje prisotnih ter vzpodbuja vnaprejšnji razmislek o argumentih in njihovi artikulaciji pred ostalimi deležniki. Ti se namreč potegujejo za iste razvojne resurse.
Združeni framework bo torej posvojil timeboxing Scruma. Edina izjema bi bil lahko Daily Scrum. V Kanban okolju teami namreč pogosto in brez problemov presežejo v Scrumu priporočeno število devetih članov. To se odraža predvsem v izvedbi Daily Standup, kjer veliki Kanban teami pogosto posvojijo časovno optimalnejšo metodo Walk the Board, kljub temu ta pogosto preseže omejitev 15 minut.
FLOW
Največ sprememb bo združeni framework doživel v mehaniki pretoka funkcionalnosti (PBI – Product Backlog Items) skozi razvojni proces. Timeboxing Sprinta bo prišel v konflikt s filozofijo kontinuiranega pretoka in SLE (Service Level Expectation).
Obstajata dve rešitvi.
Rešitev 1: Nedokončani PBIji se vrnejo v Product Backlog
Značilnosti:
- Nezaključeni PBIji se na koncu Sprinta vrnejo v Product Backlog.
- Product Backlog se pred začetkom novega Sprinta na novo sprioritizira skupaj z vrnjenimi PBIji. Ker so ti delno že razviti, imajo v naslednjem Sprintu višji ROI kot so ga imeli v preteklem. To jih v povprečju ohranja visoko v Product Backlogu, saj “sunk costs” niso faktor pri odločanju o naložbi. Ohranjanje visoke pozicije v Product Backlogu preko dveh zaporednih Sprintov je zaželeno zaradi kontinuitete razvoja posameznega PBI in s tem čim hitrejšega začetka vračanja investicije.
- V naslednji Sprint se potisne na novo prioritiziran spisek PBIjev glede na kapaciteto teama (velocity).
Posledice:
- Če se razvoj nezaključenih PBIjev nadaljuje v naslednjem Sprintu, to pomeni, da so ohranili konkurenčno poslovno vrednost glede na ostale PBIje v Product Backlogu. Njihov SLE ostaja kvalitetna metrika za planiranje.
- Nezaključeni PBIji, ki se niso uvrstili v naslednji Sprint, so bili izključeni, ker se je v vmesnem času pojavil PBI z višjo poslovno vrednostjo. Ta vrsta PBIjev se izključi iz SLE statistike, saj je bila degradirana iz poslovnih razlogov.
- Da bi se PBIji med Sprinti manj drobili, jih je priporočljivo razbiti na najmanjše enote, ki še prinašajo poslovno vrednost. Karakteristike dobrega PBI/uporabniške zgodbe so zajete v okrajšavi I.N.V.E.S.T.. Pri kombiniranem frameworku je to še pomembneje kot pri samostojnem Scrum ali Kanban pristopu.
- PBI dekompozicija in prioritizacija se tradicionalno izvajata na Backlog Refinement sestankih. Ti se izvajajo med Sprintom za naslednji eden do dva Sprinta. Opisani pristop to zakomplicira, saj zahteva, da se mini reprioritizacija, ki vključuje nezaključene PBIje, izvede še enkrat neposredno pred začetkom novega Sprinta. Najbolje bi jo bilo izvesti kot samostojni dogodek takoj po Sprint Retrospektivi, saj mora ta dogodek poleg predstavnikov razvojnikov vključevati tudi predstavnike naročnikov za katere se PBIji razvijajo in imajo zato besedo pri prioritizaciji. Po mojem mnenju ta dogodek nebi smel trajati dlje kot 30 minut.
- SLE se meri in velja samo za PBIje, ki so v celoti razviti znotraj enega Sprinta ali pa se njihov nezaključen razvoj nadaljuje v naslednjem Sprintu. Lahko tudi v naslednjih dveh ali treh Sprintih (en ali dva preskočena Sprinta). To je odločitev organizacije, ki mora temeljiti na dinamiki in okoliščinah razvoja.
- Razvojne faze, ki so na začetkih Sprintov tradicionalno nedejavne (testing), so s tem pristopom produktivne že takoj na začetku Sprintov. Tako se delno zmanjša tudi potreba po multifunkcionalnih članih teamov.
- V velocity metriko je potrebno vključiti tudi razvite Story Points nezaključenih PBIjev, saj je to metrika produktivnosti in ne realizirane poslovne vrednosti.
- Če team določenega PBIja ni uspel razviti v dveh Sprintih, le ta ni bil razbit na dovolj majhne enote (I.N.V.E.S.T.).
Rešitev 2: Brezpogojno nadaljevanje nedokončanih PBI v naslednjem Sprintu
Značilnosti:
- Razvoj nezaključenih PBIjev se v vsakem primeru nadaljuje v naslednjem Sprintu.
- Metoda ne vpliva na prioriteto čakajočih PBIjev v Product Backlogu.
- V naslednji Sprint se potisne samo toliko novih PBIjev, da se zapolni kapaciteta teama (velocity).
Posledice:
- Razvoj nezaključenih PBIjev se brezpogojno nadaljuje v naslednjem Sprintu neglede na to, ali so se medtem v Product Backlogu pojavili PBIji z višjim ROI. Da bi nadaljevanje razvoja nedokončanih PBIjev v resnici blokiralo razvoj PBIjev z višjim ROI, je malo verjetno, saj se bo iz prejšnjega Sprinta preneslo le nekaj PBIjev, pa še ti bojo na začetku Sprinta zaposlili kasnejše razvojne faze; kot na primer testiranje, ki je tradicionalno na začetku Sprinta manj obremenjeno.
- Da bi se PBIji manj drobili med Sprinti, jih je priporočljivo razbiti na čim manjše enote, ki še prinašajo poslovno vrednost. Karakteristike dobrega PBI/uporabniške zgodbe so zajete v okrajšavi I.N.V.E.S.T.. Pri kombiniranem frameworku je to še pomembneje kot pri samostojnem Scrum ali Kanbanu.
- Ta metoda je enostavnejša, ker ne zahteva dodatnega Backlog Refinement sestanka.
- SLE se meri in velja za vse PBIje.
- Razvojne faze, ki so na začetkih Sprintov tradicionalno nedejavne (testing), so s tem pristopom produktivne že takoj na začetku novega Sprinta. Tako se delno zmanjša tudi potreba po multifunkcionalnih članih teamov.
- V velocity metriko je potrebno vključiti tudi razvite Story Points nezaključenih PBIjev, saj je to metrika produktivnosti in ne realizirane poslovne vrednosti.
POVZETEK
Prva rešitev je malce kompleksnejša a prilagodljivejša glede kontinuiranega kreiranja najvišje poslovne vrednosti. Druga metoda pa je v bistvu samo periodično prekinjanje Kanban pretoka s Scrum ceremonijami.
Marsikatera posledica je enaka za prvo in drugo rešitev in lahko sklepamo, da velja na splošno za kombiniranje Scrum in Kanban frameworka.
Želel bi reči, da mi je bližje prva metoda, a je to v resnici odvisno od same organizacije. Končni rezultat verjetno ni pretirano različen.
DEUS EX MACHINA
Videli smo, da so navidezni konflikti med Scrum in Kanban frameworkom relativno preprosto rešljivi.
V članku sem opisal svoje videnje prihodnjega združevanja obeh frameworkov. Ali se bojo moje prerokbe uresničile, bo pokazal čas. Zagotovo pa bo združeni framework glede mnogih elementov fleksibilnejši, kot sta trenutno vsak zase.
V tretjem delu prispevka se bomo odmaknili od strokovnih tem in v slogu rumenega tiska spoznali nekaj zanimivih dejstev konflikta v Kanban skupnosti in njegovih akterjev, ter kako je to vplivalo na razvoj samega frameworka. Pravtako bomo omenili možne smeri Kanban in Scrum certifikacij.
