Large Scale Scrum (LeSS) týmy v českém podání aneb jak probíhá workflow firmy Y Soft

DomůKomentáře

Large Scale Scrum (LeSS) týmy v českém podání aneb jak probíhá workflow firmy Y Soft

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.

Součástí MS Office 2021 může být firemní komunikátor Teams
Dell uvádí bezpečnostní nástroje Managed Detection and Response Pro Plus
Software house eMan zakládá designovou agenturu BrightVibe
Lenovo ThinkSmart View Plus bude v Česku od srpna v prodeji za 62 290 Kč

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

WORDPRESS: 0
DISKUZE 0