Category Archives: Agile

Svoboda v práci a agilní přístup

Pokud kolem lidí postavíte plot, začnou se chovat jako ovce.

Četl jsem knihu Freedom Inc. (česky Svoboda v práci) a při čtení mi došla spousta věcí. Knize samotné se budu věnovat jen okrajově, mám z ní smíšené pocity. První půlka byla super, druhou jsem jednoduše nezdolal.

Celá kniha se točí kolem toho, že jsou dva druhy firem. „Proč“ a „Jak“. Na jedné straně jsou tradiční společnosti, které lidem říkají jak mají pracovat. Dávají jim přesně vymezené úkoly, měří je metrikami, sešněrovávají nařízeními, motivují je odměnami a tresty, mají jasný řídící proces. Zkrátka klasika. Pak je druhý typ firem. V těch se lidem neříká co a jak mají dělat, ale ptají se jich proč dělají to co dělají. V prvním typu je důležitá hierarchie a procesy v druhém kultura a sdílená vize.

Podle autorů je druhý typ firem výrazně lepší v podstatě ve všech ohledech. Lidé jsou motivovanější, víc o věcech přemýšlejí, jsou iniciativní, neztrácí čas a energii zbytečnou byrokracií. Zkrátka a jednoduše se snaží naplňovat společný cíl. Společnosti prvního typu iniciativu a snahu jednotlivců spíš ubíjí procesy a pokusy o zaškatulkování.

Došlo mi, že to vysvětluje proč tolik firem selže při závádění agilního vývoje. Jsou to společnosti typu „Jak“. Když kouknete na agilní manifest, tak to z toho úplně číší. V klasické „Jak“ firmě nemůžete upřednostňovat jednotlivce před procesy, tyto firmy jsou na procesech stavěné. Nemůžete reagovat na změnu, plán je posvátná kráva. Nemůžete mít samoorganizující se týmy, co by pak dělali jejich manažeři a manažeři manažerů a jejich manažeři?

No jo, ale jak řídit firmu bez vyhlášek, procesů, hierarchie, pololetního hodnocení zaměstnanců a motivačních vstupenek do kina zdarma. To by přeci zavládla anarchie. Zaměstnanci by se celý den flákali, každé oddělení by si dělalo co chce, firma by se zmítala ve vlnách, nikam by se nerozvíjela a za chvíli by zkrachovala.

Máte pravdu, aby k tomu nedošlo, potřebujete dvě věci. Kulturu a vizi. Lidé ve firmě musí mít sdílenou kulturu a vizi, musí se shodnout na tom, kam má firma směřovat, jaké jsou její priority. Musí vědět jaký je jejich společný pohled na to co dělají, v čem chtějí být dobří, jak se k sobě chtějí chovat, jak chtějí řešit problémy, co je to něco, co je spojuje. Nejen že je těžké to uchopit a nadefinovat, ještě těžší je zařídit aby tomu lidé věřili, aby to přijali za své. Spousta z nich už zažila nepodařené a často neupřímné pokusy o něco podobného.

V jedné nejmenované korporaci jsem například zažil, jak kdosi vymyslel vizi celé firmy. Slavnostně nám to odprezentovali. Abychom to přijali za své, tak najali telefonistky, které nám telefonovaly a zkoušeli nás. Kdo správně odrecitovali firemní hodnoty, dostal dáreček. Hurá. Samozřejmě si z toho všichni dělali srandu a nic se nezměnilo. Bylo jen takové plácnutí do vody.

Vůdce nemůže donutit lidi přijmou firemní vizi, může se jen snažit navodit podmínky, při kterých se lidé přesvědčí sami.

Takže zpátky k agilitě. Známe přísloví říká „agile nemůžete dělat, agilní musíte být“. Agile nejde zavádět tak, že lidem přikážete, že mají mít ranní pětiminutovku, že musí mít nástěnku, že musí posouvat lístečky ve vámi určeném směru. Pokud k tomu budete přistupovat takto, tak pokus o zavedení agile skončí jako další z desítek nařízení, které ti lidé budou buď bezduše vykonávat nebo prostě ignorovat.

Bohužel se na to musí jít tou těžší cestou. Nejdříve je potřeba se shodnout na tom, proč to chceme dělat, co je naším cílem. Je nutné vědět, jaká je vize firmy, týmu, projektu nebo iterace. Pokud máme jasno ve vizi a lidé ji přijmou za svou, je nutné dát lidem svobodu tuto vizi naplňovat. Mluvím o skutečné svobodě, ne jen deklarované. Můžete tvrdit lidem, že mají svobodu, ale pokud zároveň musí plnit hromadu nařízení, u který není jasný důvod, tak to dobře nedopadne. Ano je mnohem snazší vydat nařízení, než se s lidmi bavit a hledat nejlepší řešení. Pak se ale nesmíte divit, že se budou chovat jako ovce.

Je jen na vás jestli chcete mít sebevědomé, iniciativní, snaživé a motivované pracovníky nebo poloautomaty, jejichž veškerou snahu a iniciativu sežere boj s korporací. Rozdíl je jen ve vizi a kultuře.

Lean from the Trenches

Dostala se mi do rukou skvělá knížka, Lean from the Trenches (Hubeňouři ze zákopů) od Henrika Kniberga (tady se dá stáhnout draft)

Hlavní důvod, proč mi přišla tak dobrá je, že tam řeší stejné problémy, jaké máme aktuálně my. Od plánování, přes implementaci, až po testování. Celá knížka je vlastně popis toho, jak dělali projekt pro švédskou policii trvající něco přes rok a čítající asi šedesát lidí. Používali mix Kanbanu, Scrumu, Leanu a kdovíčeho ještě. Což je nakonec jedno, protože jak píše,

.. občas týmy dělají Kanban, protože se jim nelíbil Scrum. Až později přijdou na to, že Scrum problémy nezpůsoboval, ale upozorňoval na ně.

Nástěnka

Velká část knihy se točí kolem jejich Kanban nástěnky. Abych zase ocitoval

Rychlost projektu je z velké části určena tím, jestli všichni vědí co se děje. Když všichni vědí, kde právě jsme a kam jdeme, je pro ně mnohem snazší jít stejným směrem.

Dokonce má celou kapitolu o tom, proč používají fyzickou nástěnku místo elektronické. Hlavní důvod je snadná měnitelnost. Je mnohem snazší ji rozvíjet a upravovat. Když něco chybí, tak se to dopíše. Něco je špatně, vezmu fixu a překreslím to. Není potřeba trávit hodiny klikáním v Jiře. Stačí vzít tužku a z pár minut je hotovo.

U všech svých klientů jsem si všiml jednoho vzoru – obdobné nástěnky mohou změnit organizační kulturu. … Viděl jsem, jak se změnily vzájemné vazby a jak se díky spolupráci u nástěnky zvýšila důvěra mezi týmy.

Metriky

Také mě zaujaly metriky, které používají. Jsou to

  1. Počet věcí (featur) dodaných za týden
  2. Čas, za který proleze featura celým procesem

Je dobré si všimnout, že neměří komplexitu. Takže jim je jedno jestli udělají deset velkých nebo malých věcí. Prý je to proto, že se to nakonec stejně vykrátí. Odhady složitosti jsou nepřesné a metriku zkreslují. Počet je podle něj stejně vypovídající, ale mnohem jednodušší. Navíc je to tlačí do malých kousků, což je taky jenom dobře.

Druhá metrika je také zajímavá. Mají ji hlavně proto, aby je nutila zkracovat fronty mezi jednotlivými fázemi. Příliš velký čas vás upozorní třeba na to, že věci zbytečně čekají na otestování. Když se snažíte celkový čas zkracovat, musíte tato úzká hrdla řešit a to celému procesu jen prospěje.

Náš proces nebyl navrhnut, ale objeven.

Diagramy příčiny a důsledku

Úplnou novinku pro mě byly diagramy příčin a důsledků. Řešíte třeba dlouhé release cykly. Doporučuje nakreslit si diagram. Začnete u toho, že máte dlouhé release cykly. Nad to píšete jaké to má dopady, a pod to jaké jsou důvody. Často tam vyběhnou začarované kruhy, jako třeba tady.

Cause-effect diagram

Doporučuje se samozřejmě zaměřit na kořeny toho problému. Když vyřešíte příčinu, je možné, že vyřešíte i problém. Začarovaný kruh se rozpadne. V tomto konkrétním případě je dobré vyhazovat požadavky, pokud se nějaké jiné do releasu přidají. Více se dočtete tady.

Ostatní

Pak tam má také spoustu zajímavých věcí o retrospektivách, neustálém zlepšování, pokrytí testy a dalších. Takže pokud válčíte s agilním procesem, tuto knížku vřele doporučuji. Je docela krátká, ale nacpaná praktickými radami. Ideální kombinace.

Dejte mi zadání

Nedávno jsem si uvědomil, že používám techniku, která na první pohled nevypadá moc agilně. Chci po lidech písemné zadání práce. Možná se ta finta může hodit i vám. Tu situaci asi znáte. Někdo za vámi přijde a chce po vás udělat nějakou změnu v programu. Může to být nová funkcionalita, kterou vám zadává člověk z marketingu, nový nápad vzešlý z testování nebo něco od spolupracujícího oddělení. Může se jednat o něco pracnějšího, ale klidně i doopravdy malou a jednoduchou změnu.

Ve všech podobných případech si říkám o písemné zadání. Samozřejmě se nemusí jednat o sáhodlouhý dokument v předem připravené šabloně. Pokud je to trivialita, stačí jedna nebo dvě věty v mailu, pokud je to něco většího, většinou se spokojím se stránkou na Wiki.

Asi se ptáte proč je to tak důležité, proč jsem takový potížista a připravuji ostatní o čas? Mohl bych vám odpovědět zástupnými vysvětleními, jaké dávám těm kdo mi tu práci zadávají. Když se mě ptají oni, tak říkám, že to je proto, aby měli testeři podle čeho testovat. Nebo jím říkám, že jsem sklerotik, a mohl bych některé důležité detaily zapomenout. Další oblíbená odpověď je také taková, že se tím předejde případným sporům v budoucnu. Tyto všechny důvody jsou pravdivé a nesmírně užitečné. Ten hlavní je ale způsobený takovým těžko vysvětlitelným kouzlem. Když zadavatele donutím sepsat to co chce, donutím ho se nad danou věcí zamyslet. Často pak za mnou přijde znovu s tím, že chce něco jiného nebo že vlastně nechce nic, protože si to rozmyslel. Nejsem psycholog, takže to neumím vysvětlit, ale když lidé mluví, tak myslí jinak, než když píší. Znám to i z vlastní zkušenosti, občas mám geniální nápad, který i dobře zní, když ho někomu vysvětluji. Když ho ale začnu sepisovat, tak v něm najdu díru. Předpokládám, že něco podobného platí i pro ostatní.

Pokud tu fintu budete zkoušet sami, mám pro vás pár praktických rad. Pokud po někom chcete něco písemně, může to vypadat, že tu věc nechcete dělat nebo že chcete zdržovat. Je proto důležité druhé straně vysvětlit, proč je to užitečné i pro ně. Moje sociální vlohy jsou sice slabé, ale i tak se málokdy odvážím někomu říci, že se bojím, že to nemá dost promyšlené. Většinou argumentuji tím, že chci aby testeři měli podle čeho testovat. To obvykle zabere.

Často se taky setkáte s tím, že zadavatel nemá čas. To je zapeklitý oříšek. Často je to totiž člověk, který je formálně důležitější než vy. I tak je dobré zkusit mu vysvětlit, proč je to užitečné. Argumentů sami vymyslíte určitě spoustu. Pokud jste odvážnější, můžete se zeptat, kolik času mu může trvat napsat jeden odstaveček. No a pokud jste nevycválaní jako já, můžete ocitovat agilní poučku, která říká, že pokud nemá zákazník dost času aby něco pořádně zadal, tak to pro něj asi není dost důležité. Ale to je jen finta pro silné povahy, která navíc moc nezabírá.