Agilně ve velkých organizacích

Posledních několik měsíců se poměrně intenzívně zabývám otázkou zavádění agilních principů ve větších organizacích. Na následujících řádcích bych se s vámi rád podělil o své zkušenosti, které vedou k úspěšnému nastavení efektivního agilního prostředí ve vetší firmě.

 

Less

 

Velkou organizací myslím společnost s pěti a více týmy, ale mnohé, co zde zmíním, je dobré vzít v potaz i v menších firmách, například i o dvou týmech. Kromě vlastních a ověřených zkušeností, zde zopakuji obecně známé zásady LeSS (large scale scrum) a Spotify modelu. Právě Spotify model se stal v poslední době jakýmsi etalonem funkčního agilního prostředí.

 

Feature týmy jsou základ

Na úrovni vývojových týmů je největší překážkou jejich uspořádání nastavené v minulosti a neochota toto uspořádání změnit. Většinou se jedná o týmy zaměřené na určité komponenty systému nebo technologie – backendový tým, databázový tým, frontend, Java, a tak dále – takzvané komponentové týmy.

komp-team

Jakkoliv se toto komponentové uspořádání mohlo v minulosti zdát logické a i přesto, že mohlo v prvních letech existence společnosti fungovat dobře, s  jejím růstem a potřebou doručovat více featur a rychleji přestalo být efektivní. Ve větší společnosti, která chce doručovat iterativně a rychle, týmy uspořádané kolem komponent představují zásadní překážku. Proč tomu tak je?

  • User Stories, které jsou orientované na doručení hodnoty zákazníkovi se musí vždy rozpadnout do menších celků a ty jsou zpracovány jednotlivými týmy. Tyto menší celky už samy o sobě ztrácí informaci o přínosu zákazníkovi a stávají se obyčejným projektem s technickým zadáním. Hodnota vývojářů jako kompetentních odborníků schopných hledat dobrá řešení pro danou potřebu zákazníka je výrazně nebo úplně eliminována.
  • User Stories se rozpadají na menší celky, a proto musí existovat někdo, kdo plánuje a synchronizuje jejich doručování a integraci. Z tohoto pohledu pak není většinou možné doručit původní User Story v jednom sprintu. Pokud se User Story rozpadne do čtyř menších celků podle komponent systému, ze zkušenosti mohu říct, že je často potřeba alespoň čtyř nebo více sprintů k jejímu finálnímu dokončení.
  • Plánovaní a koordinaci často řídí klasický project manažer. Ten osvícenější bude své kroky konzultovat s týmy, ten méně osvícený vsadí pouze na své dovednosti a vypracuje pro každou User Story „prováděcí plán“. User Story jako taková pak velmi často existuje pouze v jeho hlavě a nějakých high level specifikacích, týmy o tomto vyšším celku mají velmi omezené informace a pracují pouze na low-level technických projektech bez širšího produktového kontextu.
  • Vývojové týmy jsou mentálně odděleny od produktu a smyslu práce, na které pracují. Mají tendenci zaměřovat se pouze na technické aspekty své práce a často vymýšlí architekturu, která neodpovídá současným ani budoucím potřebám produktu. Právě toto oddělení vývojářů od napojení na produkt je zásadním zabijákem jejich efektivity.
  • Týmy nemohou user story jako takovou otestovat z hlediska její funkce a logiky. Takové testovaní se provádí až po integraci všech dílčích menších částí a to speciálním testovacím týmem podle testovacího plánu vytvořeného project managerem nebo testovacím specialistou.
  • Nečitelnost a složitost doručovaní rozdrobených User Stories může vést k ještě větší potřebě vše dlouhodobě plánovat. Tak se společnost místo posunu k větší akce-schopnosti začne obloukem vracet ke klasickému vodopádu.

 

Takových a podobných problémů bych mohl napsat mnoho, ale pojďme se podívat na vlastnosti a nastavení týmu, který naopak agilní přístup bude podporovat.

Opakem komponentových týmu jsou takzvané feature týmy. Feature týmy jsou naopak složeny tak, aby byly schopny doručovat featury end-to-end a přes všechny komponenty. Vstupem k jejich práci jsou high-level specifikace a komunikace s lidmi z oblasti produktu. V týmech jsou zastoupeny všechny specializace vývojářů a další profese (ux, testeři, architekti, business) tak, aby by tým byl schopen provést jakoukoliv úpravu aplikace bez nutnosti spolupracovat s jiným týmem nebo specialistou.

feature-team.png

Pokud nějaké externí závislosti existují, týmy si je řeší samy. V minulosti se hodně ve větších setupech mluvilo o pravidelných scrum of scrum schůzkách, ty ale pouze dokumentují existenci externích závislostí mezi týmy a nutnost je řešit každý den. To může být legitimní potřeba, ale časem byste ji měli eliminovat.

Feature týmy by měly být stabilní co se týče jejich složení. Jejich členové by se neměli často obměňovat. Naopak fungování jednotlivců v týmu i týmu jako takového by se mělo průběžně ladit a opečovávat tak, aby tým mohl existovat dlouhodobě. Toto vetšinou zajišťují dedikovaní interní koučové nebo to může být svěřeno scrummasterům.

Vyhněte se sdíleným specialistům. Nevytvářejte nebo neudržujte ve společnosti různé komponent ownery a specialisty na určité části aplikace. Odpovědnost za tyto speciální oblasti musí být převedena na týmy. Potřeba mít takové specialisty většinou poukazuje na fakt, že komponenta nebo kód v dané oblasti je nečitelný, ve špatném stavu a tím pádem těžko uchopitelný pro týmy, které s ním ještě nepracovali. Dedikovaným specialistou tuto skutečnost jen schováte, ale nevyřešíte. Sdílený specialista je navíc vždy brzdou, na kterou se věčně čeká a je často příliš vytížený.

 

Jednoznačná orientace na produkt

Musí být vytvářena kultura jednoznačné orientace zaměstnanců na produkt místo zaměřování na nezávislé dílčí projekty. Projektově řízený management práce způsobuje mentální odpojení vývojářů od produktu a přemýšlení o něm jako o celku.

Toto už bylo naznačeno v předešlých odstavcích, ale orientace na produkt si zaslouží zvláštní pozornost. Jestliže jsou cross-funkční feature týmy technicko-organizačním nástrojem umožňujícím doručování užitečných a na zákazníka orientovaných změn, pak nastavení všeobecné firemní kultury zaměřené na produkt zajišťuje efektivní využívání tohoto nástroje.

Pokud jsou vývojáři odtrženi od produktu a přemýšlení o něm jako o smyslu své práce, mají přirozenou tendenci zaměřovat se pouze na svou technologickou oblast a dovednosti. Například určitou komponentu. Pokud se tak děje, produktu jako takovému mu jen zřídkakdy prospívá.

Cross-funkční tým složený z frontend, backend, a jiných vývojářů-specialistů je dobrý, ale tým cross-funkčních vývojářů je ještě mnohem lepší. Právě zaměření na produkt pomáhá vývojářům vymanit se ze škatulek typu „já jsem pl/sql vývojář“ a jasně je motivuje pomáhat si navzájem a rozšiřovat své dovednosti tak, aby mohla být práce na produktu úspěšně dokončena. Netvrdím, že je potřeba a že je možné, aby byli všichni ve všem stejně dobří. V týmu vždy budou větší odborníci na určité technologie nebo programovací jazyky. Ale potlačením jejich specializací se rozboří bariéry mezi členy týmu a výrazně se omezí závislost konkrétních typů práce na konkrétních lidech.

 

Requirement areas

Pro účely agilního vývoje nemusí slovo produkt jednoznačně představovat produkt, který je obchodně nabízen zákazníkům. Produktem může být například i interní administrativní služba (reporting website). Toto dělení produktu je u větších společností logické a většinou nezbytné – není možné a nebo není praktické, aby se všichni vývojáři orientovali úplně ve všech oblastech obchodního produktu. Důvodem je skutečnost, že úsilí, které musí vývojáři vynakládat na orientaci v celém produktu, je příliš velké a míra neustálého učení a zjišťování informací se jednoduše nevyplatí. V takových případech je dobré produkt rozdělit do takzvaných requirement areas a nechat jednotlivé týmy pracovat v těchto oblastech. Ve společnosti Verotel je produkt  (platební portál) rozdělen na dvě části: buyer experience a merchant experience. Buyer experience zahrnuje vše orientované na uživatele, který platí kreditní kartou a vlastní processing platebních transakcí. Merchant experience naopak pokrývá vše, co se týká obchodníků, vytváření shopů, reporting, a již zmíněnou interní administraci.

V práce v requirement areas logicky zahrnují všechny technologie v nich používané (programovací jazyky, databáze, frameworky, komunikační protokoly, atd). Requirement areas poměrně často přirozeným způsobem samy omezí nároky na znalosti technologií pro týmy v nich pracujících.

Ve větších setupech by každá requirement area měla mít svého vlastního product ownera a vlastní backlog. Těmto backlogům by měl být nadřazen jeden high-level backlog. O tento high-level backlog se stará hlavní product owner a spolu se skupinou requirement area product ownerů obstarává koordinaci položek v hlavním backlogu a area backlozích. Jinak řečeno, jedná se o hierarchicky uspořádané backlogy.

Hlavní product owner není chápán jako nadřízený area product ownerů, ale jako někdo, jehož odpovědností je udržovat high-level backlog a organizovanou spolupráci všech product owner.

Společnost přecházející na agilní vývoj musí identifikovat, případně vytvořit potřebné requirement areas a každé této oblasti přiřadit tým nebo skupiny týmů. Je lepší vytvořit spíše méně širších requirement areas a nechat v každé z nich operovat více týmů, než jich vytvořit mnoho a pro každou mít pouze jeden dedikovaný tým. Toto zajistí lepší chápání produktu, jeho souvislostí,  sdílení kódu a výše zmíněné všeobecné napojení na produkt. Extrémně úzké requirement areas mohou ve finále mít podobný efekt jako komponentové uspořádání týmů.

 

Communities of practice

Dobrá, máme funkční feature týmy, jsme plně zaměřeni na rozvoj produktu, jenže po čase nám architektura systému, UX, i produkt samotný začnou drhnout. Velice pravděpodobně  to bude způsobeno přespřílišnou nezávislostí a odděleností jednotlivých týmů a nedostatku komunikace mezi nimi. Elegantním a velmi praktickým způsobem, jak zajistit sdílení a šíření informací mezi týmy je koncept takzvaných Communities of Practice.

Communities of practice (CoP) jsou virtuální týmy, které sdružují specialisty z jednotlivých feature týmů, například CoP všech UX specialistů, CoP všech testerů, nebo backend vývojářů.

cop-teans

CoP jsou základem samo-organizace na úrovni celé společnosti, zajišťují konzistenci rozhodnutí činěných na úrovni týmů, sdílení a šíření důležitých poznatků, vytváření dlouhodobějších vizí.

Každá CoP by měla mít svého vedoucího. Není to nezbytně nutné, CoP kompetentních pracovníků se dokáže organizovat sama. Pokud ale na agile přecházíte, je určitě dobré CoP definovat  a v každém z nich určit člověka, který bude za její fungování odpovědný. Odpovědný hlavně za to, že se komunita pravidelně stýká, schůzky jsou smysluplné, diskuze mají dobrý obsah a vytváří se na nich dlouhodobější vize jejich práce. Vedoucí by měl být zkušeným odborníkem v dané oblasti, přirozenou autoritou, ideálně však i běžným pracovníkem, který pracuje v nějakém feature týmu. U dedikovaného vedoucího, který se věnuje pouze řízení CoP na plný úvazek, existuje riziko odpojení od reality každodenní práce.

To, že CoP koncept je pro udržitelné a fungující agilní prostředí naprosto zásadní, ilustruje společnost Spotify tím, že vytvořila jak povinné communities of practice (chapters) tak i a communities of interest, takzvané guilds.

Kromě všeho zmíněného CoP přirozeným způsobem podporují vytváření continous improvement kultury na úrovní celé společnosti.

V návaznosti na zavádění CoP musíte dále zajistit:

  • Retrospektivy nejen na úrovni teamů, ale i joint retrospektivy zahrnující několik týmů nebo celou společnost
  • Neoptimalizovat pouze fungování uvnitř týmů, ale věnovat pozornost celému systému týmu, jejich spolupráce, závislostí a komunikace mezi nimi.
  • pořádat cross-teamové reviews ať už ryze technických a nebo celofiremních produktových demos.

 

Není to jen software development

Čím větší společnost, tím víc přechod na agile ovlivní chod celé firmy.

Nejčastějším důvodem neúspěšného přechodu na agile u větších společností je potřeba zachovat existující strukturu řízení společnosti, jejích oddělení a způsobu řízení.

Aby společnosti dosáhli dobře fungujícího agilního prostředí, musí být původní setup upraven – ten byl nastaven na jiný způsob práce – například klasické projektové řízení. Musí dojít ke zploštění řídící struktury tak, aby jednotlivé týmy získaly skutečnou možnost ovlivňovat chod vývoje produktu a způsobu organizace jejich vlastní práce. Požadovat po týmech, aby byly self-organized a nedat jim k tomu prostor (nebo jim dát přísně vymezený prostor) je svým způsobem protimluv.

Struktura organizace by měla být tak horizontální, jak je to jen možné. A to proto, abychom se vyhnuli složitým stromečkům hierarchie, ve který lidé ztrácí potřebu za něco nést odpovědnost. V takovém prostředí je vždy možné přehazovat odpovědnost na jiné – nadřízení na podřízené a podřízení na nadřízené.

Nezbytností je rozbít sila specialistů (business, software) a rozdistribuovat je do patřičných feature týmů a communities of practice.

V oblasti product managementu musí být jmenován silný product owner, musí mu být svěřena pravomoc dělat produktová rozhodnutí. Veškeré změny pak musí procházet skrze backlog, který obhospodařuje. Tím se eliminují nešvary spojené s prostředím, ve kterém každý obchodník, pracovník marketingu, product manager chaoticky posílají požadavky na featury a změny vývojovému oddělení. Product owner na oplátku všem poskytuje transparentní a srozumitelný přehled o tom, na čem se bude pracovat.

Vetší organizace se musí o své zaměstnance starat a vychovávat je tak, aby chápali a dál šířili své zkušenosti a kulturu firmy. U větších organizací dochází také k větší míře fluktuace zaměstnanců. Pokud je zaměstnanec chápan jako komodita, potřeba starat se o jeho vzdělávání a předávání firemní kultury nedává smysl. Zvýšená fluktuace způsobuje neustálý forming-storming-norming-(performing) týmů a výrazně tím snižuje efektivitu. Pouze dlouhodobě existující tým, ve kterém stav vztahů dospěl do fáze performingu může mít skutečný fokus na doručování kvalitních featur zákazníkovi.

Pár slov na závěr

Vše výše zmíněné dává smysl a tak může vzniknout mylný pocit, že jednorázovou reogranizací vše vyřešíme. Šance na úspěch takového postupu se ale blíží nule. Stejně tak myšlenka, že se celá reoganizace jednorázově vymyslí, nastaví a firma bude rázem agilní je zcestná. Celý proces zavádění agile je stejně iterativní jako samotný iterativní vývoj software. Je potřeba začít u proveditelných změn, příjímat dosažitelné challenges, zkoušet různé způsoby, jak dosáhnout určitého cíle. Většinou je to běh na dlouho trať a reálný cíl neexistuje. Vždy je co zlepšovat. Důležité ale je uvědomit si, že sebemenší krůček je posun dobrým směrem. Jinými slovy cesta je cíl 🙂

Reklamy

One thought on “Agilně ve velkých organizacích

  1. Martin Strnad napsal:

    Díky za vynikající postřehy. Myslím, že se u nás přesně projevují nedostatky toho klasického přístupu popsaného na začátku článku

Zanechat Odpověď

Vyplňte detaily níže nebo klikněte na ikonu pro přihlášení:

WordPress.com Logo

Komentujete pomocí vašeho WordPress.com účtu. Odhlásit / Změnit )

Twitter picture

Komentujete pomocí vašeho Twitter účtu. Odhlásit / Změnit )

Facebook photo

Komentujete pomocí vašeho Facebook účtu. Odhlásit / Změnit )

Google+ photo

Komentujete pomocí vašeho Google+ účtu. Odhlásit / Změnit )

Připojování k %s

%d bloggers like this: