CYNEFIN pomůže určit, kdy aplikovat agile

Co je to CYNEFIN a proč jej zastánci agilního způsobu řízení projektů propagují a vychvalují při všech možných příležitostech? A proč je zas mnohdy slyšet, že agile nefunguje, nelze nasadit apod.? Mohou mít pravdu „oba tábory“?

Základem je samozřejmě pochopení a porozumění, co to agilní přístup k řízení projektu vlastně je a proč se v některých případech ukazuje jako velmi užitečný a jindy zas jako zcela nevhodný. O některých aspektech tohoto dilema jsme již psali např. zde. Ostatně, je obvyklé, že jeden přístup zkrátka nepokrývá celou problematiku. To již zkušenější projektoví i top manažeři dobře vědí.

O agile či vodopádu toho bylo již napsáno mnoho. Nicméně, a poněkud paradoxně, většina textů se moc nezbývá, jaké projekty a v jakém prostředí vlastně probíhaly. Zdánlivě demonstrují „konvenční“ nebo iterativní přístup na stejném projektu ve stejném kontextu. To však může být velmi zavádějící! Právě kontext a projektem řešený typ problému je důležitý pro správné rozhodnutí, zda aplikovat konvenční přístup, iterativní přístup nebo třeba celou záležitost pojmout úplně jinak.

Rámec CYNEFIN

Zmapujme si tedy nejprve prostředí, ve kterém se obvykle pohybujeme. K tomu je vynikající rámec CYNEFIN [KUN-iv-in] (původem slovo z velštiny znamenající oblíbené místo, místo výskytu apod.), se kterým přišel v roce 1999 Dave Snowden z IBM Global Services. Rozděluje kontext, ve kterém se pohybujeme, na pět domén:

Jasné / jednoduché

První doména představuje dobře známé problémy a jasným očekávaným výsledkem a postupem řešení (také nazýváno jako „známé známé“). Jsou známa pravidla či nejlepší praxe, prostředí je stabilní a je jasná posloupnost „když A, pak B“.

Doporučení chování v této doméně je „porozumět, zařadit, zareagovat“. Tedy poté, co pochopíme situaci, je třeba ji správně zařadit a pak už jen konat dle daných pravidel pro danou situaci.

Například může jít o příchozí objednávku. Pracovník, ke kterému objednávka dorazí, ji zařadí podle předem daných kategorií a poté aplikuje příslušný postup – např. předání na příslušné oddělení k vyřízení a vystavení zálohové faktury.

Je tedy zřejmé, že tato doména je doménou procesů, jasně daných postupů a obecně osvědčené praxe. Např. pro objednávku od klienta typu X vždy požadovat platbu předem. Ve zkratce jde tedy o nalezení příslušného pravidla a jeho aplikaci.

Bohužel, někdy se stává, že mají manažeři tendenci některé problémy a situace příliš zlehčovat a tlačit je do této domény. To může mít katastrofální důsledky s koncem v doméně chaosu (implementovat nový ERP systém je přece jednoduché, stačí to jen nastavit…).

Komplikované

Druhá doména sestává ze „známých neznámých“. Pro správnou reakci (a posouzení vztahu jestliže – pak) je potřeba analýza situace a výběr z možných správných řešení (dobré praxe).

Příkladem problému z této domény může být např. stavba mostu. Neexistuje jeden typ / návrh mostu vhodný do všech prostředí. Existují však normy a standardizované postupy pro návrh a stavbu mostu.

V této doméně jsou tedy klíčovými hráči inženýři, specialisté, experti apod., kteří jsou schopni správné analýzy dané situace a návrhu správného řešení.

Komplexní

Ve třetí doméně nám neurčitost dále narůstá a pracujeme s „neznámým neznámým“. Vztah jestliže – pak je možné dedukovat pouze zpětně. Nelze dopředu zjistit, co je správným řešením.

Doporučení pro tuto doménu je „prozkoumat – porozumět – zareagovat“. Tedy zkusit něco udělat (prototyp, sondu), pochopit, co se stalo a následně na to reagovat.

Rozdíl mezi komplikovaným a komplexním je třeba jako rozdíl mezi letadlem a firemní kulturou. Letadlo je jistě velmi komplikované, nicméně zkušený technik ví, kde hledat problémy a jak je řešit tak, aby letadlo dále fungovalo a bylo to stále dané letadlo. Na druhé straně, třeba změna dodavatele stravovacích služeb může vést i k velmi nečekaným a nepředvídatelným dopadům v rámci korporace, např. zvýšené fluktuaci zaměstnanců nebo snížení nemocnosti atd.

Jako komplexní situace jsou obecně označována např. bojiště, trhy, ekosystémy, firmy a další systémy, které jsou jako celek mnohem více než pouhá suma jednotlivých částí.

Chaos

Čtvrtá doména je reprezentována naprostou nejasností vztahu jestliže – pak. Doporučeným postupem je zde de facto hledání ostrůvků stability. Není čas a prostor dělat komplexní analýzy k pochopení situace.

Proto je také doporučen postup „jednat, porozumět, zareagovat“. Tedy začít něco dělat, porozumět, co je a není stabilním a následně reagovat se snahou změnit chaos na komplexní situaci.

Příkladem chaosu může být situace těsně po nějaké katastrofě nebo třeba teroristickém útoku. Na začátku není vlastně moc jasné, co se vlastně stalo, jak je to velké atd., nicméně (poněkud zjednodušeně), hasiči prostě začnou hasit, záchranáři odvážet zraněné a situace se po nějakém čase „dostane pod kontrolu“. Na začátku je třeba především předejít panice – a tedy „prostě začít něco dělat“.

Zmatek

Temná pátá doména uprostřed je to, co většina lidí v ČR intuitivně nazývá jako chaos (CYNEFIN však chaos přeci jen definuje jako zvládnutelnou čtvrtou doménu). Tedy, v CYNEFIN doméně „zmatek“ (disorder) především „nikdo nic neví“. Není jasné, do jaké z úvodních čtyř domén problém patří, lidé se hádají mezi sebou a celkově se jedná o jistou kakofonii, během které „levá ruka neví, co dělá pravá“.

Jedinou cestou ven je případné rozdělení situace na dílčí části a ty zařadit do příslušných domén.

Pohyb mezi doménami

Je obvyklé, že se zvyšující se zkušeností a znalostí se týmy a firmy postupně mohou posouvat po směru hodinových ručiček – tedy že co bylo ze začátku chaosem, je po získání zkušeností komplexní situací, komplexní situace se s ustálením dobré praxe stává komplikovanou situací a ta se zas může po svém zvládnutí redukovat až na jednoduchý problém.

Vyvíjet se může i samotná situace. Např. vybudování pobočky mezinárodní firmy může být ze začátku komplexní problém, který se poté, co už jsme tři pobočky vybudovali, mění na komplikovaný (už máme zkušenosti a praxi) až po jednoduchý (rozjíždíme stopadesátou stejnou franšízu).

Pohyb může být samozřejmě i opačným směrem, např. když z firmy odejdou pracovníci s klíčovými zkušenostmi a jejich znalost je tak ztracena.

Pozn.: Velmi povedená CYNEFIN infografika je např. zde.

Využití CYNEFIN v projektovém managementu

Pozornějším čtenářům jistě neuniklo, že první a čtvrtá nebo dokonce pátá doména nemá s projekty moc společného. Jasné a jednoduché problémy jsou řešeny procesně, chaos je spíše o krizovém řízení a zmatek je někdy především ve firmě jako takové.

Z pohledu PM jsou tedy zajímavé především domény komplikované a komplexní. Jak již bylo uvedeno výše, příklad problémové situace v komplikované doméně je třeba stavba mostu. Obecně do komplikované domény patří především projekty, které mají poměrně jasně definovaný výsledek a jsou realizovány v prostředí, které je celkem stabilní. Břehy řeky obvykle moc nemění svou polohu. Může se tedy jednat i o konstrukci nějakého technologického zařízení, stroje, jednoznačně zadané IT aplikace apod. Můžeme se na to podívat i z trochu jiného úhlu – poměru mezi nejistotou (nestabilitou prostředí) a neurčitosti zadání, co má být výsledkem:

CYNEFIN doporučením pro komplikované problémy je aplikovat dobrou praxi. Což jsou v kontextu PM především standardy a metodiky pro řízení projektu (IPMA, PMI, PRINCE2). A, protože jsme v komplikované doméně, mělo by být možné (a správné) řešený problém podrobně analyzovat, navrhnout správné řešení a to poté zrealizovat.

Což je ve své podstatě „vodopádový“ styl řízení projektu. A je zde správně. A správně je zde samozřejmě aplikovat i koncepty jako je rolling-wave planning (PMI) či jeho aplikaci v PRINCE2 v podobě podrobného plánování jen nadcházející etapy, zatímco ty další jsou plánovány nahrubo (a tedy jisté náznaky iterativity).

Co ale v komplexních situacích?

Zde se můžeme snažit i dlouho analyzovat, počítat a navrhovat a přesto výsledek nebude správný. V komplexní doméně je vynikající přístup k projektům agile, respektive iterativní přístupy. Přesně ve smyslu CYNEFIN doporučení „prozkoumat – porozumět – zareagovat“. Ať už se jedná o SCRUM nebo přístupy typy rapid prototyping apod. Základem je udělat nějaký experiment, prototyp, první náčrt, získat zpětnou vazbu a podle toho postupovat do další iterace.

Při rozhodování, zda se snažit vytvořit agilní tým se všemi nezbytnými atributy nebo postupovat „konvenčním“ způsobem je tedy velmi vhodná úvaha, v jaké problémové doméně se problém řešený projektem nalézá. Stavět most pomocí SCRUM týmu asi nikoho nenapadne. U IT nebo organizačních projektů už ale nemusí být situace tak zřejmá.

Předně, v projektech, které mají mnoho zainteresovaných stran, množství uživatelů apod. Máme vždy poměrně vysokou pravděpodobnost, že se bude jednat spíše o komplexní situaci. Pokud navrhujeme informační systém s dopadem na značnou část firmy, téměř jistě se jedná o komplexní situaci. Přistoupit k ní jako k situaci komplikované nebo dokonce jednoduché téměř jistě povede k velmi neuspokojivým výsledkům (a řadu takto nepovedených implementací IS jsem měl možnost osobně vidět).

IT není nutně jen komplexní

Na druhé straně, pokud „pouze“ migrujeme data z jednoho systému do druhého, tak byť se může jednat o techniky komplikovaný proces, nebude zřejmě agilní přístup tím nejlepším. Tedy za předpokladu, že se nám migrovaný a cílový systém nemění pod rukama ;).

Dobrým námětem na agilní projekt jsou také různé webové portály. Ty se mohou zdát jednoduché, ale upřímně, kdo je vůbec schopen dát dostatečně podrobné zadání na web? A pak jej neměnit a být spokojený a bez připomínek s dodaným řešením?

A proti – pokud máme prostě „vyrobit“ generátor s jasně danými parametry, tak nás sice čeká práce v konstrukci, nákupu, výrobě atd., ale nejedná se o vhodnou situaci pro iterativní přístup. Proč? Protože k tomu existuje lépe fungující dobrá praxe!

Postupujme tedy při aplikaci iterativních či konvenčních přístupů uvážlivě, podle toho, v jaké doméně CYNEFIN se nachází náš problém. Alespoň základně nás to může nasměrovat správným směrem.