Úvodem krátký exkurz do historie: Ve čtyřicátých letech minulého století se japonské fabriky značky Toyota začaly soustředit na eliminaci “muda” (odpadu, tedy čehokoliv, co nevytváří hodnotu pro zákazníka). Mezi pravidla patřilo například neodesílání defektních obrobků k dalšímu zpracování, výroba přesně takového množství, které je potřeba k dalšímu zpracování a komunikace skrze kanban (tabuli s úkoly).

Právě aktivní komunikace mezi zástupci jednotlivých částí výrobního procesu byla klíčová. Na této filosofii postavený “kaizen” (neustálé zlepšování se) začal dávat japonským továrnám větší a větší kompetitivní výhodu nad těmi americkými. A jak jste si už možná všimli, právě z této filosofie se vyvinul i současný agilní vývoj a SCRUM.

Zpátky do přítomnosti. Jak to se SCRUMem v realitě nejčastěji vypadá?
Chci říct, že si vážíme všech našich klientů bez ohledu na metodiku, kterou používají. Sami víme, jak je těžké opravdový agile zavést. Je nám jasné, že stakeholdeři jsou vždy ohraničení v rámci organizačních matic a změna takového charakteru vyžaduje i změnu celé firemní kultury. Následující řádky nejsou kritika, ale objektivní náhled, kterým chceme pomoci.

Vývojářské firmy agile často používají jako marketingové heslo, zatímco agilní metodiku pořádně používat nedokáží. Klienti ho vyžadují, protože je to moderní postup – a přitom mu častokrát do hloubky nerozumí. Je to podobné, jako když si zákazník kupuje fotoaparát a dívá se přitom jen na množství megapixelů – bez ohledu na typ snímače a další zásadní, komplikovanější parametry.

Pokud jde o samotné fungování, jeden z principů je “people first, not processes”. Ten ale klade o to větší nároky na odpovědnost a disciplínu všech zúčastněných. Stand-up meetingy, které mají být rychlé, stručné (co jsem dokončil; na čem dělám dnes; co jsou mé další kroky; brzdí-li mě něco, co to je a zda s tím potřebuji pomoci) a jsou klíčové pro postup projektu se často zvrhávají v klasické, unavující statusy. “Dáme to do backlogu” často znamená “zapomeneme na to”. Evidence backlogu dává smysl při pravidelné revizi priorit a smysluplném plánování včetně odhadu pracnosti. Product owners (klienti) nebývají zvyklí dostatečně aktivně spolupracovat.

Zkrátka – kanban vznikl v rámci dobře plánovaného výrobního procesu, kdy je každý zúčastněný schopný spolehlivě odevzdat bezchybnou část výsledného produktu a komunikovat se zbytkem týmu. A za takových podmínek i dobře funguje. Stejně jako SCRUM.

Tedy, stojí to za to? Ano, ale…

Je důležité, aby k sobě firma byla upřímná. Agile není univerzální řešení na všechny potíže. Pokud je problém s nekompetencí útvaru nebo zaměstnance a firma má strach ho vyhodit, agile to nevyřeší – ba naopak v takovém případě způsobí ještě větší zmatky. Často se využívá jako deklarace “vyřešení problému”, což nakonec působí jako náplast na mokvající ránu. Navíc, pokud budete hlásit, že tento systém využíváte, i když to není pravda, ztrácíte reputaci – zvlášť u zaměstnanců.
Na SCRUM je potřeba tým, ve kterém dlouhodobě funguje spolupráce s důvěrnými vztahy. Není to krizový management. Vedle Scrum Mastera je pro organizaci (zvláště u zakázkového vývoje) klíčový projekťák. A při zavedení musejí být všichni ztotožnění s principy a postupy. Nepředstírat rituály. Zkrátka, dělat to opravdově.