V klasickém projektovém řízení již dlouho existuje disciplína Změnový Management (Change Management). Jde o sadu rolí a aktivity, které se potýkají s nutností změnit již domluvené a naplánované. Znáte to – chystáme se, sbíráme požadavky ze všech stran, pak to dáme dohromady, zanalyzujeme to, nadesignujeme to aby to celé dávalo smysl – vše je ideální. Jenže jakmile na tom začne pracovat tým… skoro okamžitě se začnou dít změny. Mění se plánovaný rozsah, objevují se zapomenuté požadavky, některé naprosto nutné potřeby se ukážou vlastně nepotřebnými, a podobně. Právě proto existuje Změnový Management, který každou takovou příchozí změnu analyzuje a následně zpracovává tak, aby celek opět dával smysl. Ať už odmítnutím (více práce než užitku), nebo zapracováním do plánu. Vzhledem k tomu. že v dnešní době se změny dějí téměř neustále, je toto velice důležitá činnost.
V Agilním světě je tomu trošku jinak. Samo Agilní myšlení staví na jednoduché myšlence adaptivnosti, že “změna prostě je” a počítá s ní od prvopočátku. Jakýkoliv Agilní přístup je tedy stavěn s myšlenkou, že změny budou přicházet neustále a že je třeba s nimi počítat. Toto je zdůrazněno i v principech Agilního manifesta, bod 2: “Vítáme změny v požadavcích a to i pozdějších fázích vývoje…”
Známý Agilní framework Scrum je toho příkladem – v něm si tým plánuje jen sadu nejprioritnějších úkolů a to typicky jen na 14 dní dopředu. Pak bude nejvyšší čas se opět rozhlédnout a ověřit, že stále kráčíme tím správným směrem. Pokud žádná změna nepřišla, pokračujeme dalšími prioritními úkoly. Ale pokud změna přišla, můžeme na ni ihned reagovat.
Zastánci ještě větší dynamiky používají metodologii Kanban, kde není ani fixace na 14 dní, pracuje se vždy jen na několika málo nejvyšších prioritách a o tom co se bude dělat dále se můžeme rozhodnout pokaždé, když něco dokončíme.
Toto vysvětluje jak Agilní přístupy fungují na operativní týmové úrovni. Jak si ale plánovat strategicky? Naši zadavatelé a vlastníci chtějí typicky vidět dále, než jen na horizont 14 dní. Agilní přístupy se tímto vypořádávají typicky dvoufázovým plánováním:
V první fázi se také shromažďují a analyzují požadavky zadavatelů, nicméně se analyzuje jen nutné minimum tak, abychom sice tušili o čem potřeba je, ale abychom na tomto spálili pouze minimum času a úsilí. Výstupem bývá takzvaný Backlog – prioritizovaný seznam všeho, o čem aktuálně víme že potřebujeme zpracovat, co je lehce odhadnuto a o čem s jistotou můžeme říct, že se to bude měnit. Na základě i těchto hrubých odhadů už jsme schopni (často až s překvapivou přesností) stanovit hrubé hranice celé větší aktivity – kolik to asi bude stát, kdy to asi bude – a tím pádem zda ji vůbec chceme startovat. A to vše za minimální investici – poměrově porovnáváme úkoly vůči podobným z minulosti.
V druhé fázi se ihned ponoříme do práce a začneme tyto požadavky z Backlogu podle priority odbavovat. Jejich hluboká analýza přichází až zde, kdy je opravdu chceme ihned odbavit. Už během prvních dnů tak získáme cenné lekce z praxe. Typicky jsou to lekce jako “tahle oblast je mnohem komplikovanější než jsme si mysleli”, “tady vůbec nevíme, jak to vlastně mysleli” případně “tady to je mnohem jednodušší, to bude brnkačka”. Tohle všechno jsou už zástupci prvních změn, které se vkrádají do našeho plánu a tím pádem do Backlogu:
- “Komplikovanější” se stává téměř vždy, protože až na samotné práci se často setkáváme s realitou, která nebývá tak růžová jako naše plány. Zde máme hned možnost reagovat buď komunikací že se plán prodlužuje, hledáním, jak tento požadavek dělat jednodušeji, případně škrtnutím některých požadavků.
- “Nevíme” se také stává často – když se popis potřeby ukáže být nedostatečný, nebo se původně plánované řešení ukáže nemožným. V takové chvíli nás tato realita ihned pošle zpět k zadavateli pro vyjasnění, nebo přepracování požadavku (a tudíž správnému pochopení). Tímto předcházíme typickému zklamání z řešení “zadavatel to ASI chtěl takhle”.
- “Brnkačka” jsou ty nejvítanější změny, protože nám zkracují cestu k cíli. A uvolňují místo v Backlogu pro další požadavky, případně pro předchozí dva typy změn.
Zbývá si určit, kdo je tedy ten “zadavatel”, který se o daných změnách dozvídá a reaguje na ně. Typicky se v Agilních přístupech používá role z metodologie Scrum, role Vlastníka Produktu (Product Owner). Tato role spravuje svou danou oblast (ať už je to doopravdy Produkt, nebo jen vývojový tým) a stará se o jejich Backlog – aby v něm byly nahoře ty nejprioritnější požadavky a aby tým měl jasno co dělat, případně koho se zeptat. Je zástupcem všech zákazníků a podobných stakeholderů vůči týmu. Je tím pádem finální autoritou nad svým Backlogem a rozhoduje, co se bude dělat v případě té či oné změny. A díky tomuto přístupu ke změnám interním už je poměrně snadné podobně nakládat i se změnami externími – změny potřeb, změny trhu, změny priorit, atd.
Toto je způsob, jak se Agilní přístup vypořádává s omezeními plynoucími z Železného Trojúhelníku. Tvrdí, že už od začátku NEVÍME (jen tušíme), jak je tento trojúhelník velký a že na změnách a zpřesňování je třeba pracovat neustále. Ať už tím, že odebíráme původně plánované požadavky (změna Rozsahu), nebo posouváme finální čas (změna Času), dlouhodobě rozšiřováním kapacity týmu (změna Nákladů), nebo i riskantně tím, že ošidíme kvalitu (změna Kvality). A to vše podle aktuální situace, možností a shody se zadavateli/strategií. Agilní přístup tak vlastně povyšuje Změnový management na primární mechanismus tím, že vše je už od počátku změna a že je to tak správně.
Přínos tohoto přístupu ke změně:
- Transparentnost – nevytváří falešnou představu, že se věci nemění, naopak, pracuje s nejistotou, že toto je aktuální obraz a ten se bude měnit. To má i pozitivní vliv na lidskou reakci na změny, protože tady neustále víme, že přijdou, není zde falešný pocit jistoty stability a tím pádem je odpor ke změně výrazně nižší.
- Flexibilita – jakákoliv změna je vítána. Jistě, každá má svou cenu, ale pokud je pro nás stav po změně výhodnější, než stav před ní, je to změna k lepšímu.
- Rychlost – tento přístup může vést k rychlejšímu Času uvedení na trh (TTM), protože nám přinese nejdůležitější hodnotu v nejkratším možném čase.
- Cena – pokud je takováto reakce na změnu přirozenou součástí procesu, nepotřebujeme pak žádné zvláštní analýzy jednotlivých změn, ani schvalovací komise. Toto zjednodušení procesu se projeví na nákladech. A opět, doručení nejdůležitější hodnoty v nejkratším čase nám mohou pomoci dojít k minimálnímu hodnotnému výstupu (MVP) dříve a tento monetizovat (profit), případně u něj skončit (méně nákladů).
