Večina agilnih metod, ki smo jih predstavljali do sedaj, je namenjena predvsem manjšim timom, danes pa predstavljam nadgradnje agilnih metod, predvsem Scruma, ki se uporabljajo pri projektih, v katerih sodeluje več ljudi.

Najenostavnejša rešitev, ki je sicer zelo podobna tradicionalni organizaciji, je tako imenovan »Scrum of Scrums« (SoS) ali »meta Scrum«. Vsi sodelujoči se razvrstijo v Scrum time s 3 do 9 člani, koordiniranje dela med timi pa se izvaja prek tima, ki ga tvorijo predstavniki timov (Scrum of Scrums). Ko posamezni timi zaključijo dnevne sestanke, se predstavniki dobijo na usklajevalnem sestanku, a ne nujno vsak dan (priporoča se 2-3 sestanki tedensko), pri čemer usklajevalni sestanki niso omejeni na 15 minut. Vsebina sestanka je podobna vsebini predhodnih sestankov timov. V kolikor je sodelujočih še več, obstaja še en višji nivo (Scrum of Scrums of Scrums).

Neposredna nadgradnja Scrum metode je Nexus. Za koordniacijo med večjim številom timov skrbi usklajevalni tim (Nexus Integration Team, v nadaljevanju ga bom imenoval Nexus tim), v katerem so – poleg lastnika izdelka in Scrum mojstra – še člani tima, običajno sistemski inženirji, lahko pa tudi predstavniki timov. Sistemski inženirji nastopajo predvsem kot ključni strokovnjaki, ki usmerjajo delo timov in jih tudi učijo uporabe določenih orodij in praks. Nexus tim naj bi zagotovil, da vsak sprint prinese vsaj en uporaben rezultat.

Planiranje sprintov se izvaja v dveh korakih. Na prvem sestanku predstavniki timov, skupaj z Nexus timom, pregledajo in pokomentirajo aktualen zahtevnik (ang. Backlog) in za vsak tim določijo zahteve (funkcije, naloge) za tekoči sprint. Vsak tim nato samostojno splanira svoj sprint, pri čemer po potrebi sodeluje z drugimi timi. Skupni zahtevnik sprinta zagotavlja preglednost vseh izbranih postavk zahtevnikov timov in morebitne odvisnosti med njimi.

Nexus (Schwaber, 2018)

Na dnevnih sestankih Nexus tima sodelujejo predstavniki razvojnih timov, ki poročajo o napredku dela v svojih timih in kritično ocenijo dotedanji skupni (integriran) rezultat. Tega oceni Nexus tim tudi v reviziji sprinta (v razvojnih timih revizije ne izvedejo). Retrospektiva pa se izvede v treh korakih: na prvem sestanku predstavniki timov z Nexus timom izpostavijo težave, ki si jih imeli izven »meja« svojih timov, sledi retrospektiva po razvojnih timih, v tretjem koraku pa isti sodelujoči, kot na prvem, predlagajo korektivne akcije in spremembe (so)delovanja.

Tudi LeSS je zasnovan na Scrum metodi, kar pove že ime (Large-Scale Scrum). Ključna značilnost metode je, da za usklajevanje dela med timi ni formalno določenih koordinatorjev, ampak se timi po potrebi sestajajo sami, usklajujejo zahteve, delo in rezultate. Druga značilnost je pogostejše sodelovanje uporabnikov (poleg lastnika izdelka). Na polovici vsakega sprinta se timi namreč dobijo s končnimi uporabniki in pregledajo vmesne rezultate ter po potrebi podrobneje razjasnijo zahteve. Sicer pa se tudi pri tej metodi planiranje sprintov izvede v dveh korakih – v prvem si na skupnem sestanku vsak tim izbere naloge / funkcije, ki jih bo razvil v sprintu, po tem pa si vsak tim posebej splanira aktivnosti sprinta. Tudi revizija sprinta se izvede z uporabniki (in ne le z lastnikom izdelka): preveri se, če so rezultati skladni z zahtevami, željami in pričakovanji uporabnikov, odstopanja pa se odpravijo v naslednjem sprintu. Podobno, kot se planira, se tudi retrospektiva sprinta izvede v dveh korakih: najprej tim izvede svojo retrospektivo, potem pa se dobijo vsi sodelujoči in izmenjajo izkušnje, poleg tega pa ocenijo tudi sodelovanje med timi.

V kolikor v projektu sodeluje več kot 8 timov, se projektu priključijo še »področni lastniki izdelka« (APO – Area Product Owner). Govora je o strokovnih področjih, kar pomeni, da npr. en APO koordinira delo programerjev, drugi pa razvijalcev elektronike, itd…

LeSS (less.works)

SAFe v prevodu pomeni »Razširjen agilni okvir« (ang. Scaled Afile Framework). Metoda sistematično pokriva štiri ravni projektov. Na osnovni ravni – manj obsežnih projektih (in manjših timih) – sledi metodam Scrum in Kanban (ter Scrumban). Obsežnejši projekt na naslednji ravni imenujejo »Bistveno« (ang. Essential), projekt pa je razdeljen na programske cikle (ang. Program Increments), ki se običajno izvedejo skozi 5 dvotedenskih ciklov (ki jih ne imenujejo sprinti, ampak iteracije). Po koncu vsake iteracije se izvede skupen sestanek (ang. System Demo), kjer se ugotavlja stanje izvedbe, oceni dotedanje rezultate cikla, timi pa dobijo povratne informacije za izboljšanje rezultatov v nadaljevanju. V teh projektih sodeluje 5 do 12 timov (50 – 125 ljudi), timi pa so multi-disciplinarni. Vse time skupaj poimenujejo Agile Released Train (ART), koordinator pa je Release Train Engineer (RTE). Poleg njega so v ekipi še lastnik izdelka, Scrum mojster, sistemski arhitekt ter poslovni direktorji (ang. business owners).

Naslednja raven projektov je »Večja rešitev«, kjer prej omenjeni ekipi pridružijo novi timi ter kreator rešitve (ang. Solution Manager). Celotno ekipo poimenujejo »Vlak rešitve«, ključni koordinator pa je Solution Train Engineer (STE). Četrta raven metode se imenuje »Portfelj« in obravnava vse projekte v družbi.