Proč je vlastně agile takovým trendem?

Dnes už asi nikdo moc nevěří zapáleným prezentacím, které slibují, že agile vyřeší všechny problémy lidstva. Přesto i ve střízlivých příspěvcích je např. poměrně často prezentována tabulka z CHAOS Reportu 2015 od Standish Group, ve které je uvedeno, že zatímco zcela úspěšných agilních projektů je 39 %, u projektů řízených vodopádem to je pouze 11 %. A zcela neúspěšných agilních projektů je pouze 9 %, zatímco vodopádových celých 29 %. Zbytek jsou projekty, které trpěly různými těžkostmi (a je jich stále víc než 50 %, bez ohledu na přístup!). Výzkum byl proveden nad daty z 10 000 SW projektů z let 2011—2015, takže se nejedná o žádný malý vzorek. Zajímavé je také rozdělení podle velikosti projektů:

I zde je vystavena celkem jednoznačná směrovka na agilní cestu. Nicméně – čím větší projekt, tím horší čísla, a to dramaticky, i u agilních projektů.

Proč vychází agilní projekty jako úspěšnější?

I přes vrozenou nedůvěru k průzkumům, které lze vhodným výběrem vzorků více či méně ovlivnit, se zdá, že čísla dokazují vyšší pravděpodobnost úspěchu u agilně řízených projektů. Nebo z druhé strany, mnohem vyšší pravděpodobnost velkého průšvihu u vodopádově řízených projektů (42 % velkých SW projektů řízených vodopádem je podle CHAOS reportu 2015 totální průšvih!).

Vodopád, tak jak je obecně vnímán, v sobě totiž nese mnohem větší riziko. Proč? Již desítky let se opakují stále ty samé příčiny neúspěchu projektů, kterými jsou lidské zdroje (kvalifikace, nedostatek kapacit), kvalita zadání a nedostatečná podpora či nekompetentnost sponzora a/nebo zákazníka projektu (viz průzkum Projektové řízení v ČR 2015, který provedla společnost PM Consulting ve spolupráci se Společností pro projektové řízení). Takové závěry si přečtete v podstatě v jakémkoliv průzkumu o PM z posledních dekád.

Ať už jde o malou firmu nebo korporaci, tak obzvláště u SW projektů nejsme dost dobře schopni formulovat své požadavky, čímž snižujeme pravděpodobnost na úspěch hned od začátku.

Aktuálně konzultuji jeden ERP projekt, ve kterém jeho manažer obcházel tři hlavní uživatele a posbíral požadavky jako „chceme snížit administrativní zátěž“. Když se pak ptal dál, co je tím vlastně myšleno, tak dostal pokyn, ať něco vymyslí.

Když se takovéto požadavky dostanou do toku vodopádu, vede to pochopitelně k velkému průšvihu… který se však objeví až za 12 či 15 měsíců, za které se nejen nainvestovalo značné množství prostředků, ale také se ledasco změnilo (ve firmě, na trhu, apod.).

Je zde samozřejmě institut změnového řízení, ale přiznejme si, obzvláště u většího projektu je velká výzva uřídit větší množství komplexních změn. V tom je iterativní přístup mnohem lepší. Mnohem dříve je doručen nějaký dílčí výsledek, o kterém se dá diskutovat. Mnohem rychleji se zjistí, že se vyrábí něco, co je zcela špatně.

Mimochodem, Ondřej Kavula na Konferenci PM ve Zlíně zmínil, že zažitý koncept vodopádu vznikl zřejmě vlastně omylem. V roce 1970 publikoval Winston W. Royce koncepci řízení vývoje rozsáhlých SW systémů, kde na druhém obrázku figuruje všem známý vodopád. Publikace se údajně dostala do rukou úředníkovi US Army, který byl zodpovědný za proces nákupu SW pro armádu. Obrázek se mu líbil, a tak nastavil všechny poptávky a smlouvy na daný systém – takže firmy to tak začaly dělat.

Daný úředník ovšem zřejmě nečetl dál… neb hned pod daným obrázkem W. W. Royce píše: „I believe in this concept, but the implementation described above is risky and invites failure.“ A následně, po dalších znepokojujících komentářích, prezentuje následující schéma:

Zbytek konceptu pana Royce je pak již plný iterací a drobných, opakovaných cyklů.

Proč je agile ve firmě často expresivní vulgarismus?

Přiznejme si, že návody se v ČR moc nečtou. O to méně metodiky a podobné věci. Princip je přece jasný, tak hurá do toho! Nebo se dokonce ukáže, že si dotyční pouze přečetli agilní manifest a jediné, co si z toho odnesli, bylo vykašlání se na všechnu otravnou dokumentaci – to je přece agile, ne? Nebudeme nic plánovat ani dokumentovat a uvidíme, co z toho vyleze…

Avšak aby např. SCRUM (ale i jiné metody agilního vývoje a řízení projektů) opravdu fungoval, jsou třeba určitá pravidla. Je potřeba ctít dané principy. A to se až příliš často neděje a management firmy je pak nepříjemně překvapen, že ten agile vlastně vůbec nepomohl, nebo co hůř, spíše uškodil.

Např. jsou pravidla typu, že jeden sprint má dán svůj rozsah. Na konci sprintu je třeba demonstrovat, že je daný rozsah hotov a funguje. Každý balík práce, který je do sprintu vpuštěn, má jednoznačnou definici, co to znamená, že je hotovo, je testovatelný, odhadnutelný na náročnost atd. (to mimochodem neustále překvapuje účastníky našeho kurzu Agilního PM).

Poté se bavíte s lidmi, kteří hrdě prohlašují, že „řídí“ (nebo častěji řídili) projekty agilně, a doslýcháte se věci, jako že: „Tento požadavek jsme si rozplánovali na tři sprinty.“ Což je v ostrém rozporu s jedním ze základních pravidel. Když hovoříte dál, tak se buď dozvíte, že se projekty vlastně řídí stejně jako dříve, jen se to jinak nazvalo, nebo že se udělala určitá kombinace s tím, jak byli lidé zvyklí pracovat s agilem… což ve finále znamená, že všichni fungují stejně jako dříve. A diví se, že i projekty fungují, či spíše nefungují stejně jako dříve.

Tři důvody, proč je nasazení agile obtížné

Za prvé, je to změna

A pořádná. Takže se negativně podepisuje setrvačnost organizace a odpor vůči změně je silný.

Za druhé – agile se nehodí na vše

Agile prostě není vhodný na všechny projekty a do každého prostředí. Je to nástroj jako každý jiný. Stejně jako je kladívko dělané na zatloukání hřebíků, zatímco šroubovák si poradí se šroubky a vruty. Jistě, vrut můžete při troše síly zatlouct i kladivem, ale s výsledkem zřejmě nebudete spokojeni. Pro agilní přístup jsou vhodné projekty, u kterých není dost dobře možné specifikovat jejich rozsah a požadovaný výsledek. Kde tu specifikaci prostě natolik nejsme schopni vytvořit, že nám to stojí za změnu na agilní přístup. Pokud je požadovaný výsledek zřejmý, je spíše lépe použít nějaký konvenčnější přístup k řízení projektů, protože bude fungovat a nebude tak náročný na provedení (byť je pravda, že užití některých agilních prvků je přínosné i na velmi vodopádovitých projektech).

Za třetí, předpoklady pro funkční agile jsou náročné na splnění

Když si vezmeme např. metodiku SCRUM, tak potřebujete dostatečně zkušený, samostatný, motivovaný a nepříliš velký tým, který je na projekt alokován na 100 % a sedí na jednom místě. Těžko říct, která z uvedených vlastností a podmínek je větší vzácnost.

Dále potřebujete „vlastníka produktu“, reprezentanta zákazníka projektu, který je s vámi schopen a ochoten hrát hru dle agilních pravidel – a to je také spíše výjimečné.

Co s tím tedy?

Zdá se, že pokud to lze, je lepší volbou řídit projekty agilně. A už i na rozsáhlé projekty existují promyšlené koncepty a metodiky, jako je LESS (Large Scale Scrum) nebo Spotify.

V mnohých organizacích však z různých důvodů prostě nelze splnit všechny předpoklady pro funkční SCRUM (nebo jinou metodiku) ve všech bodech. Ať už máme nekompatibilního sponzora, nebo je projekt příliš velký a máme příliš mnoho lidí v týmu, smlouva je striktní vodopád atd.

Zřejmě proto se v posledních letech (ehm… viz koncept z roku 1970 výše…) objevují nové koncepty hybridních přístupů, jako jsou iterativní vodopády, water-scrum-fall a další. Pěkně je na Konferenci PM ve Zlíně popsal Václav Oškrdal.

Nelze také pominout, že obecně iterativní přístup je dobře aplikovatelný i bez konkrétní metodiky, prostým rozfázováním projektu, kdy je podrobně plánována jen nejbližší fáze (což je koncept někdy z 80. let a říká se tomu rolling wave planning), což uplatňují např. i PMI PM BoK nebo PRINCE2.

Nebo se může projekt do určité úrovně WBS tvářit zcela „konvenčně“ a přitom pak mohou být některé výstupy a pracovní balíky doručené čistým SCRUMem.

Jde prostě o to, se zamyslet, co v daném kontextu a prostředí dává smysl, a pak to, nejlépe iterativně a se zpětnou vazbou, začít dělat. Agile každopádně nevyřeší to, že nejsme schopni správně formulovat cíle, určovat priority nebo se prostě mezi sebou normálně domluvit.