Škálování agility naruby

Škálování agility se v mnoha organizacích a konceptech diskutuje už dlouhé roky. Vznikly různé rámce typu LeSS, SAFe, Scrum of Scrums atp. a daná oblast je už řekněme docela dost prozkoumána. Otázka však byla v tomto ohledu vždy položena ve smyslu „Jak zkoordinovat více týmů nad jedním produktem?“. Nicméně, ve své konzultační praxi jsem se v menších firmách nebo dílčích částech větších firem setkal i ze zcela opačnou otázkou: „Jak má jeden tým zvládat vícero produktů či projektů najednou?“

Takto položená otázka je prozkoumána mnohem méně. Poměrně často vede snaha o její zvládnutí k fragmentaci a dekompozici týmu na shluk jednotlivců, což je jistě škoda. Jak to tedy řešit, abychom měli proaktivní, efektivní a motivovaný sebeorganizovaný tým a zároveň s tímto týmem mohli řešit víc než jeden produkt či projekt?

Typicky jde o situaci nějaké řekněme menší SW společnosti, která má jeden nebo několik málo týmů a ty řeší i vyšší desítky různých zákazníků, kteří požívají jejich řešení. S tím jsou spojeny různé změnové a další požadavky, údržba včetně aktualizace a do toho se míchají i zcela nové implementace apod. Snaha něco takového uřídit velmi často končí hašením těch nejvíce hořících požárů a o nějakém společném „tahu na branku“ nemůže být moc řeč. Každý se prostě snaží přežít v prostředí, kdy se požadavky kupí ze všech stran.

Inverzní škálování agility může být cesta

Pro klasické škálování agility, tedy spolupráci vícero týmů nad jedním produktem, je jakýmsi zlatým pravidlem, které se snažím razit: jeden produkt, jeden backlog, jeden product owner. Tento princip můžeme do značné míry použít i v naznačeném „opačném“ gardu.

Tedy, pokud mám jeden tým, který chci, aby fungoval jako tým. Což znamená v optimálním případě, že takováto skupinka lidí dělá společně, současně na jednom dílčím výsledku (přírůstku hodnoty). Trikem zde může být, že to nemusí nutně být z jednoho jediného „produktu“. Respektive, záleží na tom, jak si daný produkt definujeme.

Např. SCRUM guide definuje produkt: „Produkt je prostředek k doručení hodnoty. Má jasné hranice, známé stakeholdery, dobře definované uživatele nebo zákazníky. Produktem může být služba, fyzický produkt nebo něco abstraktnějšího.“

To je poměrně široká definice. V jedné primárně webové firmě jsme situaci „odemkli“ definicí, že produktem je jejich vlastní redakční systém a jednotlivé implementace (a také interní rozvoj) jsou vlastně dílčí položky backlogu, kterých mají několik set. A najednou vlastně lze i v souladu s daným metodickým rámcem dělat jeden týden na jedné či několika položkách backlogu pro jednoho zákazníka, další týden na úplně jiném zákazníkovi a třetí týden dělat nějakou interní rozvojovou práci. Společně, s konzistentním tahem na branku.

Vlastně se to až tak neliší od situace, když dělám jeden SW produkt, ale vybírám si do sprintů položky backlogu pro různé koncové uživatele a tak jako tak i značně měním podstatu toho, co tvořím. Samozřejmě je tu jistě komplikace, že si prostě musím umět načíst jiný kontext atd., což je ale hodně o práci Product Ownera, personách, kvalitě backlogu atd. Sem se hodí i krásný poznatek, že nevýhody agilních přístupů jsou často způsobeny jejich nesprávnou (neumělou) aplikací. Musíme si to prostě umět odpracovat.

Omezení a rizika

V reálném světě není samozřejmě nic černobílé a výše uvedený princip má svá praktická omezení. V praxi mají různé produkty/klienti nejen rozdílné priority, ale i odlišné stakeholdery, roadmapy a životní cykly. Konsolidace do jednoho backlogu je možná pouze při velmi široké definici „produktu“ (viz příklad s redakčním systémem) – což ale může vést k zamlžení priorit, řešení nekonečného přepínání kontextu a rozpadu týmové identity.

Při vysokém počtu skutečně různých produktů (které nelze dost dobře vnímat jako navzájem propojené do většího celku) se může ukázat jako efektivnější více dílčích backlogů a více dílčích (oblastních) PO, byť při zachování silné koordinace. A jednoho „Master PO“, který případně rozhoduje spory. Včetně vyvažování vlivu a komunikace mezi jednotlivými zákazníky a stakeholdery.

Zmíněný context switching může být také opravdovým problémem. Nejen že pravděpodobně znatelně sníží produktivitu, ale může vést i ke ztrátě angažovanosti. Je proto potřeba explicitně zohlednit „cost of change“, ideálně zavést limit na počet rozpracovaných produktů/projektů pro tým (WIP), aby toho prostě nebylo příliš mnoho najednou. Timeboxing  ve formě iterací v tomto ohledu hodně pomáhá. Je prostě pro všechny snazší si říct, že tyto dva týdny děláme tohle (byť by to byly např. tři věci pro tři různé produkty, ale ne víc), než neustále přeskakovat z jednoho na druhé.

Pro škálování agility se částečně hodí i KANBAN

V případě, že máme kontext natolik „rozstřelený“, že si nemůžeme dovolit alespoň týdenní iterace a nějakou formu Scrumu (opravdu to tak je?), lze se „uchýlit“ i ke KANBANU. Tady nejsme řízeni rytmem iterací, takže to vyžaduje o něco více sebekázně. Na druhou stranu můžeme poměrně plynule zpracovávat jednotlivé položky… za jistých předpokladů a podmínek.

Např. bude potřeba snaha o obdobnou granularitu položek ke zpracování a jejich definici, popis. Bude totiž hodně záležet na tom, jak moc budeme schopni pracovat společně jako tým na jedné položce. Riziko, že se nám to rozpadne do skupiny individuálních kolegů je zde dost možná vyšší. Velmi důležité tak bude vhodně „štěpit“ položky ke zpracování tak, aby dávaly pro týmovou práci smysl.

A i v tomto případě bude jistě platit jeden produkt tým, jeden backlog, jeden product owner. Respektive vlastník backlogu týmu, který plynule určuje priority. Tak, aby to bylo vidět, např. formou „swim lines“ pro jednotlivé zákazníky / produkty / projekty apod.

Principy a hodnoty vás povedou

Je zřejmé, že neexistuje nějaký univerzální recept pro škálování agility, který by platil vždy a všude. Nicméně hodnoty a principy agilních přístupů pro vás mohou být majákem při hledání vlastní cesty. Např.:

• Transparentnost, tedy potřeba mít srozumitelný náhled do toho, co se děje, chystá atd. To samo o sobě řeší spoustu věcí.
• Dodávat smysluplný výsledek (nebo jeho část), přírůstek hodnoty, co nejčastěji a získávat na něj relevantní zpětnou vazbu. Jen tak si lze účinně validovat směr postupu.
• Usilovat o skutečný tým, který je sehraný, dokáže se domluvit, zorganizovat a dodávat efektivně hodnotu. Takový tým je mnohem účinnější než nesourodá skupina individualit.
• atp.

A někdy to prostě nejde

V některých případech můžete samozřejmě zjistit, že to vlastně nejde. To především v případě, že je charakter položek backlogu, respektive přístup pro jejich zpracování, velmi odlišný. Někdy je prostě lepší prediktivní (vodopádovitý) přístup, někdy jde vlastně de facto o proces, jindy je to čistě agilní zadání.

V takovém případě dává smysl tyto věci oddělit. Např. vytvořením týmu, který se primárně zabývá prediktivním způsobem práce a týmu pro adaptivní zadání. Více o tom píši i v tomto článku o systémovém pohledu na organizaci. Jeden přístup obvykle není schopen vyřešit vše.

Budu Vám v hledání vaší cesty držet palce. A když uznáte za vhodné, můžeme to společně probrat. Ať už na některém z našich tréninků, na nějaké konferenci nebo i zcela individuálně.