Jaká je správná metodika vývoje pro vaši organizaci? To je otázka, se kterou vám může pomoci Cynefin framework, jenž tvrdí, že pro výběr správného řešení problémů je nutné nejprve porozumět povaze daného problému.
Vodopádový vývoj se osvědčí tam, kde lze vše naplánovat dopředu a kde jsou budoucí změny drahé nebo nemožné. Scrum bude vhodnější v méně předvídatelných a rychle se měnících podmínkách. Pokud potřebujete škálovat, můžete nasadit například LeSS.
Kdy je vhodné uvažovat a FaST Agile?
Možná se ale pohybujete v situaci, kdy potřebujete škálovat vývoj, a současně je komplexita, nejistota a rychlost změny taková, že přesahuje možnosti běžných škálovaných frameworků. Příklady takových situací jsou hledání nových, inovativních produktů a služeb, vývoj softwaru v prostředí s vysokou mírou nejistoty nebo rychlými změnami, řízení rozsáhlých změn a mnohé další.
Pro tyto, v dnešním rychlém a nepředvídatelném světě stále častější a složitější problémy, je vhodné využívat metodiky, které jsou pro takové prostředí vhodné. Jednou z nich je metodika Fluid Scaling Technology (FaST).
“FaST se ideálně hodí pro prostředí nebo výzvy, které vykazují složitost, rychlé změny nebo kde je potřeba inovace.” – FaST Guide 2.1
Proces a role aneb v jednoduchosti je síla
FaST metodika staví na přístupu Open Space Technology (OST) a jejím hlavním prvkem je samoorganizace. Z názvu je zřejmé, že je určena primárně pro škálování, ale může dobře fungovat i v prostředí jednoho týmu.
Základem je Kolektiv – skupina lidí, kteří společně spolupracují a samoorganizují se okolo práce. Nejsou zde (minimálně ne nutně) žádné další struktury, jako stabilní dlouho existující týmy, manažeři nebo další role. Existuje zde jedna výjimka – role Produktového manažera (PM), která je však chápána odlišně od ostatních agilních metodik a přístupů. PM je členem Kolektivu a přináší do něj typicky produktová témata, jako jsou produktová strategie, znalost zákazníka a businessu či product discovery. Nemá ale žádnou nadřízenou roli, nestanovuje priority, nespravuje backlog ani neakceptuje dodávky týmů – je prostě rovnocenným členem Kolektivu, který může zahrnovat i více PMs. Není ani nutné, aby mezi sebou měli nějakou hierarchii – stejně jako u ostatních rolí Kolektivu se mohou nominovat do role Team stewarda (viz dále) nebo se přidat do nějakého týmu. Jejich práce by vždy měla být plně transparentní na Marketplace boardu (viz dále).
Dále v Kolektivu existují již jen dočasné role, které se z něj rekrutují. Team steward je kdokoliv (např. technická role, PM, UX) z Kolektivu, kdo se rozhodne vést následující value cycle (viz dále). Feature steward je dobrovolná role, která dlouhodobě zastřešuje vývoj určitého úsilí Kolektivu a stará se například o architekturu, technickou kvalitu nebo konzistenci. Feature steward je v praxi často propojen s Team stewardem, ale ve větších vývojových celcích, kde se lidé z Kolektivu často střídají, je velmi užitečný.
Value cycle nemá pevně stanovenou délku (je předmětem experimentování, doporučená startovací délka jsou 2 dny), a jeho délka se může v čase lišit (např. v jednom týdnu může být cyklus dvou- a třídenní, zatímco v dalším týdnu jiný). Z hlediska doručení je cyklus principielně podobný jak u metodiky Kanban – jde o postup směrem k cíli, nikoliv závazek doručit něco konkrétního, nejde tedy o iteraci ve smyslu Scrumu.
Jak probíhá Value cyklus
- Value cyklus začíná zopakováním cílů kolektivu (typicky se jedná o úkol pro PM) a poté klíčovým principem FaSTu – samoorganizací. Někteří členové kolektivu se nominují, že by chtěli vést snažení v dalším cyklu (např. nějaký kus vývoje aktuální feature, experiment, technický dluh, product discovery atd.) a ostatní členové kolektivu určí priority tím, že se “přiřadí” k některému ze stewardů (důvody se mohou lišit – např. mám zde největší znalost, dává mi to největší smysl vzhledem k zákazníkovi, chci se zde něco naučit, potřebujeme vybudovat zastupitelnost a další). Většinou má kolektiv ve svých domluvách, že minimum členů ve Value cyklu jsou dva (z důvodu zastupitelnosti, review a dalších).
- Následuje až několik iterací samoorganizace, než se kolektiv domluví, co bude obsahem dalšího cyklu. Je žádoucí, aby zde probíhaly diskuze a challengeování s cílem najít nejlepší možné uspořádání. Rozhodnutí je ale na každém z členů kolektivu.
- Poté následuje vlastní práce na cyklu včetně autonomní synchronizace (pod vedením Value Cycle Stewarda) s ostatními týmy a stakeholdery. Jakým způsobem tým synchronizaci uchopí, je zcela na něm.
- Cyklus končí krátkou synchronizací tzv. “show & tell”, kde dynamicky vzniklé týmy prezentují výsledky své práce.
Zopakování cílů, samoorganizace a show & tell probíhá na jediném meetingu na začátku cyklu – FaST meetingu. FaST meeting podporuje artefakt nazývaný Marketplace board, který zobrazuje práci vybranou na aktuální cyklus a kdo z kolektivu se k ní přidal.
Hranice kolektivu nejsou pevné – kdokoliv z ostatních částí organizace může přijít na FaST meeting a představit svůj záměr. Dále se s ním zachází stejně jako s kterýmkoliv jiným – aby se uskutečnil, musí se najít steward, který si jej vezme, a musí se najít členové kolektivu, kteří se ke stewardovi přidají.
Silné stránky metodiky
Z popisu procesu vyplývá, že přínosy metodiky budou tím větší, v čím náročnější doméně se kolektiv pohybuje. Metodika má mnoho aspektů, které ji dělají pro taková prostředí vhodnou:
- krátké cykly a možnost přizpůsobení jejich délky
- flexibilní prioritizace a jednoduchá reakce na změnu
- dynamická práce s týmy umožňující jejich jednoduché přeskládání vzhledem k okolnostem
- plná kompatibilita s product discovery, případně s libovolnými přístupy The Lean Startup
Například na začátku projektu může kolektiv pracovat jen na product discovery (stewardem jsou PMs nebo UX designéři a techničtí lidé se k nim přidávají) a technickém designu a architektuře. Postupně se náplň práce může plynule měnit směrem k vývoji featur a ke konci vývoje část kolektivu zase začne pracovat na product discovery nového tématu. Do toho může některý dynamický tým řešit např. adopci některé z minulých featur.
Metodika FaST je vzhledem ke své jednoduchosti velmi univerzální a dá se nasadit nejen do prostředí vývoje softwaru, ale i do prakticky libovolné jiné domény a libovolného týmu. Praktickou zkušenost mám např. s využitím na úrovni leadership týmu vývojového oddělení, kde obsahem value cyklů byly např. implementace konkrétních změn na úrovni vývojového oddělení, podpora vybraného vývojového týmu nebo reakce na zpětnou vazbu od lidí z vývoje v rámci průzkumu spokojenosti.
Zajímavou perspektivu dává pohled na FaST agile na základě principů Lean a Lean Software Development. Lean obecně staví na důležitosti koncových lidí v organizaci a na tom, že oni jsou ti, kteří by měli být v kontaktu se zákazníky, dělat rozhodnutí a jejich empowerment je kritickým předpokladem jejich motivace.
„Lean využívá inteligenci pracovníků v první linii a věří, že to jsou právě oni, kdo by měl určovat a neustále zlepšovat způsob, jakým vykonávají svou práci.” Lean Software Development
Je zřejmé, že FaST agile jde s tímto pohledem na věc ruku v ruce, protože deleguje plnou odpovědnost za priority, proces a výsledek na členy kolektivu.
Předpoklady pro nasazení
FaST agile ke svému efektivnímu nasazení vyžaduje zejména ochotu delegovat odpovědnost na kolektiv (a přesunout role manažerů do polohy, kde jejich úkolem je primárně podporovat kolektiv v jejich snažení – servant leadership přístup). Na druhé straně je to vyzrálost členů kolektivu, projevující se zejména ochotou tuto odpovědnost a svobodu přijmout.
Tyto zmíněné faktory mohou představovat hlavní překážku v adopci FaST agile přístupu. Je ale třeba si uvědomit, v jak náročném (konkurence, technologické změny, nejistota …) a rychle se měnícím světě se pohybujeme a zda není čas provést změny, které umožní vaší organizaci v tomto století prosperovat.
„Najměte dobré lidi a nechte je na pokoji. Když kolem lidí postavíte ploty, získáte ovce. Dejte lidem prostor, který potřebují.“ William L. McKnight, dřívější CEO 3M
Doporučení pro zavedení metodiky
Na závěr ještě zmíním několik tipů, které se mi při zavádění FaSTu osvědčily.
- Změna metodiky bývá náročná změna a je třeba, aby měla vyhrazeného drivera, který je v první linii s kolektivem a stakeholdery a změnu řídí.
- Vizualizujte Marketplace board pomocí nástroje typu Miro nebo Mural. Důvodem je flexibilita těchto nástrojů a jednoduchá možnost asynchronní práce. Do budoucna se kolektiv může rozhodnout nástroj vyměnit. Máme ověřeno, že jako podpora FaSTu dobře funguje i např. Atlassian JIRA.
- Minimálně pro první týdny – než si celý proces „sedne“, než se usadí psaná a nepsaná pravidla a než si lidé zvyknou na svou novou roli v kolektivu – je vhodné dát kolektivu k dispozici schopného facilitátora.
- Věnujte náležitou pozornost vysvětlení role PM – nejen lidem na této roli a kolektivu, ale i všem relevantním stakeholderům. Důvodem je velká odlišnost od toho, jak tuto roli chápou ostatní agilní metodiky.
- Maximálně podpořte stewardy v jejich práci a užitečná praktika je i vytvoření návodu, jak v této roli co nejlépe obstát.
- Zajistěte, aby stakeholdeři daného kolektivu chápali, jak budete fungovat, byli sehraní a mluvili jako jeden.
