Razvojni teami uporabljajo množico Agilnih, Lean in hibridnih waterfall pristopov. Ti v večjem delu temeljijo na skupnih postulatih. Najpomembnejša sta ciklični inkrementalni razvoj, ki omogoča pogoste povratne informacije in ustvarjanje pogojev za aktivacijo ustvarjalnega potenciala teamov.
Obstajajo seveda tudi izjeme. Na pamet mi pade framework, ki zagotavlja varnost hierarhične organizacije v “Agilnem” okolju – ampak ga ne bom imenoval 😊
Glede na skupne korenine, bi pričakovali, da so funkcijske vloge v teh pristopih podobne in se razlikujejo predvsem po imenu. Je res tako, ali pa približki ostajajo samo približki?
V spodnji tabeli sem tri Scrum vloge, na osnovi njihovih zadolžitev, preslikal na vloge ostalih frameworkov. Scrum vloge sem izbral, ker so dobro razumljene širšemu krogu bralcev.
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 na primer managerje, ki so zadolženi za produkt in istočasno teamske procese. Pravtako 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 zmanjševanju števila vlog. Ekstrema v tej kategoriji sta Scrumban** in Kanban.
Razlog za to je verjetno demokratizacija procesov odločanja v organizacijah in težnja po multifunkcijskih teamih 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 teami poizkušajo slediti.
Samo razvojniki? Ali obstaja spodnja meja števila teamskih vlog?
Verjetno da. V Kanbanu se v primerih kompleksnejših, slabše definiranih produktov, pogosto pojavlja problem razumevanja potreb stranke (gulf of evaluation). Odkrivanje in interpretacija le teh je v Scrumu naloga Product Ownerja, v Kanbanu pa to breme pade na razvojnike. Ti se pogosto ne želijo ukvarjati z organizacijo tržnih raziskav in fokusnimi skupinami. Zanimajo jih samo interpretirani rezultati omenjenih aktivnosti (PO). Pravtako ne želijo izgubljati časa z odstranjevanjem organizacijskih preprek (SM). Najdražji razvojnik je tisti, ki ne dela, za kar je usposobljen. Če pa govorimo o ožji definiciji razvojnikov (arhitekti, programerji, testerji), je njihov čas tudi monetarno najdragocenejši.
Praksa je pokazala, da je pretok funkcionalnosti skozi razvojni proces najoptimalnejši, če z razvojniki kontinuirano sodeluje predstavnik produktnega managementa. To je lahko Product Owner (Scrum), produktni manager (Kanban) ali projektni manager (DSDM). S tem se razvojniki razbremenijo nalog zajemanja in (delno) interpretacije produktnih zahtev, kar jim omogoči osredotočanje na svoje primarne naloge.
Vloga enakovredna Scrum Mastru je zaželena iz istega razloga. Čeprav isti Scrum Master lahko istočasno pokriva več teamov, je to priporočljivo le v naprednejših Agilnih okoljih kjer so razvojni teami dosegli določeno stopnjo organizacijske zrelosti (Tuckman).
Prihodnost
V zadnjih letih se je razvoj Agilnih frameworkov osredotočal predvsem na omogočanje učinkovitega širjenja razvojnih dejavnosti na več teamov (scaling). Večina Scaled Agile frameworkov za svojo osnovo uporablja Scrum, kar kaže na to, da je ta framework dosegel učinkovito ravnovesje teamskih vlog in profitabilnosti.
Predvidevam, da se bo razvoj Agilnih in Lean pristopov v naslednjih nekaj letih osredotočal predvsem na:
- Izboljševanje med-teamske koordinacije pri kreiranju kompleksnih integriranih produktov.
- 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.
