Jak probíhá práce v prostřední přední české globální ICT společnosti Y Soft? O tom v komentáři informuje Zdeněk Soukup, Area Product Owner společnosti Y Soft.
Large-Scale Scrum (LeSS) je framework pro škálování Agilního vývoje pro více týmu. LeSS staví na principech Scrumu jako je empirismus, cross-functional týmy, samoorganizující se týmy a přináší framework pro aplikaci Scrumu pro větší organizace, velké produkty a více týmů. Jak probíhá práce v prostřední přední české globální ICT společnosti Y Soft? O tom v komentáři informuje Zdeněk Soukup, Area Product Owner společnosti Y Soft.
Jsou dva aspekty práce u Y Softu, které stojí za to probrat podrobněji:
- Adopce LeSS
- Absence manažerů
Large-Scale Scrum (LeSS)
V roce 2019 jsme ve vývoji začali používat metodiku LeSS, která je postavena okolo agility a scrumu. Nejzásadnější organizační změna byla v přeskládání celého vývojového oddělení do tzv. feature týmů a opuštění předchozího konceptu komponentních jednotek. Rozdíl je v tom, že dnes dokáže kterýkoliv tým vyvinout, otestovat a nasadit jakoukoliv uživatelskou funkcionalitu. A dopad? Můžeme výrazně škálovat, počet týmů roste.
Bezmanažerská organizace
Tým je u nás tvořen z produktových vývojářů, je kompletně samoorganizovaný. V týmech tak neexistují pozice jako team leader, manažer, product owner a dokonce ani scrum master. Z organizačního pohledu to u nás vypadá tak, že všech 100+ lidí formálně spadá pod Y Soft CEO.
O absenci manažerů v Y Softu existuje spousta článků a rozhovorů (odkazy), tak jen stručně zmíním, že vznikly situace, se kterými jsme se museli vypořádat a jako příklad uvedu proces kariérního růstu.
Kariérní růst: kdo mi schválí povýšení?
Ve chvíli, kdy se člen týmu rozhodne, že je čas posunout se formálně na vyšší pozici, je třeba udělat jedinou věc: zeptat se kolegů, jestli jim to dává smysl.
Má na to formuláře a vzory, ty rozešle lidem, kteří s daným člověkem často spolupracují. Sebranou zpětnou vazbu poté projde „komise“, jejímž jediným úkolem je se ujistit, že byl splněn proces. A že na základě zpětné vazby je skutečně povýšení na místě. V této komisi zasedají zástupci týmů (dobrovolně) a HR.
Tolik k organizačnímu kontextu, pojďme se podívat na některé principy, které při práci využíváme.
Jak probíhá vývoj
V současné době u Y Softu pracuje 13 týmů, každý má 7 produktových vývojářů. Každý tým má své jméno, logo, interní dohody a svou vlastní kulturu. Jedná se o samoorganizovanou jednotku do té míry, že tým sám rozhoduje o tom, kdy budou nabírat další kolegy a jaké, jak budou pracovat nebo kdy je třeba tým rozpustit. Ano, i takové případy máme – členové zanikajícího týmu pak mohou nastoupit do jiných týmů, pokud se s nimi domluví.
Společně pak týmy tvoří jakýsi „tým týmů“, který pracuje na základě vzájemných dohod (agreements). Způsob práce se přizpůsobuje a mění na základě jednoho produktového backlogu, jedné roadmapy.
Sprint
Scrum používá tzv. sprinty jako pevné jednotky času, kdy je vhodné se zastavit a ohlédnout. Mimo jiné tak jednou za dva týdny tak validujeme, že stále pracujeme na těch nejdůležitějších věcech, na kterých můžeme v danou chvíli pracovat.
Sprint začíná refinementem, kdy týmy rozeberou problém a navrhnou řešení:
- Ano, opravdu jsou to týmy, kdo problém analyzuje.
- Ano, opravdu řešení navrhují týmy. Nikoliv Product Owner nebo Manažer nebo někdo takový.
Toto řešení pak validujeme s lidmi, kteří jsou nejblíže koncovému uživateli – v ideálním případě máme přímo zákazníka, který je součástí těchto diskusí. V jiných případech například kolegy z prodeje nebo podpory. Je to opět vývojový tým, kdo zaznamená akceptační kritéria na jedno-sprintový vývoj a určuje odhad pracnosti.
Během Plánování (událost definovaná Scrumem) se domluvíme co se bude prezentovat na dalším Sprint Review – tedy jakou demonstraci našeho dvoutýdenního snažení ukážeme kolegům a zákazníkům. Po plánování následují dva týdny (ideálně) nerušeného vývoje.
Sprint Review
Sprint Review vnímám jako nejdůležitější událost Sprintu: validujeme, že nás naše úsilí, naše investice, posunuje správným směrem. Že se skutečně přibližujeme vyřešení problému, kterému naši zákazníci čelí.
Cílem Sprint Review je získat zpětnou vazbu na naši práci a k tomu optimalizujeme průběh celé události. Všechny ukázky novinek jsou prováděny týmy a to tak, že jsou pochopitelné pro netechnické obecenstvo. Ukázka nového zdrojového kódu nového způsobu skenování dokumentů určitě pochopitelná není. Naproti tomu video jak vkládám papíry do podavače na kopírce a ukazuju jak byly zpracovány jsou něco, co je pro zákazníky mnohem stravitelnější.
Kdo vylepšuje systém?
V článku tohoto rozsahu určitě nelze popsat všechny mechanismy a postupy, které jsme za ty roky nastavili, nastavili a zrušili, nastavili a změnili.
Přidám tedy jeden zajímavý experiment, který už několik měsíců běží: vrchol backlogu je rezervovaný na vylepšování jakéhokoliv typu.
Cokoliv někdo cítí, že když se stane, tak budeme všichni efektivnější, může vložit jako top prioritu pro celou organizaci. Jediná podmínka: musí to vzít a udělat.
KOMENTÁŘE