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.

Stackopera spouští český katalog firemního softwaru
Cisco: vývojáři musí řešit problémy aplikací, místo aby vytvářeli nové
Lenovo ThinkSmart View Plus bude v Česku od srpna v prodeji za 62 290 Kč
Start-up Productboard získal další investici 1,5 miliardy 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