Večina sodobnih produktov je prekompleksnih, da bi jih lahko realiziral en sam razvojni team. Kompleksnost je lahko posledica same narave izdelka, ali pa se postopoma povečuje tekom razvoja produkta, ko začnemo z MVPjem in nato inkrementalno dodajamo nove funkcionalnosti. scaling
Omejitve s strani teama, ki se posledično pojavijo so lahko:
- Pomanjkanje znanja za pokrivanje vseh obstoječih in planiranih aspektov produkta.
- Produktivnost obstoječega teama, ki zaradi kompleksnosti razvoja ne zagotavlja dovolj pogostih releasov na trg.
- Tržni pritiski, ki narekujejo pospešen razvoj.
Pokazatelji, da je kompleksnost razvoja postala prevelika za obstoječi team (ali teame) so običajno:
- Namesto, da bi teami na koncu Sprinta predstavili skupen produktni inkrement, to parcialno zase naredi vsak team posebej. Predstavniki stranke oz. končni uporabniki, ki na Sprint Review ocenjujejo primernost inkrementa in dajejo teamom povratne informacije, si v takšni situaciji težko ustvarijo sliko trenutnega stanja produkta. Ali so teami prepričani, da bojo parcialno predstavljene rešitve, enkrat združene, delovale kot koherentna celota? Ali bojo teami pred releasom potrebovali še poseben “integracijski” Sprint? Kdaj bo izveden? Ali bo potreben le eden? Dlje kot teami razvijajo svoje kodne branche, težje jih bo integrirati v trunk.
- Teami pred releasom potrebujejo poseben Sprint. Običajno se imenuje hardening, release, stabilization ali integration Sprint. Kakršno koli ime pač ima, potreba po njem kaže, da teami na koncu Sprintov do sedaj niso bili sposobni kreirati integriranega “done” produktnega inkrementa (potentially releasable).
- Kreiranje integracijskega teama katerega naloga je integracija dela ostalih razvojnih teamov v funkcionalno celoto. Učinkovitost takšnega teama in pritisk na njegove člane si lahko samo predstavljamo. Kdo si želi interpretirati in integrirati kodo desetih različnih razvojnikov? Že samo iz tega razloga je integracijo potrebno izvajati sproti.
- Kreiranje “undone” teama katerega naloga je zaključevanje dela, ki ga ostali teami tekom Sprinta niso uspeli zaključiti. Naloga “undone” (ja res se tako imenuje) teama je še širša kot integracijskega teama, saj poleg integracije razvija tudi manjkajoče funkcionalnosti iz Product Backloga.
Agile Scaling
Soočena z naštetimi izzivi, mora organizacija na razvoju produkta angažirati več teamov.
V takšnem razširjenem okolju imajo teami na koncu Sprintov pogosto težave z realizacijo integriranega produktnega inkrementa. Razlog za to je podcenjevanje kompleksnosti koordinacije več teamov, ki razvijajo skupni produkt.
Bistvo organiziranega Scalinga je:
- Planiranje dela na način, ki zmanjšuje med teamske odvisnosti, ki bi lahko povzročile zastoje v procesu.
- Preprečevanje podvajanja dela, ko več teamov nevede vzporedno razvija isto funkcionalnost.
- Sprotno med teamsko usklajevanje razvojnih dejavnosti in kreiranje skupnih standardov.
- Boljše usklajevanje razvojnega dela z organizacijsko strategijo.
Pristopi / frameworki
Vsi Scaled Agile frameworki naslavljajo omenjene izzive. Poleg tega se diferencirajo po svojem fokusu. Nexus na primer poudarja zmanjševanje med teamskih odvisnosti, Scrum@Scale Agilno transformacijo, LeSS linearno rast produktivnosti, SAFe koeksistenco Agilne in hierarhične organizacije.
Lahko bi rekli, da večina Scaled Agile frameworkov v določenem okolju uspešno izvaja svojo predvideno funkcijo, zaradi svoje diferenciacije pa niso vsi primerni za vsako organizacijo in organizacijsko kulturo.
Delta Agile nudi edini tečaj na trgu, ki predstavi štiri Scaled Agile frameworke. Nexus, Scrum@Scale in LeSS spoznamo na nivoju, ki slušateljem omogoči implementacijo v lastni organizaciji, SAFe pa na informativnem nivoju.
