Press "Enter" to skip to content

Školení SCRUMu

Abychom náhodou něco nedělali blbě, dostali jsme školení. S konzultantem. Teda, konzultanti tam jsou nakonec tři a zdá se, že do toho vidí. To vypadá nadějně.

Školení v podstatě ani nezačalo a už na ně prší otázky, většinou typu „co vás vede k názoru že nám máte co říci“ a „jste vůbec kompetentní nám něco říkat?“. Připadá mi, že asi polovina kolegů celou dobu přemýšlí jen o tom, jak ten anarchistický nesmysl zlikvidovat. Protože je přeci jasné, že v korporaci něco takového jako agilní vývoj nemůže nikdy fungovat.

Vzhledem k tomu, že jsem ukecanej jak Palacký, se taky zapojuji do diskuse a vyjadřuju se optimisticky – přeci jen agilní vývoj v korporátu není nic nemožného ani nového. Navíc máme vyzkoušené v praxi, že to může v pohodě fungovat, přinejmenším pokud se to nikdo nesnaží příliš organizovat.

Ve skutečnosti ale tak trochu sdílím obavy mých kolegů:

  • korporát, to je samý specialista. Agilní vývoj potřebuje generalisty – praktické jedince s širokým rozhledem, co se nebojí improvizovat, komunikovat a udělají tu práci, kterou je třeba udělat.
  • když nefunguje dobře agilní vývoj v malé firmě, zkrachuje. Když nefunguje v korporaci, v lepším případě dostane někdo vynadáno, v horším si toho ani nikdo nevšimne. Chybí tu ten každodenní kontakt se syrovou realitou.
  • když vlastník není spokojen s týmem, zbaví se problematických jedinců, nebo celý tým vymění. Bojím se že tenhle ozdravný mechanismus v korporátu nebude fungovat.
  • pokud se managerům podaří prosadit jejich mechanické „procesní“ pojetí, skončíme někde u rituálních tanců. Na to fakt nejsem zvědav.

Obecný začátek OK, nicméně pak se dostavil náš „agilní manager“ a zase vykládá nesmysly. Jeden příklad za všechny:

Metodika SCRUM říká, že v každém sprintu tým doručí jednu nebo více „user stories“. Hned jsme si to ukázali na konkrétním příkladu, kde šlo o doručení prototypu obrazovky. To mě zarazilo, protože zadání typu „udělejte prototyp obrazovky“ je přesně to, na čem se ukazuje, jak SCRUM nedělat.

Nastalo divení, ale různé dezinformace vzniklé z nesprávného použití pojmů jsou běžné, tak jsem radši položil pár doplňujících otázek, aby se to vyjasnilo. Ukázalo se, že to není omyl, ani špatně zvolený příklad, ale že v celé naší „metodice“ je konzistentně nazýváno pojmem „user story“ cokoli, co se má doručit – ať už je to dokumentace, HTML šablona, wireframe, seznam požadavků nebo dokument architektury.

Zdá se mi že konzultanti asi chápou, v čem je problém, ale nezasahují. Buď na to nemají dost zkušeností a myslí si, že by to mohlo fungovat, spíš ale že usoudili, že se lépe poučíme, když si nejdřív nabijeme držku. Jarred Spool o tom napsal výborný článek: https://articles.uie.com/beans-and-noses/