Agile XL? Kies dan wel het juiste framework

Veel organisaties staan onder druk om sneller in te spelen op veranderingen. Of het nu gaat om nieuwe digitale diensten die worden geïntroduceerd of de implementatie van nieuwe technologie of IT-systemen. De gemene deler is dat zowel consumenten als eindgebruikers steeds hogere eisen stellen aan de IT-afdeling om snel te leveren. Traditionele softwareontwikkelmethodes bieden te weinig flexibiliteit om snel nieuwe diensten en functionaliteit op te leveren. Dit verklaart waarom bedrijven de afgelopen jaren op zoek zijn gegaan naar een alternatief en het werken op basis van agile principes hebben omarmd. Het meest toegepaste agile framework voor softwareontwikkeling is scrum.

Scrum werken

Scrum is een projectmatige en flexibele manier van werken met als doel sneller resultaat te bereiken en de maximale waarde te leveren als team. Binnen dit framework zijn vaste rollen en processen gedefinieerd om in verschillende stappen (sprints) en evaluaties (sprintreviews) de juiste prioriteiten te definiëren, optimaal gebruik te maken van de expertise van de verschillende teamleden en zoveel mogelijk van elkaar te leren. Een belangrijk uitgangspunt van scrum is dat het team zelfsturend is en verantwoordelijk is voor de planning en het eindresultaat.

Scrum werken en de schaalbaarheidsuitdaging

Scrum teams zijn zelf-organiserend en leveren in korte iteraties waardevolle softwareoplossingen op. Deze teams dragen de volledige verantwoordelijkheid voor het leveren van waardevolle software. Dat maakt scrum teams veel wendbaarder en sneller dan traditioneel werkende teams. Organisaties kunnen zo veel sneller inspelen op veranderingen. Maar dit is alleen mogelijk als het scrum team beschikt over de expertise en het mandaat dat nodig is voor het leveren van één volledige softwaredienst, zonder afhankelijk te zijn van andere teams of experts. Maar wat nu als je product te groot is voor deze kleinschalige manier van werken?

Stel, je bent een grote financiële dienstverlener met een breed portfolio aan digitale platformen en diensten voor verschillende doelgroepen. Deze diensten moet je continu vernieuwen en zijn veelal onderling gekoppeld. Je hebt dan meerdere teams nodig om de hoeveelheid werk met de gewenste snelheid te kunnen leveren. Hoe borg je dan de samenhang tussen deze teams?

Het schalen van scrum is een uitdaging waar steeds meer organisaties mee te maken krijgen. Ergens in het proces ontstaat een punt waarbij het noodzakelijk is dat meerdere teams samen één dienst gaan leveren. Dan is het bewaken van de onderlinge samenhang noodzakelijk. Organisaties krijgen dan behoefte aan een ander besturingsmodel. Een besturingsmodel waarbij zij de voordelen van scrum niet willen verliezen.

Als antwoord op deze behoefte zijn door verschillende partijen diverse frameworks voor het schalen van agile en scrum ontwikkeld. Voorbeelden hiervan zijn: Het Spotify-model, Nexus, Disciplined Agile Delivery, Large Scale Scrum (LeSS) en het Scaled Agile Framework (SAFe). LeSS en SAFe zijn binnen Nederland de bekendste en meest toegepaste frameworks voor het schalen van scrum. Hoewel niet alle bedrijven zich hiervan bewust zijn, is het belangrijk om een duidelijke keuze te maken voor het framework dat het beste bij de organisatie past. Een onbewuste of ondoordachte keuze kan namelijk grote gevolgen hebben voor het softwareontwikkelproces.

Scrum als basis voor SAFe en LeSS

SAFe en LeSS hanteren beide de basisprincipes van scrum, met scrum teams bestaande uit een product owner, een scrum master en een multidisciplinair team van bijvoorbeeld front-end en back-end developers, een ontwerper en interactiedesigner. Hoewel er ook vanuit technisch perspectief verschillen te benoemen zijn tussen SAFe en LeSS, is het vooral interessant om te kijken naar de impact van deze frameworks op de manier van werken en gevolgen voor de organisatie. Hierin zijn de verschillen tussen beide benaderingen namelijk fundamenteel.

Scaled agile framework (SAFe)

Binnen het SAFe framework werken de ontwikkelteams conform het scrum framework. Belangrijk verschil met scrum is de rol van de product owner. De product owner is binnen SAFe niet eind verantwoordelijk voor het maximaliseren van de klantwaarde. Deze verantwoordelijkheid is op een hogere bestuurslaag bij de business owners belegd.

Het SAFe framework introduceert boven de ontwikkelteams één of meerdere bestuurslagen. Hoeveel lagen dit zijn is afhankelijk van de gekozen variant. Het SAFe framework definieert vier verschillende varianten: Essential SAFe, Portfolio SAFe, Large Solution SAFe en Full SAFe. Essential SAFe is het meest eenvoudige framework met één bestuurslaag en Full SAFe is het meest uitgebreide framework met drie bestuurslagen. Elke bestuurslaag introduceert nieuwe processen, technieken en rollen om het schalen in een bepaalde organisatievorm te ondersteunen. Denk daarbij aan organisatievormen zoals: programma management, solution management en portfolio management. Dit zijn organisatievormen die aansluiten bij de manier waarop grote organisaties traditioneel softwareontwikkelprojecten beheersen.

Het SAFe framework is tot in detail uitgewerkt in proces- en rolbeschrijvingen en wordt ondersteund met hulpmiddelen zoals templates en richtlijnen. Daarnaast biedt dit framework uitgebreide ondersteuning voor de implementatie van de nieuwe werkwijze. Denk daarbij aan draaiboeken, trainingen en implementatiecoaches.

Large-Scale Scrum (LeSS)

Het LeSS framework vertoont grote gelijkenissen met het scrum framework. Het belangrijkste verschil is dat de teams de sprintplanning en de retrospective in twee stappen uitvoeren. Dat begint met een gezamenlijke sprintplanning die rekening houdt met alle onderdelen en afstemming van het geheel. Daarna voert elk scrum team zijn eigen sprintplanning uit voor het deel van het werk waarvoor zij verantwoordelijk zijn.

De teams sluiten de sprints vervolgens af met een gezamenlijke sprintreview. De retrospective (evaluatie van wat beter kan) voeren de teams eerst individueel uit en daarna volgt nog een teamoverstijgende retrospective bijeenkomst. Daarnaast werkt het LeSS framework met één overall owner die overlegt met de teams, de prioriteiten bepaalt en de visie op het product inbrengt vanuit zijn of haar expertise. Het implementeren van het LeSS framework heeft een grote impact op de organisatie. Dit is het gevolg van een belangrijk uitgangspunt van LeSS: reduceer de complexiteit van de organisatie zoveel mogelijk.

Het doorvoeren van dit soort maatregelen heeft een grote impact op de organisatiestructuur en maakt veel coördinerende rollen overbodig. Een ander belangrijk LeSS principe is dat er gestart wordt met een zo minimaal mogelijk proces. Alleen scrum met een aantal aanpassingen om de samenwerking tussen meerdere teams te faciliteren. Vervolgens passen de teams op basis van de opgedane ervaring het proces aan. LeSS biedt geen kant-en-klare procesbeschrijvingen zoals SAFe. LeSS biedt wel een aantal principes om de organisatie vorm te geven en een grote bibliotheek met technieken waarmee teams kunnen experimenteren.

Het beste framework

De vraag welk framework voor het schalen van scrum het beste past is sterk afhankelijk van een organisatie. Het blijft uiteindelijk maatwerk. Bij het selecteren van een framework is het in ieder geval belangrijk om de volgende overwegingen mee te nemen:

  • Het SAFe framework bevat samenvangende procesbeschrijvingen die worden ondersteund met een gedetailleerde, uitgewerkte set van technieken en rollen. Ook biedt SAFe veel gestandaardiseerde hulpmiddelen die de implementatie van SAFe ondersteunen. Dat geeft houvast en duidelijkheid.
  • Het LeSS framework is zeer geschikt voor organisaties die zoeken naar een framework dat ze helpt om radicaal afscheid te nemen van de oude organisatie structuur. De organisatiestructuur moet op de schop en elke bestuurslaag en coördinerende rol staat bij het implementeren van LeSS ter discussie.
  • Welk framework je als organisatie ook kiest, het ultieme recept voor het schalen van scrum teams bestaat niet. De nieuwe aanpak moet passen bij de organisatiestructuur en bedrijfscultuur. De grootste valkuil bij het schalen van scrum teams is niet (bewust) kiezen.