Category Archives: Agile

Autonomie, vlastnictví, agilita

Chcete aby byl váš tým agilní? Je to jednoduché. Musíte mu dát autonomii, z ní může vzejít pocit vlastnictví a teprve pak se může začít objevovat agilita. Pro mě je totiž Agile v první řadě neustálý proces učení se a zlepšování. Nikdo není dokonalý, takže je potřeba se neustále ohlížet, zjišťovat co funguje a co ne a na základě toho se učit. Proto máme iterace a na konci každé z nich retrospektivu. Tento pravidelný rytmus rituálů zajišťuje, aby se na učení nezapomnělo.

Ale je nutné si uvědomit, že rituály jsou k ničemu, pokud nemá tým pocit, že může něco změnit. Pokud si nevezme problémy za své, tak můžete udělat třeba tisíc retrospektiv a bude vám to k ničemu. Pro to, aby měl tým pocit vlastnictví, musí mít nad svou prací kontrolu, musí být autonomní. Musí mít prostor a zdroje, aby mohl měnit věci které nefungují, musí vidět že opravdu může něco zlepšit.

Pokud tým nemá autonomii, tak nemá důvod se snažit. Proč taky, vždyť o všem důležitém rozhoduje někdo jiný. V podobné situaci jsme byli před rokem, dvěma. Pokoušeli jsme se o Kanban. Šoupali jsme kartičkami po tabuli a nevím co ještě, ale pořád jsme měli moc rozpracovaných věcí (Work In Progress). Kanban je při tom na sledování množství rozpracovaných věcí postaven. Pokud je jich moc, tak je to příznak problému. Tým si toho všimne, zjistí co drhne, opraví to a jede dál.

Ale v našem pojetí to vypadalo následovně: „Proč děláš na třech věcech najednou?“ „Tady čekám na předávku kvalitě a tady na operations.“ „A proč to nepopoženeš?“ „Copak jsem jejich manažer?“ Zpětně je evidentní, že problém byl v nedostatečné autonomii týmů. V každodenní práci byly moc odkázány na ostatní, nebyly samostatné a jejich členové necítili vlastnictví. Proč by měli popohánět lidi z jiného oddělení? Proč by se měli snažit o zlepšení? Vždyť je to problém někoho jiného.

Pomohlo až to, co píší v každé knížce o Agile – dali jsme operations, kvalitu a vývojáře do společného týmu a najednou to není problém někoho jiného, najednou se to dá řešit, najednou se týmy snaží zlepšovat. Navíc nám už nikdo shora nepřikazuje zlepšovat tu a tu metriku, najednou se týmy snaží zlepšovat samy. Ano, není to procházka růžovou zahradou, jde to pomalu, drhne to, ale hýbe se to.

Nicméně jak říká Henrik Kniberg, Agile is Fragile. Je velmi snadné to rozbít. Nám se to částečně povedlo u releasů. Máme složitou platformu takže i releasy jsou složité. Některé týmy si to vyřešily po svém a nasazují samostatně. Jinými slovy, cítily problém, který přesahoval jejich možnosti, tak si odtrhly část platformy pod svoji kontrolu a zbytek neřešily. V rozdělování platformy měly navíc velkou podporu vedení, takže se to některým týmům povedlo.

Problém s releasy se tím ale nevyřešil. Některé týmy to mají s odtrháváním složitější, mnoho částí navíc zůstalo v zemi nikoho. Třeba společné testovací prostředí, to nikdo nechce, ale každý ho může rozbít. Zkrátka a dobře, problém s releasy se sice výrazně zlepšil, ale pořád se nám občas na produkci dostane něco, co by se tam dostávat nemělo.

Protože se to stávalo opakovaně, tak se naše vedení rozhodlo s tím něco udělat. Sešli se páni direktoři a rozhodli, že releasovat se bude tak a tak. Na tom také není nic špatného, dělají svoji práci. Viděli problém, tak se rozhodli ho řešit. Jenom jim nedošlo, že tím berou týmům část jejich autonomie. Teď už nejsou releasy záležitostí týmů, teď už jsou záležitostí directorů. Že se nová funkcionalita dostala na produkci pozdě? Ptejte se directorů. Že nevíme co, kdy a kde testovat? Ptejte se directorů. Je hrozně snadné k takovému přístupu sklouznout. Představte si, že vám někdo začne mluvit do věci, s kterou si beztak nevíte moc rady. Je hrozně snadné rozhodit rukama a tvářit se, že to tím pádem není váš problém. Znám pár lidí, kteří dokáží těmto pocitům vzdorovat, ale například mě to fakt nejde. Pokud mám pocit, že nad něčím nemám kontrolu, tak se nedokážu přinutit to řešit.

Hrozně rád bych tady napsal co s tím, bohužel to ale nevím. Na jedné straně vidím, že pokud týmy mají opravdovou autonomii, tak to funguje mnohem lépe. Čím víc si toho můžou řešit samy, tím lépe. Na druhou stranu ale nevím, jak řešit věci, které se dotýkají víc týmů nebo celé firmy. V chytrých knihách píší, že je potřeba určit společný cíl, který si lidé vezmou za svůj. Pak už jen údajně stačí jim dát prostor a oni vás k němu dostanou. Hmm.

Poslouchejme

Nemůžete posunout konverzaci pozitivnějším směrem, pokud se váš partner necítí vyslyšen a pochopen.
Douglas Stone

Musím se k něčemu přiznat. Myslel jsem si, že hlavním cílem komunikace je přenos myšlenek z jedné hlavy do druhé. Že když mi někdo něco vysvětluje, tak je jeho hlavním cílem předat mi nějakou myšlenku a mým úkolem je snažit se mu v tom pomoci. V okamžiku, kdy mi tu myšlenku předal, tak mu to musím dát najevo, ujistit se, že jsem to pochopil správně, prohlásit téma za ukončené a přesunout se dál.

Zní to rozumně, plně to odpovídá modelu racionálního člověka a přesto je to naprosto špatně. Ve spoustě situací vám druhý člověk nechce předat informaci, ale chce se jednoduše vypovídat.

Proč to vůbec píšu? Protože je to důležité a hrozně s tím bojuji. Nedávno se mi stalo, že jsem zastavil kolegu po první větě, protože jsem věděl, že to co mi říká, už dávno neplatí. Chyba. Myslel jsem si, že nám tím ušetřím čas, ale nestalo se. Byl rozhozený a následná diskuze byla k ničemu.

Co s tím? Je potřeba poslouchat. Ano, i když vám někdo říká něco co už dávno víte, i tak musíte poslouchat. Ne jenom čekat až ten druhý domluví, inteligentně u toho pokyvovat hlavou a přitom přemýšlet co budu říkat já, až se uráčí vyžbleptnout. Je potřeba ho opravdu naplno poslouchat. Nejen že nám opravdu může říci něco co nevíme. Ale i kdybychom přesně věděli, co nám chce sdělit, tak dokud nebudeme poslouchat my jeho, tak nebude poslouchat on nás. Dostaneme se do situace, kdy budeme vést sériový monolog. Každý si bude mlít to svoje, aniž bychom se navzájem poslouchali.

Abych ocitoval odbornou literaturu: „Důvod proč vás ten druhý neposlouchá není to, že je tvrdohlavý, je to proto, že se necítí být vyslyšen. Jinými slovy, neposlouchá vás ze stejného důvodu proč neposloucháte vy jeho. Myslí si o vás, že jste pomalí a tvrdohlaví. Takže se opakuje, hledá nové cesty jak vám to vysvětlit, zvyšuje hlas a tak dále.“ Nepřipomíná vám to vaší poslední složitou schůzi? Mně jo.

Netvrdím, že poslouchání je jednoduché. Už pár měsíců se to snažím naučit a pořád se mi to nedaří. Ano, umím se naučit parafrázovat, klást doplňující otázky a podobné finty. V tom to ale není. Ten pravý trik je v tom opravdu vnímat co ten druhý říká. Je to hrozná fuška, ale začíná mi docházet, že jinak to nejde.

Conwayův zákon

Pokud máte čtyři skupiny pracující na kompilátoru, dostanete čtyřprůchodový kompilátor.
Eric S. Raymond

V poslední době jsem několikrát narazil na Conwayův zákon. Řekl jsem si, že se o něj s vámi musím podělit.

Každá organizace navrhující systém nevyhnutelně vyprodukuje návrh, jehož struktura bude kopií komunikační struktury této organizace.

Na první pohled je to evidentní. Pokud mám dva moduly, které spolu komunikují, musí spolu zákonitě komunikovat i týmy, které je mají na starost. A naopak, pokud mám týmy, které si spolu nepovídají, nemohou si spolu povídat ani jejich komponenty.

Proč je to zajímavé? Protože to má dopad na architekturu systémů. Zjednodušeně řečeno, o architektuře je rozhodnuto dávno před tím, než se s ní vůbec začne. Řekněme, že chcete co nejlépe navrhnout nový systém. Je to velké, takže práci rozdělíte. Arnoštovi zadáte, aby vymyslel jak budou uložena data a Bedřišce zadáte, ať vymyslí jak je zobrazit. Aniž jste si to uvědomili, už jste rozhodli, že aplikace bude mít dvě oddělené komponenty, frontend a backend. Aneb jak píše sám pan Conway:

… samotný akt organizace navrhujících týmů znamená, že určitá rozhodnutí ohledně návrhu již byla učiněna, ať už explicitně nebo jinak. Ať už jsou týmy organizovány jakkoliv, vždy existuje třída alternativ, které nemohu být touto organizací efektivně následovány, protože neexistují nutné komunikační kanály.

Co z toho plyne? Pokud navrhujete něco nového, odsuňte rozhodnutí o organizaci týmů na co nejpozději. Předčasným rozdělením se připravíte o možná dobrá řešení.

Zajímavé je, že ta věta platí i naopak. Pokud už máte existující systém, musíte kolem něj stavět organizační strukturu. Představme si například, že máte úspěšnou aplikaci, ale tým už se rozrostl nad únosnou mez. Je potřeba ho rozdělit. Kvůli Conwayovu zákonu jsou dvě možnosti jak to může dopadnout. Buď se zároveň rozdělí i aplikace a každý tým dostane na starost jednu část. Nebo týmy zůstanou rozdělené jen na papíře. Lidé pracující na jedné komponentě spolu prostě musí komunikovat natolik intenzivně, že nemohou být rozděleni do víc týmů.

Pokud vás to zaujalo, přečtěte si původní článek. Na to, že byl napsán v roce 1968 je pořád zajímavý.