Než začnete diskutovat na téma, že nástroje jsou přece užitečné, podívejte se kolem sebe. Kolikrát jste slyšeli, že ten a ten systém je špatný? Že vám nedává to, co byste chtěli? Že musíte používat jeden a raději byste měli druhý? Že nemůžete věci dělat jinak, protože váš nástroj to neumožňuje? A čím větší je firma, tím více procesů a nástrojů vygenerovala. O procesech jsem psala minule, takže těm se pro tentokrát vyhnu. Vzpomínáte si na Agilní manifest? Hned první princip říká “Upřednostňujeme lidi a jejich vztahy před procesy a nástroji”. A přesně v tomto kontextu je to potřeba vnímat. Opravdu upřednostňujete to, co vaše týmy potřebují, před tím, co zrovna musíte používat za nástroj? Viděla jsem spoustu týmů, které implementovali Agile a Scrum tak, že začali hledat nástroj… Nástroj, který jim pomůže být agilní a Scrum nasadit. Ale to není zrovna agilní přístup, že?
Najdete různé pěkné nástroje, které umí mračna zajímavých věcí. A tak týmy, ve snaze využít maximum možností, dělají milióny věcí, které jim nic nepřinášejí a k opravdovému cíli – tedy společně dodat hodnotu pro zákazníka efektivně, rychle a kvalitně – nás nikterak neposouvá. Ba právě naopak. Jsme pak často pomalejší, Scrum se stává divnou byrokracií bez obsahu, a jako takový nepřináší vyšší zapojení jednotlivců, nadšení, ani žádné inovace, ale jen “my teď musíme… “, “my nemůžeme…”, a nebo “my pořád schůzujeme a vyplňujeme”…
Příkladem toho, o čem mluvím, může být třeba ohodnocování tásků hodinami. Výborná praktika, která žere neskutečně času týmu a jediným důvodem pro její vykonávání je to, že náš nástroj pak umí kreslit burndown graf za Sprint… Který však, podíváme-li se na něj čistýma očima, nepřináší nic, co bychom už dávno nevěděli z dobré tabule a funkčních standupů. Sprint burndown je naprostá zbytečnost, která se v agilní komunitě ujala právě proto, že týmy viděly další pěknou věc, kterou jejich nástroj umožňuje, tak proč ji nezkusit, že?
Dalším příkladem jsou různé nástroje, které umožňují vidět tabuli online. A teď ani tak nemluvím o geograficky distribuovaných týmech, ale o lidech, kteří sedí v jedné budově či dokonce místnosti… Na začátku za tím stojí dobrý nápad, my budeme naši tabuli vidět odkudkoliv, nemusíme vstávat, abychom tam udělali změnu… Ale není to náhodou přesně to, čeho se chceme vyvarovat? Co chceme agilním přístupem změnit? Vždyť my přece chceme, aby se tým potkával a povídal si, aby každý mohl vzít tužku a lísteček a hned napsat, co se musí ještě udělat, a když se něco změní, tak prostě lísteček vzít a zahodit, jako by ani neexistoval. Nepotřebujeme historii tásků popsanou do posledního detailu. Nepotřebujeme evidenci všech změn a nápadů, které jsme kdy měli… Chceme si jen být jisti, že jako tým ještě stihneme dokončit všechny User Stories které jsme zákazníkovi slíbili. A nechceme žádnou zbytečnou byrokracii. Zkuste si napsat task na lepítko anebo zadat do systému. První varianta je mnohonásobně kratší a všichni její výsledek vidí kdykoli vzhlédnou nebo jdou kolem na kafe, aniž by museli spustit systém a dát refresh.
A když volně přejdeme k dalšímu přikladu, chceme se flexibilně organizovat… Není tedy cílem vzít User Stories a na začátku Sprintu je přiřadit jednotlivým lidem. A mentálně je za ně udělat zodpovědnými. Tým by měl být za jejich dodání zodpovědný jako celek, ale když se řídíme nástrojem, tak to často nejde. Ano, některé týmy User Stories přiřadí Scrum Masterovi aby nástroji něco předhodili. Ale většina takových řešení funguje psychologicky na backgroundu a ovlivňuje – aniž byste si to uvědomovali – vaše chování. A to i ve věcech, kde byste se hádali do krve, že vás to přeci neovlivní. Že nevěříte? Dělaly se například studie s velkou skupinou lidí. První skupina dostala otázku “Kolik obyvatel má stát Texas?”. Když z odpovědí celé skupiny uděláte průměr, dostanete nějaké číslo. Druhá skupina dostala velmi podobnou otázku – “Kolik obyvatel má stát Texas, je to více než 500 tisíc?” a překvapivě odpovědi byly výrazně bližší číslu 500 tisíc. Experiment se v různých podobách opakoval mnohokrát a pokaždé se stejným výsledkem. Říká se tomu kotvení. A zpět k příkladu s nástrojem, který vás nutí User Story assignovat konkrétnímu členovi týmu. V momentě, kdy to uděláte, zakotvíte zodpovědnost z týmu jako celku k nějakému konkrétnímu členu týmu. A stejně jako u výše zmíněné otázky na obyvatele Texasu, na pozadí to ovlivní chování týmu. Aniž byste si to uvědomili. Je to psychologie chování lidí.
Scrum překvapivě drží pohromadě právě na tom, že jednotlivé praktiky různým způsobem podporují nebo naopak omezují jisté stereotypy chování lidí. Scrum je postaven na psychologii. Bez ní je to jen technický proces, který v praxi pouze vzbudí ohromná očekávání ale výsledek se nikdy nedostaví. Nástroje jsou fajn, ale bez toho, aniž rozumíte psychologii na pozadí Scrum procesu, bez toho aniž byste pochopili Scrum DNA, jsou většinou kontraproduktivní a Scrum a Agile zabíjejí. Velice rychle a chytře. Jsou jak rakovina, která se usídlila v organizmu týmu nebo firmy. Po chvíli se vy přizpůsobujete nástrojům, ne naopak, a to je přesně ta chyba. Používejte nástroje, protože tu jsou od toho aby vám pomáhaly, ale v momentě kdy zjistíte, že něco děláte jen proto, že to nástroj umožňuje, nebo že naopak něco neděláte, jen proto, že to nástroj neumožňuje, zastavte se a zamyslete se kdo má koho pod kontrolou. Vy nástroj, nebo nástroj vás. A v prostředí, ve kterém lidi a týmy řídí nástroje, se lidem moc nedaří.
