Razvojni timi uporabljajo različne Agilne in Lean pristope. Ti v večjem delu temeljijo na skupnih temeljih. Najpomembnejša sta:
- inkrementalni razvoj, ki omogoča pogoste povratne informacije in
- organizacijsko ustvarjanje pogojev za aktivacijo ustvarjalnega potenciala timov.
Obstajajo seveda tudi izjeme. Na pamet mi pade “agilni” framework, katerega “sales pitch” je zagotavljanje varnosti managementa v hierarhični organizaciji in nazivno dodajanje agilnosti v letno poročilo – ga ne bom imenoval.
Glede na skupne korenine, bi pričakovali, da so funkcijske vloge v Agilnih in Lean pristopih podobne in se razlikujejo predvsem po imenu. Poglejmo si, če je temu res tako, ali pa približki ostajajo samo približki?
Vloge v frameworkih ne nastanejo same po sebi, ampak kot odgovor na tri organizacijske potrebe:
- product discovery (kaj gradimo in zakaj),
- upravljanje razvojnega procesa (kako učinkovito sodelovati),
- tehnična koordinacija (usklajevanje arhitekture, kvalitete in integracije).
Različni frameworki te potrebe rešujejo z različnim številom specializiranih vlog. Približki
Približki
V spodnji tabeli sem tri Scrum vloge, na osnovi njihovih zadolžitev, preslikal na vloge ostalih frameworkov. Scrum vloge sem izbral, ker jih širši krog bralcev najbolje razume.
Preslikava je približna. Pri nekaterih frameworkih je na primer ločnica med framework procesom (Scrum Master – SM) in produktnim managementom (Product Owner – PO) zabrisana, ker imamo managerje, ki so zadolženi tako za produkt kot za timske procese. Prav tako je ponekod zabrisana ločnica med razvojniki in produktnim managementom, ko imamo vloge, ki sodelujejo tako v razvoju kot definiranju produktnih specifikacij. V primeru podobnih dilem sem vlogo mapiral glede na prevladujočo aktivnost oziroma proti desni (SM ⇒ PO ⇒ razvojniki). Približki
Tabela nakazuje, da imajo starejši* frameworki (RUP, DSDM), ki so bližje waterfall osnovam, več vlog. Po drugi strani, novejši frameworki težijo k njihovem zmanjševanju. Ekstrema v tej kategoriji sta Scrumban** in Kanban.
Razlog za to je verjetno demokratizacija procesov odločanja v organizacijah, krajšanje odločitvene latence in težnja po multifunkcijskih timih s T specialisti.
* Ko govorim o starejših in novejših frameworkih ne mislim samo na prvi datum njihove objave, ampak pri tem upoštevam tudi tempo razvoja in nivo implementacije. RUP (~1998) je datumsko novejši od Scruma (1993), ampak se skozi leta ni aktivno prilagajal novim spoznanjem in evoluciji razvojnih okolij, tako da je v ažurnosti zaostal za Scrumom. V tem smislu ga smatram za starejšega.
** V enem prejšnjih člankov, sem opisal zakaj Scrumban v resnici ni framework. Tukaj ga navajam zgolj kot primer Kanban anomalije, ki ji nekateri timi poizkušajo slediti.
Ali obstaja optimalna spodnja meja števila timskih vlog?
Verjetno da. V Kanbanu se v primerih kompleksnejših, slabše definiranih produktov, pogosto pojavlja problem razumevanja potreb naročnika (gulf of evaluation). Odkrivanje in interpretacija potreb je v Scrumu naloga Product Ownerja, v Kanbanu pa to breme pade na razvojnike.
V modernem product discovery procesu morajo biti vključeni tudi razvojniki, kljub temu pa zaradi učinkovitosti, ta proces zahteva koordinatorja. Iz tega razloga se je predvsem v kompleksnejših projektih izkazalo, da so Kanban timi, ki sodelujejo s produktnim managerjem (Product Owner) učinkovitejši od tistih brez njega.
Vloga enakovredna Scrum Mastru je zaželena iz istega razloga. Od samo organizirajočih timov pričakujemo, da bojo v večji meri sami reševali svoje težave. Ko pa te prerasejo okvire razvojnega tima je dobro imeti pomoč (Scrum Master), ki bo razvojnike razbremenila pogajanj z managementom.
Prihodnost
V zadnjih letih se je razvoj Agilnih frameworkov osredotočal predvsem na omogočanje učinkovitega širjenja razvojnih dejavnosti na več timov (scaling). Večina Scaled Agile frameworkov (63% – State of Agile 2024 report) za svojo osnovo uporablja Scrum, kar kaže na to, da je ta framework dosegel učinkovito ravnovesje timskih vlog in profitabilnosti.
Predvidevam, da se bo razvoj Agilnih in Lean pristopov v naslednjih nekaj letih osredotočal predvsem na:
- Izboljševanje med-timske koordinacije pri kreiranju kompleksnih integriranih produktov.
- Vključevanje razvojnikov v product discovery proces
- Vključevanje DevOps filozofije v same frameworke.
- Iskanje novih načinov za čim zgodnejši feedback končnih uporabnikov. Del “exploratory user testing” obremenitev bo prevzel tudi AI.
- Vključevanje Lean flow dinamike v Scrum. Ali preprosto povedano, združevanje Scrum in Kanban frameworka.
