Agile Schaling - houd het simpel

Erik Buitenhuis - Voordat ik bij Quality Accelerators werkte, nam ik eens een SAFe-opdracht over van een collega-coach. Bij deze SAFe implementatie bleek het te gaan om 1 team! Er was een zware schalingsmethode ingevoerd voor 1 team! Iemand had de klant SAFe verkocht, of misschien had die er zelf wel om gevraagd, in een context waar een simpel Scrum proces had volstaan.

SAFe wordt vaak ‘uitgerold’ als dé methode om Scrum verder te brengen dan het niveau van individuele teams, om teams onderling te laten samenwerken en aansluiting tussen operationeel, strategisch en tactisch niveau te bewerkstelligen. Maar te vaak zonder oog voor de onderliggende agile mindset. Wat veel organisaties niet beseffen: agile werken is een fundamenteel andere manier van organiseren. Zelforganisatie, contextafhankelijkheid en voortschrijdend inzicht zijn daarin leidend — niet het proces zelf. Die mindset is de grote verandering, niet de praktijken van een agile methodiek. Het gevaar van SAFe is dat het vaak geadopteerd wordt door topzware organisaties met veel proces. Doordat SAFe zo uitgebreid is, kan mooi alle overhead een plekje krijgen in de nieuwe organisatie. De nadruk wordt gelegd op processen en praktijken en niet op de mindset. Dat is het gevaar. Het leidt dan tot minimale verandering, waarbij de toegenomen complexiteit de transparantie vermindert. Een simpele methode als Scrum brengt door zijn eenvoud problemen in de organisatie naar de oppervlakte. Een complexe methode verbergt disfunctionaliteiten vaak juist. Dit, samen met de top-down ‘feel’ van de methode, is de kritiek op deze meest populaire schalingsmethode. Ik deel veel van die kritiek, maar SAFe kan wel degelijk op een ‘echt agile’ manier worden ingezet en kent een aantal nuttige praktijken.

Waarom schalen?

Producten zijn vaak groot en complex en kunnen dan niet door een enkel team worden gebouwd en onderhouden. Wanneer je moet opschalen naar meerdere teams, gaan die teams elkaar al snel in de weg zitten. Er zijn onderlinge afhankelijkheden, zowel business als technisch, die opgelost moeten worden. Teams kunnen elkaar tegenwerken door hun eigen stukje product te (sub)optimaliseren met onvoldoende focus op het grotere (product) belang. De noodzaak van coördinatie en alignment maken alles complexer. Dat betekent dat we het simpele agile proces (vaak Scrum) moeten uitbreiden om die complexiteit te managen.

Houd het simpel

Les 1 bij het schalen van agile is: doe het niet als het niet nodig is! Houd het simpel - dat geeft overzicht. Simpel helpt alles transparant te houden. Je kunt beter zien hoe en waar je moet ingrijpen om knelpunten op te lossen. Wanneer je verschillende producten kunt onderscheiden met onderling geen of minimale afhankelijkheden, richt dan teams in rond de waardestromen van die producten.

Maar als dat niet kan en je gaat schalen omdat je team te groot wordt (Jeff Sutherland vond in een onderzoek naar high performing teams dat die teams vaak best klein zijn, gemiddeld 4-5), houd het dan zo simpel mogelijk, dat is niet voor niets een van de agile principes! Schaling voegt een stuk proces toe, het voegt complexiteit toe. Dat kan leiden tot stroperigheid, bureaucratie en meer fouten. Voer geen uitgebreid SAFe-proces met alle toeters en bellen in voor slechts drie teams. Kies in zo’n geval voor een paar simpele praktijken.

Samenstelling van de teams

Denk zorgvuldig na over de samenstelling van je teams. Deel het werk zo op dat je afhankelijkheden tussen teams minimaliseert. Voor dat werk stel je vervolgens teams samen (of beter, je laat de teams zichzelf formeren). Belangrijk is ook hoe die teams met elkaar interacteren. Wat zijn hun interfaces (technisch en sociaal!)? Het boek Team Topologies (https://teamtopologies.com/book) geeft hierbij veel waardevolle inzichten.

Het voorkomen van afhankelijkheden is altijd een goed idee. Afhankelijkheden die er niet zijn hoef je ook niet te managen. Je hoeft daar ook geen extra proces voor in te richten. Het blijft simpeler. De inzichten uit Team Topologies helpen afhankelijkheden te beperken en te managen.

Scrum Accountabilities

Door schaling is dus een complexer proces gevraagd. Dat betekent dat rollen veranderen en vaak ook nieuwe rollen worden toegevoegd. Laten we eerst eens kijken naar de Scrum accountabilities (rollen). Verschillende schalingsmethodieken maken hier andere keuzes.

Je kunt een Scrum Master per team houden (we kennen in Nederland vaak de dubbelrol Scrum Master/ Developer) of een dedicated Scrum Master voor meerdere teams hebben. Soms is behoefte aan een soort Chief Scrum Master voor een aantal samenwerkende teams (zoals de SAFe RTE). Voor de Product Owner geldt hetzelfde. Een Product Owner per team (SAFe)  of een voor meerdere teams (LeSS, S@S). Met weer een Product Owner voor een groter geheel (Chief Product Owner of productmanager, afhankelijk van de methode). 

Scrum Events en Artifacts

Voor Events geldt eigenlijk hetzelfde, er zijn meerdere opties. In ieder geval is het een must om Sprints te synchroniseren. Het is ook aan te raden om het werk van de teams te integreren vóór de Sprint Review. Niet-geïntegreerd werk is een vorm van verspilling (waste). Voor de Sprint Planning, Sprint Review en Sprint Retrospective is er een gezamenlijke en een team component. Je kunt er voor kiezen die events gezamenlijk, per team of beiden te doen. Ook hier kiezen methodieken weer verschillende oplossingen. Voor de Product Backlog, DoD en DoR geldt hetzelfde.

My way

Mijn aanpak bij schalen is: begin simpel. Voeg praktijken uit schalingsmethodieken toe om concrete problemen op te lossen. Deze methodieken zijn gereedschapskisten waaruit je kunt putten en wat werkt hangt af van de context. Behalve de aanpassingen aan het Scrum proces die hier kort de revue zijn gepasseerd bevatten die gereedschapskisten nog veel meer nuttige praktijken. Gebruik voortschrijdend inzicht, experimenteren, trial and error om uit te vinden wat werkt. En blijf aandacht besteden aan de basis, de agile mindset. Praktijken ondersteunen die basis en kunnen helpen die te ontwikkelen.

Welke praktijken ik vaak gebruik? Onderstaand lijstje gebruik ik regelmatig bij klanten met schaling vraagstukken. Daarnaast gebruik ik altijd wel inzichten uit Team topologies.

• PI planning (SAFe). Een planning op wat langere termijn, zoals een kwartaal. Ik noem het ook wel kwartaalplanning. Teams maken een prognose voor die periode. Niet met het detail van een Sprint Planning maar grover, aan de hand van doelen van de Product Owner. Het helpt om een helder doel op wat langere termijn te hebben. Dat geeft focus. Een kwartaal Review vóór die planning geeft een mooi overzicht wat de afgelopen periode is bereikt. Dit kan ook helpen stakeholders te betrekken die niet iedere 2 weken op de hoogte hoeven te worden gebracht, maar wel aangehaakt willen blijven.
• PO sync (SAFe). Product owners komen bij elkaar, bij het bord met het werk en de afhankelijkheden. Ze bespreken afhankelijkheden en risico’s. 
• Gildes (Spotify). Een gilde bestaat uit mensen met interesse in een bepaald vakgebied, bijvoorbeeld automatisch testen, front-end development of architectuur. Teamleden uit verschillende teams komen bijvoorbeeld iedere 2 weken bij elkaar om kennis te delen of ontwikkelen.
• Bazaar Sprint Review (LeSS). In LeSS is er een gezamenlijk deel van de Sprint Review waarin de highlights worden gereviewed. Daarna zit ieder team apart voor een review van meer specifieke details. Dat kan in een soort bazaar format. Veel stakeholders zijn maar in het werk van een of twee teams geïnteresseerd en kunnen dan meer de diepte in gaan
• observer (LeSS). Iemand uit een ander team die meeluistert bij de Daily Scrum
• traveler (LeSS). In een team dat complexe technologie ontwikkelt die andere teams gaan gebruiken loopt een teamlid een Sprint mee met een ander team om ze te leren hoe het werkt en te zien waar men in de praktijk tegenaan loopt.

Tot slot

Schalen maakt het werk complexer. Houd het zo eenvoudig mogelijk. Blijf leren en gebruik frameworks als inspiratie — niet als voorschrift. Er is meer dan SAFe!

Welke praktijken werken voor jou het best?

Naar het overzicht