Zavedení funkčních Scrum týmů do struktury organizace představuje značnou výzvu a mnohé snahy v této oblasti končí neúspěchem. Pokud však máte více vzájemně závislých týmů, které pracují na společném produktu nebo v rámci jednoho hodnotového toku, je zapotřebí robustnějšího řešení.
Je nezbytné využít škálovací rámec, který zastřeší Scrum týmy. Tento rámec by měl poskytnout procesy a pravidla, která umožní týmům synchronizaci, sladění cílů a orientaci v celkovém procesu vývoje.
Často se stává, že vznikají tzv. „silo týmy“, což jsou v podstatě samostatné Scrum týmy, které se zaměřují na své lokální cíle, avšak s minimálním povědomím o společném cíli celého projektu. Právě zde vstupuje do hry Scaled Agile Framework (SAFe).
Co je SAFe?
Zdroj: scaledagileframework.com
SAFe je přístup, který aplikuje agilní principy a procesy na tradiční hierarchické struktury. Nejde o vytváření nové struktury, ale o organické zavedení druhého systému, který je většině stávajících zaměstnanců známý a intuitivní.
SAFe je založen na několika klíčových hodnotách:
Sjednocení
- Všechny Scrum týmy by měly chápat vizi a strategii a znát konečný cíl, ke kterému směřují.
- Propojte strategii mezi týmy a veďte je ke společnému cíli.
- Komunikujte s týmy jednotným, srozumitelným jazykem.
- Pravidelně ověřujte, zda týmy rozumí cílům a vizi.
- Týmy by se měly soustředit na zákazníka a chápat, kdo jsou jejich zákazníci a co potřebují. Strategie by měla tyto potřeby odrážet.
Transparentnost
- Vytvořte prostředí, kde každý může pracovat co nejlépe a bez nedůvěry.
- Otevřeně sdílejte argumenty a fakta. Buďte přímí a upřímní, neskrývejte důležitá fakta před týmy.
- Rychle se poučte z chyb. Pokud něco selže, rychle to zjistěte a poučte se z toho. Následně strategii upravte.
- Vizualizujte rozpracovanou práci, aby ji všichni lépe pochopili.
- Zajistěte snadný přístup k potřebným informacím.
Úcta k lidem
- Zdůrazňujte lidský aspekt. Nepovažujte lidi za pouhé zdroje.
- Oceňujte rozmanitost lidí a jejich názorů. Podporujte upřímnou zpětnou vazbu.
- Rozvíjejte a vzdělávejte lidi prostřednictvím koučování a mentoringu.
- Uvědomte si, že zákazník je ten, kdo využívá vaši práci.
- Budujte dlouhodobá partnerství uvnitř i vně týmů.
Neustálé zlepšování
- Vytvořte prostředí, kde řešení problémů motivuje týmy.
- Zamyslete se nad tím, jak se vám dařilo v minulém týdnu a zjistěte, co lze v budoucnu udělat lépe.
- Berte fakta jako nejdůležitější argument pro zlepšení.
- Poskytněte čas a prostor pro inovace. Dejte týmům příležitost experimentovat a zkoušet různé přístupy, i když nejsou zcela bezpečné.
SAFe vnáší do škálovaných agilních systémů prvek spolupráce a komunikace. Nenahrazuje jednotlivé aktivity Scrum Team Sprint, které již provádíte.
Klíčovým prvkem SAFe je Agile Release Train (ART). Jde o dlouhodobý a stabilní tým složený ze Scrum týmů (obvykle až 12), který pravidelně dodává nové inkrementální funkcionality po každém sprintu. Vyvíjejí, dodávají a podporují jedno nebo více řešení v rámci pracovního toku.
Zdroj: scaledagileframework.com
Role v SAFe
SAFe spoléhá na osoby s různými povinnostmi. Dodržování rolí je zásadní pro úspěšnou implementaci rámce. Je proto důležité rozumět jednotlivým rolím a jejich účelu.
#1. Agilní tým
Agilní týmy jsou multifunkční, což znamená, že mohou v rámci týmu pokrýt veškeré potřebné dovednosti. Jsou také samoorganizující se a samostatně definují, vytvářejí, testují, implementují a uvolňují nové hodnoty.
Každý agilní tým má schopnosti realizovat daný rozsah v dohodnutém a závazném termínu. Tým tento rozsah implementuje navyšováním v každém sprintu, a to předvídatelným způsobem. Předvídatelnost je klíčová, protože umožňuje týmu se zavázat k plnění konkrétních cílů v daném čase. Komunikace a efektivní dodávání výsledků jsou klíčové hodnoty, které musí tým neustále zlepšovat.
Agilní tým hraje klíčovou roli při plánovacích setkáních Program Increment (PI) pro vytváření příběhů v rámci sprintů a jejich plánování. Nakonec se týmy zavazují k naplnění cílů PI.
Scrum Master koučuje agilní tým a usnadňuje týmová setkání. Odstraňuje překážky a chrání tým před vnějšími vlivy. Účastní se setkání Scrum v rámci ART.
Product Owner (PO) je dalším důležitým členem týmu. PO je zástupcem zákazníka a má přímý vliv na příběhy a jejich prioritizaci. PO komunikuje s ostatními PO, aby definoval a upřednostňoval příběhy v backlogu.
#2. Product Management
Produktový management stojí nad Scrum týmy a dohlíží na sladění cílů. Musí pokrýt následující povinnosti:
- Zajistit dosahování obchodních cílů tím, že vývojové týmy vytvářejí životaschopné a udržitelné produkty a řešení.
- Chápat potřeby zákazníků a zajistit, aby produkty odpovídaly definovaným požadavkům zákazníka.
- Zajistit, aby byl v backlogu vždy dostatek připravených funkcí.
- Podporovat tok práce přes programové desky a do programového backlogu.
- Určit rozsah dalšího přírůstku programu prioritizací funkcí, které týmy vytvořily. Produktový management nese konečnou zodpovědnost za definici dalšího PI.
#3. Systémový architekt / Inženýrství
Technický tým analyzuje a rozvíjí schválený obsah v backlogu příběhů. Je odbornou součástí týmu a je zodpovědný za:
- Vytvoření a udržování Architectural Runway, aby nové funkce mohly využívat technologické prostředky.
- Aktivní účast na plánování Program Increment. Účast na ukázkách systému na konci každého Program Increment.
- Spolupráci s agilními týmy na implementaci nových prvků architektury. Tím umožní týmům vytvářet nové funkce.
- Pomoc agilním týmům při definování řešení a rozhodnutí na vysoké úrovni. Navrhování alternativních řešení a nejlepších přístupů pro ověření koncepčních aktivit uvnitř agilních týmů.
- Vytváření architektonické dráhy. To je definice technologických aktivátorů připravených pro spotřebu funkcemi definovanými jednotlivými týmy.
#4. Vlastníci podniku / Zúčastněné strany
Tyto role se nacházejí mimo Scrum týmy, ale hrají zásadní roli v SAFe v každé fázi provádění projektu.
Před plánováním PI:
- Poskytují vstupy pro zpřesňování backlogu.
- Účastní se plánování před PI podle potřeby.
- Zajišťují, aby klíčové zainteresované strany, včetně Release Train Engineer (RTE), produktového managementu a systémových architektů, porozuměly a souhlasily s obchodními cíli.
Během plánování PI:
- Poskytují obchodní kontext a vizi pro nadcházející PI.
- Účastní se revize návrhu plánu a přidělují obchodní hodnotu cílům PI týmů.
- Účastní se hodnocení managementu a pomáhají řešit problémy, které vedou k přijetí konečného plánu.
Po plánování PI:
- Aktivně se podílejí na udržování souladu mezi obchodními a vývojovými cíli, protože se priority a rozsah nevyhnutelně mění.
- Pomáhají ověřovat definice minimálního životaschopného produktu (MVP) pro Program Epics a řídí rozhodnutí o tom, zda pokračovat nebo vytrvat na základě dosažení MVP.
- Účastní se ukázek systému, aby sledovali pokrok a poskytovali zpětnou vazbu.
- Účastní se akcí plánování sprintů agilních týmů a retrospektivních sprintů podle potřeby.
- Podílí se na řízení verzí se zaměřením na rozsah, kvalitu, možnosti nasazení, uvolnění a tržní aspekty.
#5. Release Train Engineer (RTE)
RTE organizuje aktivity lidí a týmů v rámci ART. Představuje roli Scrum Mastera pro celý program. K hlavním povinnostem patří:
- Řízení a optimalizace toku hodnot přes ART.
- Vytvoření a sdělení ročního harmonogramu sprintů a programových přírůstků (PI).
- Moderování plánovacích setkání PI.
- Uspořádání týmů a pomoc při vytváření shrnutí jejich stanovených cílů PI. Přenesení cílů týmů do celkových cílů plánu PI.
- Propojení týmů za účelem komunikace a řešení rizik a vzájemných závislostí.
- Propojení produktového managementu, vlastníků produktů a dalších externích zúčastněných stran za účelem sjednocení strategií.
- Organizování workshopů Inspect and Adapt s cílem neustále zlepšovat již zavedené procesy a činnosti.
- Vyhodnocování aktuální úrovně agilní metodiky napříč týmy a definování dalších kroků pro zlepšení.
#6. Vedení
Vedení definuje strategii programu a poskytuje týmům veškeré potřebné nástroje a podporu. Vytváří systém, ve kterém vše ostatní funguje. Je tedy klíčové mít manažerský tým, který určí správný účel a definici hodnot. Jejich hlavní povinnosti jsou:
- Jít příkladem.
- Přijmout růstové myšlení.
- Zdůrazňovat hodnoty a principy SAFe.
- Rozvíjet lidi.
- Vést změny.
- Podporovat psychickou bezpečnost.
Plánování Program Increment (PI)
Plánování PI je dvou až třídenní akce s cílem porozumět a zavázat se k práci pro následující přírůstek programu. Může to být například následující čtvrtletí.
Produktový management je zodpovědný za prioritizaci funkcí identifikovaných během plánování PI. Agilní týmy jsou zodpovědné za plánování kapacit, vytváření příběhů, odhady a závazek k cílům PI.
Plánování PI je pro SAFe zásadní. Pokud neprovádíte plánování PI, v podstatě nezavádíte SAFe.
PI proces
Zdroj: scaledagileframework.com
Plánování PI začíná s několika vstupy. Každý pracovní proud shromáždí své potřeby a nápady na další vývoj pro své produkty. Tyto vstupy pak předkládá během PI:
- 10 nejlepších funkcí pro další implementaci.
- ART Backlog připravený k formulaci epopejí nebo funkcí.
- Vize vlastníka produktu.
Diskuze probíhá mezi různými pracovními proudy. Každý z nich představuje své vize a rysy. Zdůrazňují, co je důležité dále implementovat a co k tomu potřebují. To může zahrnovat:
- Povolení poskytnutá jinými pracovními proudy pro další vývoj funkcí.
- Závislost na jiných pracovních proudech a nutnost prioritizovat.
- Aktuální problémy v systému, které je potřeba vyřešit před dalším postupem.
- Personální výzvy pro tým. Možná stále chybí klíčové role pro implementaci obsahu, který funkce vyžadují.
- Rozpočtová omezení, která brání pracovnímu proudu v realizaci vize v daném časovém rámci.
- Další rizika, problémy, předpoklady nebo závislosti, které tým dokáže rozpoznat a vyžadují širší diskuzi mezi SAFe týmy, aby se dosáhlo shody.
Průběh PI
Samotné plánování PI je často rozděleno do několika dní, obvykle dvou až tří, přičemž agenda může být následující:
Den 1
- Diskuze o obchodních cílech a nadcházejících klíčových cílech, které tvoří celkovou vizi a strategii programu. Vedení tuto část řídí a jasně komunikuje s týmem.
- Představení všech funkcí z pracovních toků a jejich prioritizace v souladu se společnou vizí.
- Prezentace vize architektury a definování hlavních cílů požadavků na vývoj. Zdůraznění technických problémů a dohodnutí řešení překážek napříč týmy.
Den 2
- Detailní vysvětlení procesu plánování týmům. Nastínění očekávaných výsledků po uzavření PI.
- První rozdělení týmů do menších skupin. Cílem je vytváření návrhů plánů a identifikace překážek a rizik.
- Po dokončení práce v menších skupinách týmy prezentují a kontrolují vytvořené návrhy plánů před ostatními týmy.
- Následuje krok pro vedení, kdy se kontrolují plány a vydávají pokyny k iniciativám pro řešení vzniklých problémů. Úpravy plánů se provádějí na základě zjištěných výzev, rizik a překážek.
Den 3
- Začátek dne s úpravami plánování, které jsou nyní v souladu s předchozím setkáním s vedením.
- Týmy vypracují finální plány a upraví rizika a překážky. Vlastníci podniku přiřazují obchodní hodnotu cílům týmu.
- Týmy prezentují finální plány před celým publikem.
- Probíhá diskuse o zbývajících rizicích na úrovni programu a používají se informace o rizicích ROAM (vyřešené, vlastněné, přijaté, zmírněné).
- Týmy hlasují pro vyjádření důvěry ve výsledky plánování Program Increment.
- Pokud jsou hlasy příliš nízké nebo celková důvěra je stále nízká, následuje dodatečné plánování.
- Po PI Commitment RTE plánuje retrospektivu pro týmy, aby se prodiskutovalo, jak plánování probíhalo a co se dá zlepšit pro příští kolo. Vedení prezentuje další kroky spolu s konečnými pokyny.
Výsledek PI
Konečným výsledkem plánování PI je seznam funkcí plánovaných k dokončení podle sprintů v následujícím období PI. Všechny známé závislosti mají přesný plán, jak vyřešit a odblokovat pokrok funkcí.
Týmy se zavazují ke svým cílům a rozsahům. Pokud existují další cíle, které nejsou nutně součástí seznamu, považují se za doplňkové. Ty se mohou stále potenciálně řešit, pokud to čas a zdroje dovolí.
Týmy dokumentují a sledují všechna rizika programu a mají přesný plán, jak se s nimi vypořádat.
Týmy také zaznamenávají všechny retrospektivní nápady, které se objevily na retrospektivním setkání, a označí je jako poučení pro příští plánovací sezení PI.
Konkrétně pro týmy existuje několik očekávání, jako například:
- Týmy se zavazují k cílům s obchodními hodnotami.
- Týmy počítají svou kapacitu pro každý sprint, aby lépe odhadly realizovatelnost obsahu roadmapy.
- Berou v úvahu i aktuální zátěž pro každý sprint.
- Příběhy se přiřazují ke konkrétním sprintům každého pracovního proudu na základě poskytnuté kapacity.
- Týmy hlasují pro vyjádření důvěry v plán PI a jeho obsah.
Závěr
I po přečtení všech výše uvedených informací se implementace SAFe nemusí zdát jednoduchá. Transformace velké organizace na SAFe je extrémně náročný úkol. V některých případech se může zdát nemožný. I když se některé ze základních principů implementují, obvykle je zapotřebí mnoha iterací, než lze s jistotou prohlásit, že jste „SAFE“.
Postup často narušuje některé hierarchické principy a pravidla, které se obtížně odstraňují. Můžete provádět rozsáhlé plánování PI a dosahovat výsledků, ale co to znamená, když pracovní týmy nefungují v souladu s agilní metodikou?
Zde není prostor pro kompromisy. Buď jste plně zapojeni se všemi správnými procesy, lidmi a myšlením, nebo jste mimo, pokud alespoň jeden z aspektů metodologie není skutečně dodržen.
Než začnete uvažovat o implementaci SAFe, ujistěte se, že jste zvládli principy a způsoby práce agilního týmu. Nejen z pohledu vedení, ale dejte týmům možnost hlasovat a vyjádřit upřímný názor. Možná budete překvapeni výsledky.
Podívejte se na kvalitní vzdělávací zdroje pro získání agilní certifikace.
Byl tento článek užitečný?
Děkujeme za Vaši zpětnou vazbu!