Tato případová studie se zaměřuje na transformaci platformy, která je v softwarových firmách často nejužším hrdlem. Cílem je ukázat, že dokážete vyřešit situaci, kdy centrální tým nestíhá odbavovat požadavky produktových týmů a blokuje tak celou firmu. Tento článek je pouze shrnutí, detailní studie je k dispozici v angličtině na stránkách less.works.
O klientovi
SolarWinds je globálním lídrem v oblasti IT management softwaru. Má tisíce zaměstnanců a desítky jeho produktů v portfoliu stojí na technologickém základu (Core). Právě tento „společný motor“ se však stal kritickým bodem, na kterém závisel úspěch i rychlost všech ostatních týmů.
Startovní pozice: Past sdílené komponenty
Celý systém vývoje v tomto případě obnášel asi 200 lidí organizovaných do Scrum týmů. Klíčových bylo 5 (později 6) týmů, které vyvíjely sadu komponent zvanou Core, sdílenou všemi ostatními týmy. Původní nastavení vytvořilo klasický problém „mnoha pánů“. Skupina Core týmů měla vlastní backlog, ale úkoly do něj sypalo přes 10 různých produktových skupin. Výsledkem bylo:
- Nekonečné čekání: Produktové týmy čekaly měsíce na klíčové funkce v platformě, aby mohly dokončit své vlastní naplánované funkce.
- Politické bitvy: Prioritizace nebyla o byznys hodnotě, ale o tom, kdo z manažerů nejvíc křičí.
- Technologický dluh: Core týmy trávily téměř 100 % času „hašením“ požadavků ostatních, takže mu nezbývala kapacita na zásadní modernizaci (např. High Availability nebo nové UI).
- Fragmentace: Frustrované produktové týmy si začaly psát vlastní verze sdílených funkcí, čímž vznikal duplicitní a neudržitelný kód.
- Bobtnání organizace: Jelikož Core týmy nestíhaly psát nové funkce, management zakládal další týmy, které tyto funkce vyvíjely paralelně. Vlastně vytvořil paralelní Core týmy.
Cíl transformace
Hlavním úkolem bylo odstranit závislost produktových týmů na centrálním Core týmu a sjednotit prioritizaci napříč firmou.
Řešení: Rozšíření definice produktu a sdílené vlastnictví
Radikálně jsme změnili způsob, jakým firma o platformě přemýšlí. Implementovali jsme principy LeSS (Large-Scale Scrum):
Sloučení do jednoho Product Backlogu: Zrušili jsme izolované seznamy úkolů. Všechny požadavky na Core se soustředily do jednoho backlogu. Zároveň jsme začali pořádat pravidelné schůzky všech stakeholderů, na kterých se museli dohodnout, na čem se bude pracovat. Najednou bylo jasné, co má pro firmu nejvyšší finanční přínos.
Internal Open Source model: Zavedli jsme princip, kdy produktové týmy nemusí na změnu v Core jen „čekat“. Pokud platforma něco postrádala, mohl produktový tým sám přispět do kódu Core platformy pod dohledem mentorů (maintainers).
Výsledky
Díky změně paradigmatu se podařilo dosáhnout výsledků, které mají přímý dopad na P&L (zisk a ztráty) společnosti:
Snížení počtu backlogů: Z původních desítek izolovaných seznamů úkolů vznikl 1 transparentní systém.
Zjednodušení koordinace a manažerské režie: Před změnou jsme potřebovali 4 Product Ownery, kteří týmům připravovali požadavky. Po změně stačil jeden Product Owner a plánování sprintu zvládaly týmy samy ve velmi krátkém čase (první část plánování, kdy si týmy rozdělují úkoly, typicky trvala 30 minut)
“Změna nebyla jen o procesech, ale o odstranění bariéry ‘my vs. oni’. Core platforma se stala společným majetkem všech, což nám umožnilo škálovat vývoj bez přidávání dalších manažerů.”
Zajímá vás, jak odblokovat vývoj i ve vaší firmě? Rád s vámi proberu, zda je pro vás vhodnější model sdíleného vlastnictví nebo úprava produktové definice.
Chcete vědět víc? Propojme se!
Pokud hledáte dodavatele, který má zkušenosti z praxe a bude inspirovat vaše týmy k vyššímu výkonu, kontaktujte mě a můžeme se pobavit o možnostech spolupráce.
Kontaktujte mě