Temný SCRUM a co s ním?

Co je Temný SCRUM? Je to jev, se kterým se stále častěji setkáváme během našich angažmá v různých firmách nebo při diskuzích na našich kurzech. V anglicky mluvících zemích tomu říkají „Dark SCRUM“, temný SCRUM nebo také technický SCRUM. Tyto projevy vedou velmi často k selhání pokusu o agilní přístup a k následnému odporu k čemukoliv, co začíná slovem agilní. O co vlastně jde a jak zůstat na světlé straně SCRUMu?

Temný SCRUM

Ve zkratce jde o chybné pochopení agilního přístupu a SCRUMU jako takového. Tradiční přístup k řízení projektů a souvisejících aktivit v silně korporátním uvažování zaměřuje svou pozornost na věci jako:

• Procesy,
• Nástroje,
• Dodávky,
• Odhady,
• Jednotlivce,
• Bonusy,
• Individuální výkonnostní KPI atd.

Představme si, že s tímto způsobem uvažování („mindsetem“) začneme implementovat (!) agile… ovšem beze změny stylu myšlení a stále s orientací na individuální výkonnost, konkrétní dodávky v jasně odhadnutém čase apod. Prostě jen jiný způsob, jak dodávat, vyrábět. A máme temný SCRUM!

Projevy temného SCRUMu

Obvykle ne všechny najednou, ale často se pak (v lehké nadsázce) vyskytují situace a stavy jako:

• Předepíšeme lidem, že musí dodávat ve sprintech. Že musí být na daily SCRUM meetingu. A že tento konkrétní rozsah (tato WBS) musí být tímto způsobem dodán za 4 měsíce v předepsané podobě s danými akceptačními kritérii.
• Když ne, nebudou výroční odměny, o kterých se nesmí moc mluvit, protože jejich výše je individuální a strašně tajná… aby si lidi případně nezáviděli nebo nechtěli víc. (Stejně se to ví, protože u nás se tak jako tak vše rozkecá… nebo alespoň domyslí a odvodí 😉 .)
• Na review nechodí nikdo z přímých uživatelů, protože je to:
  • nezajímá,
  • nemají čas,
  • je to přílišn často,
  • nevědí, proč by tam měli být,
  • vše se přeci vyřešilo při zadání,
  • oni do toho přece nemají co mluvit a nikdo je nepozval.
• Nelze se jim ani divit, protože tým „demonstruje“ na review věci jako konverze DB z verze 3.2 na 3.21 nebo vytvořenou knihovnu onicem.dll apod. – které pro uživatele jednak zní jako kantonština, jednak pro ně nemají žádnou hodnotu.
• Tým si tedy dělá review de facto sám pro sebe nebo případně pro člověka, ketrému se nově říká Product Owner, kterého celý sprint neviděli a který jen shromažďuje požadavky z nejrůznějších stran a posílá je bez větších úprav týmu.
• Nebo je review vlastně jen jinak nazvaný kontrolní den, na který se přijde vyšší management podívat, jak jednotlivé produkty postupují.
• Tým skutečného zákazníka nikdy neviděl, protože management se děsí představy, že by zákazník viděl tu bandu hipíků. Nebo snad že by měli i mluvit! Na review tedy chodí obchodník nebo manažer projektu nebo jiný zprostředkovatel myšlení zákazníka (prý i existuje a viděl ho!).
• Některé položky dané WBS jsou velké, takže je natáhneme na víc sprintů a doneseme de facto gantt chart, kdy co bude.
• Managementu přijde neekonomické, aby měl každý nový tým svého SCRUM mastera. Tak vymyslí řekněme jednoho agilního kouče pro 15 týmů. JO! To je okamžitá úspora na nákladech a to se počítá! Za to budou bonusy!
• atd.

Všichni jsou od teď agilní…

Zajímavě také působí situace, kdy vrcholové vedení prohlásí firmu za agilně řízenou, což doprovodí razantní změnou organziační kultury a přivedením agilních koučů, kteří dohlíží, jestli se pracovníci chovají dostatečně agilně. Takže pracovníci pak lepí lístečky na to-do board a dělají ostatní události scrumu. A vedle toho pracují na daných věcech tak, jak jsou x let zvyklí a celý scrum je jedno velké absurdní divadlo.

Výsledky…

Je asi celkem zřejmé, že něco takového prostě nemůže fungovat dobře. A také nefunguje. SCRUM je totiž přímo založen na sebeorganizovaném, kompetentním týmu, který získává co nejčastěji a co nejvíc napřímo zpětnou vazbu od zákazníka a upravuje tak ve spolupráci s Product Ownerem svůj další postup – co možná nejvíce transparetně, formou sprintů. Výše uvedené přístupy jsou v prudkém rozporu s těmito základními SCRUM principy. Takže jednoznačné doporučení je v takovém prostředí vůbec SCRUM nezkoušet. Dokud se nezmění uvažování či pochopení, na čem je vlastně SCRUM založen.

Co na temný SCRUM koncept Shu-ha-ri?

Je to vlastně i nerespektování postupu, jak si něco dobře osvojit. Japonci na to mají svůj koncept Shu-ha-ri:

SHU

Následuj pravidla

• Začátečnický stupeň. Drill, který vyžaduje držet se pravidel a neměnit je. Cílem je provádět úkony správně a v plné kvalitě.
• Nevymýšlejte odchylky, úpravy nebo proč to nejde.
• Může se jednat o měsíce i roky, dokud vám prostě „základní formy“ nepřejdou do krve. Je to spousta práce vyžadující trpělivost.
• Např. dodržujte základní pravidla pro stand-up meeting – max. 15 minut, pouze tři základní otázky: Co bylo uděláno včera, co chci dělat dnes, co mne blokuje.

HA

Porušuj pravidla

• Základy již máte, lze tedy začít experimentovat, inovovat. Stále se však primárně držíte základního rámce.
• Např. přidáte na stand-upu čtvrtou část: „Hodila by se mi pomoc s tím a tím.“ Zatímco část „co mám hotovo“ už neřešíte, protože to na SCRUM boardu každý vidí.

RI

Buď pravidlem

• Mistrovský stupeň (master – tedy i Scrum master).
• Vytváříte své vlastní, třeba i zcela nové formy. Učíte se na základě vlastní praxe a zkušenosti.
• Např. změníte stand-up na volnou diskuzi, která však už v této fázi efektivní, koncentrovaná a zcela věcná (pokud byste se do toho pustili s týmem ve fázi Shu, bude to jen chaotický meeting bez valných výsledků).

Ani nemusíme chodit do Japonska… u tady v Evropě dlouhodobě fungoval model učeň, tovaryš, mistr řemesla… a je to vlastně to samé.

Pokud se tedy bavíme o agilu a je pro nás nový, je zkrátka vhodné následnovat SCRUM guide tak, jak je napsán. Jsme učni… naučme se tedy základy spávně a experimentujme s nimi až poté. Začít dělat SCRUM a hned z něj něco vyházet a začít dělat jinak, protože „se nám to nehodí/nelíbí“ je často cestou do … pekla a výsledkem je temný SCRUM.

A co je to tedy jiný než temný SCRUM?

SCRUM jako takový, jako rámec, vytváří určité mantinely, hranice, pro sebeorganizované týmy (kompetentních) lidí. Krom několika klíčových událostí (Sprint planning apod.) vlastně vůbec nepředepisuje žádné konkrétní techniky, metody apod.

Nikde není konkrétně uvedeno, jak má přesně vypadat Product Backlog, jestli a jaký má být SCRUM board. Jsou uvedeny vlastně jen ty mantinely a pak principy, které je třeba respektovat (transparentnost, kontrola, přizpůsobení se). Je popsána filosofie, při které se snažíme co nejdříve vyprodukovat kus hodnoty pro zákazníka a co nejdříve na ni dostat zpětnou vazbu. A podle toho se přizpůsobit.

Konkrétní postup, jak toho dosáhnout, které techniky a jak použít, to už si nastavuje sám tým. Proto je mimochodem v tomto kontextu dost nesmyslné „impelemntovat model X nebo Y“. Ty popsané postupy vzniky v určitém kontextu, složení lidí a po mnoha iteracích, kdy si ti lidé prostřednictvím retrospektiv ten postup měnili (a měnili i sami sebe, svůj postoj, svou kulturu). A budou měnit dál. Aplikovat jejich způsob na vás, bez toho, že byste měli za sebou obdobnou cestu, nejspíše selže. Vy jste o tom už padesátkrát nediskutovali, nenabili si ústa, nezměnili jste se… I jeden z autorů agilního manifestu s oblibou tvrdí, že: „Nejlepší způsob, jak začít dělat SCRUM, je po svém.“ Což neznamená, že se nemůžete inspirovat. Ovšem copy+paste přístup není zřejmě nejlepší nápad.

Vítáme změny i v pokročilé fázi vývoje…

…protože cílem není dodat původně popsanou funkcionalitu, ale co největší hodnotu pro zákazníka.

Místo individuálních KPI se zaměřujeme na výkonnost týmu jako celku (měřeno dodanou hodnotou pro zákazníka). Jednotliví členové nejsou z tohoto úhlu pohledu zajímavými. To až všichni členové a vazby mezi nimi, vytvářející komplexní sociální systém označovaný jako tým. A chápeme, že je potřeba někoho, kdo pomůže týmu být efektivním – SCRUM Mastera (pokud si to chcete vyzkoušet, můžete navštívit náš trénink, kde simulujeme agilní projekt).

Projekt z našeho Agile a SCRUM tréninku

Je zřejmé, že jen „mindset“ sám o sobě stačit nebude, ale je to základ, bez kterého to prostě nejde. Jak by na vás asi koukali obyvatelé Prahy z dob Karla IV., kdybyste jim vykládali o parlamentu a demokracii? Ti lidé vůbec nepochopí, co se jim snažíte říct. Oni ty iterace za sebou ještě nemají… Nějaká „implementace“ velkým třeskem by nejspíše velmi bolela a možná nedopadla úplně dobře (francouzi o tom vědí své). Ale lze začít ty věci vysvětlovat. Snažit se nacházet záblesky pochopení a pomalými krůčky na tom stavět dál.

Je dobré také si uvědomit, že Agile, potažmo SCRUM není cílem… ale prostředkem. Cestou. Např. ke spokojenějším zákazníkům, kvalitnějšímu produktu a motivovanějšímu týmu.

Faktem je, že všude to hned nejde…

Začít dělat věci agilním způsobem, potažmo SCRUMem má i své problémy a body k řešení. Nelze jej nasadit hned všude, vždy a za všech okolností. A temný scrum zkrátka nefunguje ;).

Nejprve je vhodné mít nějaké vhodné produkty či projekty… stavět most o délce 1 km pomocí SCRUMu asi moc smysl nedává… (více se tímto zabýváme v článku o vhodnosti agilního přístupu).

Dále, poměrně často je vytýkáno agilnímu manifestu, že není zcela jasně a zřetelně uvedeno, že fungující SCRUM vyžaduje poměrně kompetentní lidi. Tedy lidi, kteří mají schopnosti (skills) a určitou disciplínu. Nemůžeme chtít od lidí kteří neumí a/nebo nechtějí, aby ze dne na den vytvořili efektivní sebeorganizovaný tým… musíme je nejprve naučit dovednosti na potřebné úrovni a také základní míře disciplíny a zodpovědnosti. Což je opět zodpovědnost „liniového“ managementu, aby to zařídil (a pro linii tedy stále zbývá poměrně dost práce 😉 ). Jak budovat sebeorganizované týmy řešíme mimochodem i na tréninku Projektový management 3.0., který (mimo jiné) vychází z tezí Jurgena Appela a jeho knihy Management 3.0.

Prostředí samo může být také velký klacek pod nohama. Pokud máte asi tak devadesát paralelně běžících systémů, které si nejrůznějšími datovými pumpami a udělátky předávají data a něco z toho běží už 20 let a nikdo už ani neví, jak to je vlastně udělané nebo rozumí jazyku, ve kterém je to napsáno, budete jen velmi obtížně dodávat kusy hodnoty pro zákazníka v krátkých sprintech. Tam, kde to chtěli umožnit např. několik let vše přepisovali do nových verzí, které již svou architekturou takový způsob umožňují…

Jak tedy?

Vždy se ale dá nějak začít. Prvků a postupů je mnoho. Jako příklad některých snadno aplikovatelných mohou být např.:

Sebeorganziace

Např. postupně se zvyšující mírou sebeorganziace týmů, kdy jim delegujete více a více zodpovědnosti a rozhodování (nemusíte hned začínat rozhodnutími o architektuře systému samozřejmně). Ale naučte je, že o něčem budou rozhodovat i sami. Hodně tomu pomůže, když jim budete schopni popsat svou vizi, cíl, směr, kam se jde. Aby se dokázali rozhodovat i z perspektiv jako krátkodobý prospěch či dlouhodobý užitek. Co lépe pomůže naplnění vaší vize produktu/firmy/… ?

Retrospektiva

Dalším velmi mocným zaklínadlem je dobře provedená retrospektiva. Která má velmi dobré výsledky i v neagilních projektech a týmech. Vždy je dobré se umět zastavit a zamyslet se s určitým odstupem nad tím JAK věci děláme a ne jen CO děláme.

Transparentnost

Vyšší transparentnost, např. nějakou formou KANBANU (což je japonské slovo pro tabuli, takže bychom mohli psát tabuli… ovšem Kanban zní mnohem sofistikovaněji ;)) a zobrazení toku práce formou lístěčků, ať už fyzických nebo virtuálních. A zastropování množství rozdělané práce, což je vlastně ten hlavní princip této slavné metody. Opět neomezené na agile či sw vývoj samozřejmě (vždyť ten postup pochází z automobilky, z výroby…!).

Postupujme s otevřenou myslí a nebojme se mírně experimentovat. Agile je jednou z možných cest k naplnění vašich cílů. Přejeme vám nepřiliš bolestivé první kroky.

Pozn.: Článek byl poprvé vydán 28.6.2019 a aktualizován 21.7.2020.