Category: Scrum

Poslední dobou se vyrojila spousta různých metod jak škálovat Scrum a Agile proces na prostředí velkých produktů. Takže než se chytíte do sítě různých klasicky smýšlejících organizací, které ve Scalingu konečně našly cestu jak naoko aplikovat Scrum, ale praktiky nemuset měnit, tak se zkuste podívat na zcela Agilní přístup jak na to.

Není na tom nic až tak složitého.  Jen musíte rozumět tomu, co je opravdu Scrum. Není to totiž proces jak řídit vývoj, ani něco kvůli čemu máme Backlog a Standupy, ale přístup, filosofie a kultura. Obecně se tomu říká empirický proces. Tedy velice volně definovaná pravidla hry. Každá taková Scrum hra má své hřiště s pevně danými mantinely a pár pravidly jak hrát. Jinak by to byl chaos. Ale už neříká, co přesně v které situaci musíte udělat. K tomu jsou definované best practices. A Scaling Scrum je často ukázkou, jak k tomuto problému lze přistoupit neagilně a nescrumově – tedy kolem Scrum týmů vytvořit složité byrokratické struktury nových rolí, procesů,  meetingů, pojmů.  Viz obrázek, kde ta bílá plocha je to, co je původní Scrum.

Opačný přístup zvolil Bas a Craig s frameworkem LeSS. Stejně tak, jako když Ken kdysi dávno definoval Scrum a měl možnost si zvolit, které praktiky budou součástí Scrumu a které ne, volil spíše méně než více. A protože Scrum je něco, co se stále vyvíjí, je dnes na rozdíl od začátku nedílnou součástí Scrumu Retrospektiva, ale například story pointy, User Stories and Scrum Board jsou jen doporučené praktiky. Proto je Scrum tak úspěšný. Je totiž aplikovatelný úplně kdekoliv. Když se vrátím k LeSS Large-Scale Scrum frameworku, tak přesně to je hlavní filosofií LeSS – ‘Do more with LeSS‘.

Co se tedy podle LeSS musí změnit proti jednoduchému obrázku, kde máme jen jeden Scrum tým? Na první pohled nic zásadního. Pořád máme jeden stejný Sprint, jeden ‘potentional shipable product increment‘, jeden kód a continuous integration. Pořád máme cross-functional týmy které dokážou jako tým samostatně dokončit jakoukoli položku z Product Backlogu. Týmy si dělají své vlastní Standupy a Retrospektivy. Pořád máme všichni jeden cíl, dodat hodnotu zákazníkovi. A tak pro jeden produkt máme jeden Product Backlog a jednoho Product Ownera – a nemusíte se bát, zvládne to. On totiž Product Owner nikdy nepracuje sám a i na tom jednoduchém 1-1 obrázku má spoustu pomocníků.

Takže v podstatě jediné, co se změnilo je, že na úrovni development týmů se zajímáme co dělají ostatní týmy, jednotliví členové spolu řeší závislosti. Ne co se týče businessu, protože položky Backlogu jsou nezávislé, ale závislosti v kódu, dané konkrétním řešením dané Story. Dále obvykle posíláme zástupce týmů, aby chodili jako pozorovatelé na Standup ostatních týmů a identifikovali tak včas případné návaznosti a rizika. Na úrovni produktu už není jen na Product Ownerovi, aby před Sprintem vybral priority pro příští Sprint, ale obvykle se takového výběru zúčastní i zástupci týmů, aby zohlednili jejich různé zkušenosti. Nakonec je tu ještě jeden nový meeting – Overall Retrospective – jejímž cílem je udělat retrospektivu na téma jak nám jde spolupráce. A jak se asi dá očekávat, jsou tam ScrumMasteři, Product Owner, a zástupci týmů a koná se vždy po skončení Sprintu.

Nic složitého. A jestli to funguje? Ale jistě. První implementace Scrumu, ve které jsem se ocitla ještě jako vývojář, byla přesně taková. Tři týmy, jeden produkt. Časem jsem byla ScrumMasterem několika týmů právě v takovém uspořádání, tentokrát pro šest týmů. A jako Agilní coach jsem takové uspořádání pomáhala implementovat v mnoha různých firmách. Takže ano, funguje to, je to snadné, je to Agilní, a přináší to výsledky. Jestli jsem vás nepřesvědčila, můžete se podívat na některou z LeSS case studies nebo na detailní popis LeSS Large-Scale Scrum Frameworku.