Váš backlog je zlý, lebo vaša organizačná schéma je zlá

Vyberte si náhodne päť položiek zo svojho Product Backlogu. Pri každej si položte tri otázky:

Zaplatil by za to zákazník?
Dokážete to predviesť na Sprint Review?
Prechádza to všetkými vrstvami systému, od začiatku do konca?

Ak väčšina vašich položiek padne čo i len na jednej z nich, nemáte problém s písaním. Máte štrukturálny problém.

Tri V

Dobrá položka backlogu je hodnotná (Valuable: zákazník by za ňu zaplatil), viditeľná (Visible: výsledok uvidí aj vonkajší pozorovateľ) a vertikálna (Vertical: prechádza všetkými vrstvami systému ako ucelené správanie). Odtiaľ tie tri V.

Väčšina tímov, s ktorými pracujem, zlyháva na vertikálnosti. Nie preto, že by jej nerozumeli, ale preto, že v ich systéme je drahá. Ich backlogy sú plné položiek typu „Postaviť API“, „Navrhnúť schému databázy“ alebo „Vytvoriť formulár“. Každá položka sa dotýka jednej vrstvy. Žiadna nedodá funkčné správanie. Žiadna sa nedá predviesť. Žiadna sa nedá nasadiť.

Obvyklá reakcia je vyškoliť ľudí, aby písali lepšie stories. Spustiť workshop o delení stories. Rozdať checklist INVEST. Vyskúšal som všetky tri. Fungujú zhruba dva Sprinty, potom sa backlogy zase zosunú do horizontály, lebo problémom nikdy nebola ničia schopnosť písať.

Backlog je zrkadlom organizačnej schémy

Melvin Conway v roku 1967 pozoroval, že organizácie produkujú návrhy, ktoré zrkadlia ich komunikačné štruktúry. Backlogy nie sú výnimkou.

Keď sú vaše tímy organizované podľa technického komponentu (Databázový tím, Frontendový tím, API tím), backlog sa rozpadne na prácu vytvarovanú podľa komponentov. Databázový tím dokáže vziať len databázové položky. Frontendový tím dokáže vziať len frontendové položky. A tak Product Owner píše položky, ktoré sa do tímov zmestia. Nie z nevedomosti. Väčšina Product Ownerov, s ktorými som pracoval, dokáže opísať dokonalý vertikálny rez. Len ho nedokážu odovzdať žiadnemu jedinému tímu. Jedna potreba zákazníka, povedzme „filtrovať produkty podľa ceny“, sa zmení na tri položky v troch frontoch. Týždňová feature sa zmení na šesťtýždňovú dodávku.

Videl som to v softvérovej firme so 400 ľuďmi. Pred redizajnom sa ich backlog čítal ako diagram architektúry: „Implementovať vrstvu cache.“ „Aktualizovať REST endpointy.“ „Upraviť schému databázy.“ Každá položka pomenovala komponent. Žiadna nepomenovala zákazníka. Keď sme ich preorganizovali do cross-funkčných feature tímov, prvý Sprint bol chaos. Ľudia, ktorí spolu nikdy nepracovali, sa potkýnali na problémoch, ktoré si predtým prehadzovali cez plot. Pýtal som sa sám seba, či sme to nehnali príliš rýchlo. O tri týždne neskôr si Product Owner na Sprint Review otvoril nástenku a zarazil sa. „Toto už naozaj viem prečítať.“ Nikto nespustil žiadny workshop. Nikto nikoho nepreškolil. Štruktúra to naučila rýchlejšie, než by som to kedy dokázal ja.

Dokážu komponentové tímy občas dodať vertikálne položky? Áno, za cenu hrdinskej medzitímovej koordinácie. Lenže hrdinstvo nie je systém. Môžete spustiť každý workshop o delení stories, ktorý existuje, a Databázový tím aj tak bude rutinne brať len databázovú prácu. Keď váš backlog opakovane neprejde testom vertikálnosti, problémom nie sú slová na kartičkách. Problémom sú škatuľky v organizačnej schéme.

Test viditeľnosti

Druhé V, viditeľnosť, je najnepríjemnejšie.

Komponentové tímy predvádzajú API endpointy a migrácie databáz. Technicky pôsobivé. Pre kohokoľvek, komu na produkte záleží, úplne neviditeľné. Test znie: čo dokáže používateľ po tomto Sprinte urobiť, čo predtým nedokázal?

Komponentové tímy na túto otázku nedokážu odpovedať konzistentne. Dodávajú fragmenty. Ucelené správanie sa objaví až po integrácii, ktorá prichádza neskôr, v inom Sprinte, a koordinuje ju niekto iný. Craig Larman to nazýva „fake done“ (falošné hotovo): lokálne metriky ukazujú vysokú velocity, sprintové záväzky sú splnené, kvalita kódu vyzerá v rámci každého komponentu dobre. Lenže nič sa nenasadí. Systém hlási pohyb a nedodáva nič. Z každého Sprint Review odchádzajú všetci s pocitom, že boli produktívni. To je na tom to najhoršie.

Pasca hodnoty

Hodnotnosť pôsobí ako istá pôda. Váš Product Owner sa rozpráva so zákazníkmi. Váš framework na prioritizáciu existuje. To, čo sa nakoniec postaví, je predsa produktové rozhodnutie, nie štrukturálne.

Znie to správne. Teraz si otvorte dodávky za minulý štvrťrok. Koľko z toho sa dá priamo vystopovať k najhodnotnejšej zákazníckej potrebe tej chvíle?

Videl som to v každej organizácii s komponentovými tímami, v ktorej som pracoval: featury sa vyberajú podľa toho, čo dostupné tímy zvládnu najrýchlejšie, nie podľa toho, čo zákazníci potrebujú najviac. Larman ten istý pattern dokumentuje vo veľkých organizáciách: komponentový tím dostal za úlohu postaviť svoju časť nízkoprioritnej featury, ktorá nebola na rade ešte vyše roka, „jednoducho preto, že sa to tak ľahšie plánovalo“. Najhodnotnejšia práca nečinne čakala, lebo žiadny jediný tím ju nedokázal dodať od začiatku do konca. Backlog sa zaplnil tým, čo bolo štrukturálne pohodlné, a to sa potom racionalizuje ako prioritizácia.

To je tá pasca. Myslíte si, že vyberáte, čo sa postaví. Organizačná schéma už vybrala za vás.

Poctivé obmedzenie

Nie každá položka backlogu trafí všetky tri V ľahko. Lenže bežné „výnimky“ sú menej výnimočné, než sa zdá. Spiky nie sú položky backlogu; sú to experimenty na úrovni tímu, robené v rámci Sprintu, aby znížili neistotu okolo skutočnej položky. Infraštruktúrna práca je takmer vždy zameraná na zákazníka, keď sa pomenuje poctivo. Skutočných výnimiek je málo.

Tri V sú filter pre väčšinu práce. Keď väčšina vášho backlogu testom neprejde, problémom nie je výnimka. Problémom je štruktúra.

Čo s tým môžete urobiť

Organizačnú schému zajtra prekresliť asi nedokážete. Môžete však prestať predstierať, že problémom je backlog.

Keď sa nabudúce v backlogu objaví „Postaviť API“, odmietnite to. Opýtajte sa: čo dokáže zákazník urobiť so samotným API? Ak je odpoveď nič, nie je to položka backlogu. Je to úloha v prestrojení. To odmietnutie spustí hádku o tom, prečo sú vertikálne položky nemožné. Dobre. To je presne tá konverzácia, ktorú potrebujete.

Ak chcete dôkaz ešte pred hádkou, spravte jeden experiment. Jedna feature pre zákazníka. Ľudia, ktorí si ju bežne odovzdávajú jeden druhému, ju dodajú spoločne v jednom Sprinte. Druhý experiment už nebudete potrebovať.

Väčšina ľudí radšej spustí ďalší workshop.