Shodným jmenovatelem všech výše uvedených případů bylo nepochopení a nesprávná aplikace agilního přístupu. Jako žádný jiný nástroj ani agile za nás prostě nevyřeší všechny problémy, nebude za nás přemýšlet ani pracovat a není ani všemocným univerzálním nástrojem na všechno. A kdo si to ze začátku nadšeně myslel, samozřejmě záhy prohlédl.

Na druhou stranu je faktem, že určitá iterativnost v přístupu k přípravě a řízení projektů tu byla už před tím, než začal agilní boom. Agilní metody nejsou zas tak revoluční a jiné než klasičtější přístupy. Vzpomeňme třeba koncept „rolling wave plannig“ již někdy z osmdesátých let nebo spirálovité modely vývoje SW.

V každém případě je moderní agile poměrně přesně definovaným nástrojem, který se hodí do určitého prostředí a na určité typy projektů. To je veškerá složitost… A kdo to nepochopil a snažil se šroubovákem zatlouct skobu do betonové zdi, teď naříká, že to nefunguje. A má ve svém kontextu pravdu.

Významným faktem, který je potřeba vzít v potaz, jsou nezbytné předpoklady pro nasazení agilního přístupu, jako je dostatečně kompetentní zákazník, dostatečně kompetentní tým a vhodný projekt. Tedy takový projekt, který nemá jasný výstup a nelze jej dopředu přesně specifikovat. Pokud by to možné bylo, je vhodnější klasický projektový management. Pokud to tak ale není, klasika poněkud selhává, protože o kvalitní schopnosti činit časové, zdrojové a další odhady nad něčím, co nejsem schopen dostatečně přesně popsat, lze s úspěchem pochybovat.

V některých případech, jako jsou některé případy implementace IS, vývoj nového produktu, tvorba nového webu apod., je pak situace skutečně taková, že má smysl postupovat čistě agilním přístupem – tedy s respektem ke všem pravidlům vybrané metody, která to obnáší. Nelze si brát jen něco. To by bylo jako psát diktát, ale vykašlat se na vyjmenovaná slova. O ryze agilním přístupu je toho napsáno již mnoho, věnujme se raději určité oblasti na pomezí. Lze použít agilní prvky i mimo vývoj SW nebo vývoj jako takový? Co v případě investičních akcí a dalších „konvenčních“ projektů?

Dobrou zprávou snad je, že ano. Respektive, že se dají agilní a klasické přístupy vhodně kombinovat i na jednom jediném projektu. Mám dva krásné příklady z poslední doby.

Jedna firma rekonstruovala svou hlavní administrativní budovu a člověk, který to měl na starosti, všechny vyzval, aby mu zaslali své požadavky na prostorové uspořádání. A pochopitelně, nestalo se nic. Takže na to musel jinak. Dal si s tím nějakou práci a následně všechny obeslal s návrhem budoucího prostorového uspořádání. A najednou se strhla lavina připomínek, že takhle ne, že tohle musí být jinde atd. Věci se daly do pohybu, a když proběhly asi čtyři iterace, měl dotyčný v ruce takové uspořádání, které více méně vyhovovalo všem a zároveň s ním byli všichni ztotožněni, neboť byli součástí tvůrčího procesu.

Nebyl to samozřejmě SCRUM nebo jiná konkrétní metoda určená primárně pro vývoj SW, ale byl vystižen princip agilního přístupu. Následná rekonstrukce pak už byla plánována a řízena klasickým způsobem.

Obdobný příklad nastal u jiného našeho zákazníka, který se zabývá výrobou a rekonstrukcemi lokomotiv. Bylo potřeba předělat postarší elektrickou lokomotivu na moderní standardy a tři různé systémy napájení používané u nás a v okolních zemích. Opět se jako jedinou smysluplnou cestou vedoucí k výsledku ukázalo pracovat v koncepčně-návrhové fázi v iteracích a následné prezentaci a diskuzi se zákazníkem.

Mám za to, že výše popsaná kombinace agilního přístupu v návrhové fázi a klasického ve fázi realizace může být velmi užitečným konceptem pro velkou řadu projektů. Přemýšlejte nad tím.

Ing. Jan Doležal, Ph.D. Autor článku je ředitelem společnosti PM Consulting s.r.o.