5 trendů z Agile Prague pro zlepšení vašich firemních procesů

Od té doby, co jsme v Socialbakers přešli na Scrum, se agilní rituály staly důležitou a oblíbenou součástí našich pracovních životů. Rozhodli jsme se proto vyrazit na konferenci Agile Prague jako jeden z hlavních partnerů, jednak abychom o sobě dali vědět, ale také samozřejmě kvůli získání inspirace.

Každý speaker měl trochu jiný pohled na věc, nicméně se nám podařilo rozpoznat 5 základních tezí, které se často opakovaly:

  1. Přestaňte zdůrazňovat individuální výkonnost
  2. Agile není metoda, ale kultura
  3. Udržujte produktové portfolio
  4. Zrušte story pointy
  5. Přestaňte řešit, jestli je lepší Scrum, XP, nebo Kanban

Uvádím tento seznam schválně na začátku článku, aby si z něj něco odnesli i netrpěliví TL;DR čtenáři. Pro ostatní je tu detailnější analýza jednotlivých témat.


1. Přestaňte zdůrazňovat individuální výkonnost

Snaha sledovat a odměňovat individuální výkonnost zaměstnanců je dnes ve firmách hluboce zakořeněná, aniž by bylo jednoznačně prokázáno, že vede k lepším pracovním výsledkům. Pokud totiž značná část odměn závisí na individuálním skóre, tak se většina lidí snaží toto skóre za každou cenu vylepšovat, což vede ke zvýšené rivalitě, zhoršení komunikace a zapojování různých obranných mechanismů na úkor otevřenosti a spolupráce.

Frustrující pracovní prostředí má potom zásadní vliv na chod celé firmy. Luis Goncalves toto ilustroval na úžasném příkladu z New United Motor Manufacturing. Tato automobilka byla považovaná za nejhorší světě. Denně nezvládlo dorazit do práce 20 % zaměstnanců a ti, co dorazili, se spíše než práci věnovali alkoholu, drogám a provádění drobných sabotáží. V takové situaci se zdálo, že je potřeba začít na zelené louce, zavřít továrnu a všechny vyhodit.

Nicméně po zavedení Toyota Production System mohli přijmout 85 % zaměstnanců zpět. Na vině nebyli jednotlivci, ale neefektivní a demotivující procesy.

Linda Rising
“Lidé mají vrozený sklon vytvářet si bariéry jak mezi jednotlivci, tak mezi skupinami.” Linda Rising nám připomněla, že jednotlivá oddělení ve firmách se k sobě navzájem často chovají s nedůvěrou, přecházející až v otevřené nepřátelství.

S těmito přirozenými sklony k nedůvěře toho nedokážeme příliš udělat, podle Paula Klippa se jedná o velmi starou evolučně vyvinutou funkci mozku. Jediné, co zřejmě pomáhá, je naučit se bez předsudků naslouchat druhým a určit si velký společný cíl, který pro nás bude životně důležitý a bude nás tím pádem motivovat spíše k týmové spolupráci než individuálnímu soutěžení.

Ve světle těchto informací se snaha o zavádění individuálních hodnotících systémů jeví jako absurdní. V Socialbakers jsme začali experimentovat se systémem hodnocení, který je téměř přesným protikladem individuálního skóre. Zaměstnanci totiž dostávají body za pomoc ostatním s jejich problémy. Odměna tak není závislá na individuálním výkonu, ale na ochotě spolupracovat a pomáhat ostatním. Podpora těchto vlastností snad povede nejenom k přátelštějšímu a harmoničtějšímu pracovnímu prostředí, ale nakonec i k vyšší produktivitě.

2. Agile není metoda, ale kultura

Dokument The Agile Manifesto byl sepsán už v roce 2001. Zavádění jeho principů do praxe je stále velká výzva, zvláště ve velkých firmách. Dobře to vystihl Bob Schatz na své přednášce Don’t DO agile!: “Pokud zavádíte do firmy nějaký nový proces, tak je potřeba vědět, proč to děláte. Pokud přecházíte na agile kvůli tomu, že to dělají všichni ostatní, nebo proto, že je to v módě, tak pravděpodobně pouze kopírujete vnější znaky a rituály a k žádné skutečné změně nedochází.”

Tomuto přístupu se říká loutkový agile a je nebezpečný v tom, že si zúčastnění myslí, že pracují v agilních týmech, i když ve skutečnosti zůstávají zajatci tradičních metodologií. Viz následující výroky managerů:

  • Agile? Samozřejmě! Máme denní meetingy.
  • Ano, děláme agile. Máme JIRA Agile.
  • Management říká, že máme dělat SCRUM.
  • Začali jsme dělat agile, pár lidí od nás už má certifikát.
  • Zrovna jsme ukončili naše development sprinty a předali to na QA oddělení.

Firma projde spoustou reorganizací, ale nikdy se nic nezmění. Díky, Claudio Perrone.

Claudio Perrone

Tuto problematiku (možná nechtěně) dobře ilustroval Peter Eeles z IBM, který na své přednášce jasně vymezil prostor, který u nich má Agile k dispozici uvnitř dobře namazaného soukolí iterativního waterfallu RUP. Samozřejmě neznám detaily, nemohu hodnotit, třeba jim to v IBM dobře funguje. Ale rozhodně bych s něčím podobným sám neexperimentoval.

Pokud zavádíte agile praktiky v development týmech, ale zbytek firmy zůstává tradiční, tak se nutně dostáváte do konfliktu.

Manažeři a obchodníci zavazují vývojáře k fixed time — fixed price kontraktům. Místo kreativního přístupu k problémům podporují poslušnost a detailní plánování, což vede v konečném důsledku k selhání celého experimentu a poškození dobrého jména agilního přístupu.

U nás jsme se nedávno zkusili zrušit roadmapy a deadliny. Vývojáři pracují vždy na těch featurách, které mají v tu chvíli největší prioritu, přičemž priority se můžou po každém sprintu měnit v závislosti na situaci na trhu potřebách zákazníků. Týmy musí po každém sprintu odprezentovat, jakou užitnou hodnotu se jim podařilo vytvořit, a tyto prezentace se natáčí na video a jsou pak k dispozici všem ke zhlédnutí. Tím jsou týmy motivovány k produktivitě (nikdo se nechce na prezentaci přiznat, že za 2 týdny nic neudělal), aniž bychom museli používat strašáka nesplnitelných termínů.

3. Udržujte produktové portfolio

Radikální inovace, zásadní změny a jiné disruptivní události v dnešní době přicházejí téměř s železnou pravidelností a odhadnout další směr vývoje často nedokážou ani špičkoví technologičtí vizionáři.

Vasco Duarte nás upozorňuje, že detailně promyšlený plán na několik let je v takovém prostředí neospravedlnitelný hazard. Ve chvíli, kdy adoptuje Agile, se samozřejmě detailního plánování vzdáváte. To ale neznamená, že byste se jako Product Owneři měli vzdát jakékoliv vize. Svůj produkt byste měli mít detailně promyšlený, přestože zatím nevíte, kdy se která část funkcionality bude implementovat.

Ideální je mít pro případ selhání současného směru několik záložních plánů, a umět včas přeřadit na “jinou kolej”.
Vasco Duarte

Předpokládáme hierarchické rozdělení vlastností produktu shora dolu na Epic — Feature — User story. Každý Epic se skládá z mnoha Features a každá Feature z několika User stories. Na úrovní Epic uvažuje management, na úrovni Feature product owner, architekti a UX. Na úrovni User story se pohybuje product owner a vývojáři.

Na každé z těchto úrovní může běžet agilní cyklus s různou délkou iterace. Máte rozepsané všechny možné Epics, které by váš produkt mohl podporovat, a u každého potom implementujete různě do hloubky, podle toho, jaká je vaše pozice na trhu.

Můžete mít rozpracovaných pouze pár Epics do značné hloubky (specializovaný produkt), nebo naopak velké množství Epics velmi povrchně (produkt pro široké použití, s důrazem na jednoduchost).

Pokud máte produkt detailně rozpracovaný na mnoha frontách, aniž byste se předem upsali k jediné možné variantě, tak jste na na nejlepší cestě k minimalizaci rizika v rychle se měnícím prostředí.

4. Zrušte story pointy

Story pointing je považován za nedílnou součást Scrumu. Základní stavební kameny této metodiky jako Velocity a Burndown chart by bez story pointů vůbec nedávaly smysl. Story pointing se navíc stal oblíbenou náplní plánovacích meetingů. Pomáhá odhadovat obtížnost jednotlivých user stories a je katalyzátorem diskusí o způsobech implementace.

Některé týmy toto odhadování dostali s použitím karet Planning Poker téměř na úroveň společenské hry. Proto se může zdát myšlenka na zrušení story pointingu (#NoEstimates), se kterou nás seznámil Vasco Duarte, jako nesmyslná a zbytečně radikální. Jak to ale bývá se spoustou radikálních myšlenek, je dobré ji nejprve řádně prozkoumat, než ji zavrhneme.

Jak jsem již zmiňoval výše: Pokud něco dělám, tak je důležité vědět proč to dělám a jaký z toho mám užitek. Základní argument proti story pointingu je založen na tom, že u většiny projektů se neprokázala jasná závislost mezi tím, na kolik SP byla user story obodovaná, a jak dlouho nakonec trvala implementace. Vasco nám ukazoval odstrašující grafy, na kterých se tento vztah jevil jako zcela náhodný. Samozřejmě u vašeho projektu to může být jinak. Každopádně si to zkuste změřit, možná budete překvapeni.

Pokud tato premisa platí, tak z ní vyplývají jeden závažný důsledek: Meetingy, na kterých se provádí story pointing, jsou ztráta času, který by šel využít lépe. Nebylo by místo odhadování velocity a následné snahy tuto metriku dodržet užitečnější prostě za daný čas odvést práci s co největší přidanou hodnotou pro zákazníka?

Navíc snaha vypočítat s pomocí velocity a daného scope datumu nasazení projektu jde svým způsobem proti myšlence iterativního vývoje tím, že fixujeme zároveň čas a feature scope. V některých týmech to řeší tak, že mají fixní týmy a pravidelné releasy, u kterých ale neplánují, co konkrétně se do nich dostane. Prostě se releasne to, co zrovna máme, protože přece agile je o tom, že na konci každé iterace máme funkční software.

Tolik tedy argumenty proti story pointingu. Co tedy máme dělat? Vasco tvrdí, že pracovat podle #NoEstimates je jednoduché:

  1. Vyberte nejdůležitější feature
  2. Rozeberte ji na rizikově-neutrální části
  3. Implementujte každou část
  4. Iterace a refaktoring

Já osobně zatím nevím, jestli mě to přesvědčilo. Story pointing se mi líbí a odhadnout předem složitost jednotlivých úkolů mi připadá užitečné. Nerad to říkám, ale tahle myšlenka je moc radikální i na mě. Každopádně ale zajímavý podnět k diskusi.

Andrea Provaglio, Peter Eeles, Claudio Perrone

5. Přestaňte řešit, jestli je lepší XP, Scrum, nebo Kanban

Touto myšlenkou nás ve svém talku o škálování agile přístupu překvapil Dean Leffingwell. Jsme zvyklí na to, že jakmile přijde nějaká nová metodika “do módy”, tak zahodíme všechno ostatní.

Byl jsem přítomen několika několika vzrušeným debatám na téma “Scrum je out, přejdeme na Kanban”. Přitom stavět tyto metodiky proti sobě je vlastně nesmyslné, protože každá z nich se zaměřuje na úplně jinou oblast problému.
  1. XP se zaměřuje správný způsob programování. Učí nás, že to nemáme přehánět s design dokumenty, ale používat unit testy a pair programming.
  2. Scrum je odlehčená metodika projektového řízení. Definuje základní týmové role, a umožňuje plánovat iterace.
  3. Kanban řeší samotný pracovní proces. Management poptávky, limitace work-in-progress, řízení flow.

Pokud vůbec existují oblasti, kde se tyto 3 metodiky překrývají, tak jenom velmi minimálně. Myslet si, že se jedná o tvrdě konkurenční přístupy, je typickou ukázkou škodlivého teritoriálního uvažování, o kterém byla řeč výše.

Navíc ve chvíli, kdy potřebujete Agile škálovat pro větší organizaci, je každá rada dobrá. Každá z těchto 3 metodik exceluje v jiné oblasti, tak proč je nespojit dohromady tak, abychom pokryly i ty problematické oblasti, které právě při škálování vyjdou najevo?

Scrum je metodika první volby. Když ale týmy vyrostou, a znásobí se množství práce, tak najednou zjišťujeme, že se trochu ztrácíme v obrovském množství in progress úkolů. Co uděláme? Použijeme Kanban! Rozdělíme si in progress práci na několik dalších stavů, a budeme limitovat maimální počet tasků v každém z nich. A to, že Kanban neříká nic o iteracích a týmových rolích? Je to skutečně problém? Od čeho máme Scrum?

Nebo máme větší projekt, a trochu se nám akumuloval technický dluh. Kanban nebo Scrum nám s tím nepomůže, ale můžeme použít XP! Napíšeme si unit testy, nejhorší částí kódu refaktorujeme, a na ty nejtěžší části, na které si nikdo sám netroufá, si sedneme ve dvou (pair programming). A že to není skutečné XP? Protože v XP musíme párovat VŽDY?

Jde především o to, abychom se zbavili jednostranného omezujícího myšlení, přestali zbytečně škatulkovat a z dostupných metodik si vybrali to, co nám funguje. Žádné rozhodnutí se přitom nemusí tesat do kamene. Jak navrhuje Claudio Perrone, změny svého workflow můžete provádět jako řízené experimenty. Máte pak svobodu experiment bez problémů zrušit, kdyby se neosvědčil, a kromě toho narazíte na mnohem menší odpor při jeho zavádění. Experimentujte!

Jak jsme se zapojili?

Případová studie

Náš product owner Radek Míka prezentoval case study o zavedení Scrumu a škálování na 100+ developerů podle modelu Spotify Agile Squads.

Zábava na coffee breaku

Pro účastníky konference jsme si také připravili meme workshop a logické hádanky. Memy na této konferenci moc netáhly, a tak jsme si jich asi polovinu nakonec vyplnili sami. Není nad to se zasmát vlastnímu vtipu.

Zato logické úlohy slavily nečekaný úspěch. Účastníci nám je zcela rozebrali, a museli jsme dotisknout další. Pro speakery a zahraniční hosty jsme připravili ještě verzi v angličtině.

Zvláště druhý den propukla luštící mánie naplno a některé z našich hádanek vyvolávaly vášnivé diskuze. Dokonce se k nám dostaly celkem 4 unikátní řešení jedné úlohy, kterou jsme považovali za neřešitelnou bez použití hrubé síly a značného výpočetního výkonu.

Celkově naši účast na konferenci hodnotím jako velmi úspěšnou. Nabrali jsme se spoustu nových inspirativních poznatků a snad jsme udělali dobrý dojem na ostatní účastníky. Aktivity na našem stánku si všichni pochvalovali, prý jsme překonali i Microsoft s jejich 3D tiskárnou. Děkujeme všem, a těšíme se na další ročník!

P.S.

Chcete poznat náš přístup k Agile na vlastní kůži? Máte možnost. Sháníme nové kolegy.