V minulém díle seriálu o lesku a bídě používání SCRUMu ve firmách jsme poukázali na nešvary při odhadování, vytváření plánů a sledování průběhu projektů. V dnešním díle se podíváme na častý nešvar agentur, jejichž týmy honí více než jeden projekt nebo jsou seskládané z lidí nepracujících na plný úvazek či lidí nepracujících na jednom místě.
V původní vizi SCRUMu měl tým pracovat na právě jednom projektu pro právě jednoho klienta, byť v něm figuruje třeba více stakeholderů. Jaká je ale realita?
Děláme To a To a To
Obzvláště při práci v agenturách, které typicky dělají zakázkový vývoj, se lze setkat s nešvarem příliš mnoha zajíců. Firma má jen pár vývojářů, designérů a dalších specialistů, a tak z nich udělá jeden tým a na něj nahrne jak úpravy vlastních stránek a interních systémů, tak samozřejmě práci na všech zakázkách, které se obchodnímu oddělení podařilo nasmlouvat.
Každý další projekt zahrnutý do sprintu přidává do projektů další rozměr prioritizace, improvizace a nejistoty. Protože například technický dluh v rámci jednotlivých projektů může být poměrně variabilní, ovlivňuje tak podstatně spolehlivost jednotlivých odhadů.
Dalším podstatným problémem při zahrnutí zakázkového vývoje je nedostatečná agilnost SCRUMu, který, byť je označován jako agilní, počítá se změnami v zadání při plánování sprintů, nikoliv s hovorem klienta druhý den po zahájení sprintu.
Když přejdeme od náplně sprintu k realizačnímu týmu, i zde najdeme řadu nešvarů. Například žonglování s částečnými úvazky, které nelze do celkové kapacity přidávat pouhým přepočtem časové dotace, jednak kvůli SCRUM aktivitám, které prostě žerou čas, jednak kvůli menší učící zpětnovazební smyčce. A to nemluvíme o snaze zkoordinovat časy všech aktivit do dní, kdy všichni můžou.
Velmi závažným prohřeškem je i nerespektování různých schopností jednotlivých členů týmu. SCRUM sice víceméně očekává, že jednotliví členové jsou univerzální, a práci si lze rozdělit celkem ledabyle, avšak především malé týmy rychle narazí na to, že backend umí jen tato podskupina, frontend zase jen tato podskupina atd. Na druhou stranu mít celý tým full-stack vývojářů se celkem prodraží.
U realizačního týmu lze také často narazit na přidávání externistů do projektu, typicky pro dodání nějakých podkladů či realizaci jednorázových aktivit – z pohledu SCRUMu je najednou problém s odhadem, začleněním do statistik a množstvím nadbytečné komunikace vedoucí k tomu, aby byl tento externista v obraze a dodal to, co je potřeba, dřív, než je to skutečně potřeba.
Speciálním a často pozorovaným případem zejména začínajících agilních týmů je vyčleňování analytiků mimo tým s tím, že oni jen zanalyzují zadání, vytvoří úkoly a tím to pro ně víceméně skončí. Jenže mimo jiné i naše zkušenost praví, že analytik je potřeba po celou dobu projektu. Především proto, že zadání by nemělo vznikat jako celek, jak tomu je při použití vodopádu, ale mělo by být postupně laděno napříč jednotlivými sprinty. Dále pak vyčlenění mimo projekt vede k častým blokacím týmu (například když dělá na jiném projektu), komplikacím v plánování a neúplným statistikám.
Nezanedbatelnou výzvou v dnešní době je práce mimo kancelář a distribuované týmy. Obojí může snadno vést k degradaci SCRUMových aktivit, jejich kvalit, týmové znalosti vyvíjeného produktu i ke snížení zastupitelnosti členů.
V posledním díle se zaměříme asi na nejzávažnější nešvar ze všech. Uhodnete, o co půjde?
Sdílet článek