Na co je dobrý Agile a kdy použít Waterfall

Každou větší změnu se snažíme řídit projektově. Jestliže na začátku přesně víme, čeho chceme dosáhnout (postavit elektrárnu, optimalizovat proces, připravit raut pro 100 osob), dokážeme připravit plán složený z jednotlivých fází, kterého se držíme. Tomuto přístupu říkáme Waterfall – jednotlivé fáze na sebe navazují a výstup z jedné fáze přetéká do druhé. Jakmile máme ale pouze vizi, nevíme přesně, jak kroky naplánovat, zákazník si není jistý svými požadavky nebo se rychle mění trh, je lepší aplikovat agilní přístup.

Jak ve Waterfallu, tak v Agilu existuje celá řada konkrétních metodik a rámců, z nichž každý se hodí pro jiný účel. V tradičním (Waterfall) světě je příkladem metodika DMAIC, určená speciálně pro optimalizaci procesů, Prince2 nebo globální standard PMI (PMBOK), podle kterého lze řídit jak vesmírný program, tak komplexní firemní projekt. Základní princip Waterfallu ale zůstává stejný: sekvenční kroky od definice a analýzy přes návrh a realizaci až po vyzkoušení (pilot, testování) a nasazení do provozu. 

V agilním světě patří mezi nejznámější rámce Scrum a Kanban. Je jich ale mnohem více (XP, Scrumban, DSDM, FDD, ASD, …). Pokud na jednom produktu nebo službě pracuje ve firmě více týmů, běžný Scrum nestačí a je třeba používat tzv. škálované rámce jako např. Nexus, nebo LeSS.  Speciálním rámcem je SAFe, který slouží  k agilnímu řízení ve velkých korporacích, propojuje totiž strategii vedení firmy s prací jednotlivých agilních týmů. Někdo kopíruje i úspěšný Spotify model, minimálně jeho populární terminologii. Většina firem si agile principy přizpůsobuje svým potřebám tak, aby tým nebo týmy pracovaly maximálně efektivně.

Někdy nastává situace, kdy víme, čeho chceme konkrétně dosáhnout, ale nemůžeme celý projekt naplánovat předem, protože neznáme kroky. V takovém případě naplánujeme kus, potom jedeme chvilku agile přístupem, abychom zjistili, jaké další kroky budeme potřebovat, a když už to víme, můžeme opět rozpracovat plán pro dokončení projektu. Říká se tomu hybridní projektové řízení, které má ale dvě úskalí: Management musí vědět, že rozpočet a časový harmonogram se bude zpřesňovat až na základě zjištění informací z agilní části a projektový tým si musí zvyknout na to, že část projektu má pevné termíny, zatímco v jiné části se experimentuje. 

A někdy je to obráceně, když vyvýjíme /vymýšlíme něco, co se nedá snadno předělat nebo opravit po zjištění zpětné vazby od zákazníka, musíme tuto část projektu tvrdě rozplánovat předem, i přestože by se nám mohlo zdát, že nejlepší bude čstý agile přístup.