Širší produkt potrebuje menej koordinácie

Raz za štvrťrok sa 125 ľudí stretne na dva dni v jednej miestnosti. Na stene visí nástenka a do večera druhého dňa je plná šípok: tento tím čaká na tamten, toto rozhranie musí byť hotové do konca iterácie, platforma príde na rad až v marci. Keď ľudia odchádzajú, máte plán, ktorý drží pokope desať tímov. Stál 250 MD.

Pri ďalšom plánovaní veľa šípok spoznáte. Tie isté tímy, tie isté závislosti, len iný štvrťrok. Každá z nich vznikla na jednom mieste: tam, kde je nakreslená hranica produktu. Keď hranicu posuniete ďalej, šípky sa presunú do jedného backlogu a z nástenky zmiznú. Zlaďovať treba menej a ľudia z tej miestnosti majú viac času na prácu pre zákazníka.

K tomu istému záveru dospeli nezávisle od seba tri oblasti.

125 ľudí, dva dni, jedna nástenka

Štvrťročné plánovanie predpisuje škálovací framework SAFe a volá ho PI Planning. Robí to, čo sľubuje: závislosti sú viditeľné, majú vlastníka, sledujú sa a eskalujú. Po roku však nástenka ukazuje tie isté závislosti medzi tými istými tímami. Keďže plánovanie funguje, otázka, prečo sa vracajú, zaznie zriedka. Opakovanie vyzerá ako bežná cena práce vo veľkom.

Vracajú sa, lebo jeden produkt je rozdelený na viacero úzkych produktov, každý s vlastným backlogom (zoznam práce), vlastným vlastníkom a vlastnými tímami. To, čo zákazník vníma ako jednu vec, firma riadi ako šesť vecí, ktoré treba zladiť. Každá feature, ktorá prejde cez hranicu medzi produktmi, vytvorí závislosť, a každá závislosť ďalšie miesto, kde sa ľudia musia dohodnúť. Medzi desiatimi tímami je takých miest štyridsaťpäť. Ich počet rastie rýchlejšie ako počet tímov a plánovanie rastie s ním.

Okolo závislostí postupne vyrastie celé zariadenie: plánovanie, ktoré ich nájde, rola, ktorá ich riadi (v SAFe sa volá Release Train Engineer, skrátene RTE), nástenka, ktorá ich sleduje, a metrika, ktorá o nich vykazuje. Každá z týchto vecí je užitočná, kým závislosti existujú, a stráca zmysel, keď zmiznú. Ľudia, ktorí túto prácu robia dobre, majú preto dôvod držať súčasné hranice. Rozhodnutie o hraniciach ostáva na tom, kto štruktúru vlastní.

Plánovanie zachytí dva druhy závislostí. Známe a opakujúce sa (tím A vždy potrebuje rozhranie tímu B, tím C vždy čaká na platformu tímu D) poznajú všetci už dnes a na ich objavenie netreba 125 ľudí na dva dni. Riešia sa zmenou štruktúry: spoločným backlogom, iným zložením tímov, širšou hranicou produktu. Závislosti, ktoré vzniknú až počas práce, sa tri mesiace dopredu predpovedať nedajú. Dvojdňové plánovanie tak najspoľahlivejšie nájde tie závislosti, ktoré by ste poznali aj bez neho.

Bryan Finster pomenoval, prečo je to ťažké: „Skutočné zlepšenie by znamenalo zmenšovať zodpovednosti RTE, kým rola nezmizne. To nie je technický problém, je to politický problém. Žiadate ľudí, aby rozobrali koordinačný systém, ktorý ospravedlňuje ich pozíciu.“ Ľudia v tej role robia poctivú prácu. Štruktúra im dala prácu, ktorá trvá presne tak dlho ako problém.

V reportoch sa to ukáže ako veta „zlepšili sme sa v riadení závislostí“. Zlepšenie sa vtedy meria vyspelosťou procesu. Užitočnejšie číslo je počet šípok na nástenke zo štvrťroka na štvrťrok. Keď klesá, hranice sa posúvajú správnym smerom.

V širšom produkte sa závislosti rozplynú

Druhá cesta je rozšíriť definíciu produktu tak, aby sa závislosti rozplynuli. Čo prechádzalo medzi produktmi, sa ocitne vnútri jedného. Plánovanie, rola aj nástenka sa zmenšia, lebo je menej čo zlaďovať.

Jeden produkt. Jeden backlog. Jeden Product Owner (vlastník produktu), ktorý rozhoduje o poradí práce podľa hodnoty pre zákazníka. Cross-funkčné tímy si berú prácu zo spoločného backlogu. Nástenka závislostí medzi produktmi nemá čo ukazovať, lebo hranice, cez ktoré závislosti vznikali, sú preč.

Ten istý pattern nájdete všade, kde sa niekto pýta, čo je vlastne produkt. Zoberme si štát. Koľko produktov vidí občan? Občanovi je jedno, ktoré ministerstvo službu poskytuje. Zaujíma ho, či služba funguje. Z pohľadu zákazníka by digitálne služby štátu mohli byť jeden produkt.

Podobne banky. Banka povie, že má stovky produktov: sporenie, úvery, devízy, každý s vlastným backlogom a vlastnými tímami. Zákazník chce tri veci: presunúť peniaze, požičať si ich a sporiť. Tie stovky „produktov“ sú vnútorné divízie banky. V menšom to vidíte v každej technologickej firme. Tím, ktorý spravuje databázu, ju volá „náš produkt“. Tím, ktorý spravuje prepojenia medzi systémami (middleware), tiež. Zákazník si nekupuje ani jedno. Sú to organizačné hranice, ktoré dostali meno produktu, a každá z nich pridáva šípky na štvrťročnú nástenku.

Jednoduchá skúška: keď sa vaši Product Owneri musia medzi sebou zlaďovať, či už cez Chief Product Ownera (hlavný vlastník produktu), Portfolio Managera (portfóliový manažér), týždenný sync alebo zdieľanú tabuľku, tú koordináciu vyrába definícia produktu. Širšia definícia produktu odstráni celú koordinačnú vrstvu.

Najrozšírenejší škálovací framework s týmto kompromisom počíta otvorene. Jeho autor Dean Leffingwell to povedal v jednom webinári VersionOne: „Do vašej organizačnej štruktúry zvyčajne nezasahujeme, pretože to je dosť veľká vec.“ Z toho rozhodnutia vychádza celé štvrťročné plánovanie: štruktúra ostáva, riadi sa koordinácia. Je to rozumný kompromis a jeho cenu poznáte: 250 MD každý štvrťrok. Zmeniť štruktúru môže ten, komu patrí.

Najväčší nákupca technológií dospel k tomu istému

Americké ministerstvo obrany je najväčší nákupca technológií na svete. V roku 2020 vydalo DoDI 5000.87, samostatnú akvizičnú cestu pre softvér postavenú na malých cross-funkčných tímoch, iteratívnom dodávaní a DevSecOps, bez škálovaných koordinačných frameworkov. Prvý Chief Software Officer (hlavný softvérový riaditeľ) ministerstva verejne odrádzal od zavádzania SAFe. Jeho kritika bola štrukturálna: koordinačné frameworky pridávajú procesné vrstvy, ktoré spomaľujú práve to dodávanie, ktoré majú urýchľovať.

Komerčné firmy, ktoré rozšírili definíciu produktu, a najväčšia vojenská byrokracia na svete prišli k tomu istému záveru nezávisle od seba a z opačných strán. Keď najväčší kupec technológií na svete stavia svoju cestu pre softvér na malých tímoch bez škálovanej koordinácie, oplatí sa položiť si otázku aj vo vlastnej firme: koľko koordinácie patrí k samotnej práci a koľko jej vytvorila štruktúra?

Tri otázky na najbližšie plánovanie

Koordinačná vrstva riadi dopyt, ktorý vytvára štruktúra. Riadiť ho môžete lepšie, alebo ho môžete zmenšiť pri zdroji.

Na najbližšom plánovaní si položte tri otázky.

Existovali by tieto závislosti, keby jeden tím vlastnil featuru od začiatku do konca? Ak nie, vznikli tam, kde je nakreslená hranica produktu, a s jej posunom zmiznú.

Existovala by táto koordinačná rola, keby bola definícia produktu širšia? Ak nie, rola obsluhuje hranicu a zmenší sa spolu s ňou.

Keď sa práca nestihne v časovom rámci, berie to systém ako príležitosť na učenie, alebo ako nesplnený commitment (záväzok)? Rozšírenie definície produktu má svoju cenu: tímy sa najprv spomalia a až potom zrýchlia. Ľudia takú zmenu navrhnú, keď vedia, že dočasný pokles velocity (tempa dodávania) nebude trestaný. Túto istotu im môže dať ten, kto štruktúru vlastní.

Prvé dve otázky ukážu, či je príčina v štruktúre. Tretia ukáže, či sa podľa odpovede dá konať.

Na budúcom plánovaní porovnajte šípky na nástenke s tými z minulého štvrťroka. Každá, ktorá sa opakuje, ukazuje na hranicu, ktorú môžete posunúť. S každou posunutou hranicou šípok ubudne a plánovanie sa skráti. Širší produkt potrebuje menej koordinácie.