Hoe blijf je Agile met meer dan 20 productteams?

Hoe blijft je Agile als het aantal teams dat software ontwikkelt toeneemt? Als je organisatie groeit en de complexiteit toeneemt, lijkt deze vraag belangrijker dan ooit. In dit blog deelt onze consultant Jeroen van Barneveld, momenteel aan de slag als productmanager bij Essent, zijn praktijkervaringen met Scaling Agile.

Omgaan met de steeds sneller veranderende werkelijkheid en omgeving blijft een uitdaging, maar we zijn een stuk opgeschoten sinds de introductie van Agile in de softwareontwikkeling. Projecten zijn minder groot en softwareontwikkeling is meer klant- of gebruikersgericht en iteratief, geënt op flexibiliteit en samenwerking. Maar een uitdaging die nog altijd bestaat, is het opschalen van Agile.

Het opschalen van Agile-methodieken in grote bedrijven kan complex en uitdagend zijn, vooral wanneer meerdere productteams betrokken zijn. Zonder een gestructureerd framework krijg je te maken met coördinatieproblemen en een gebrek aan samenhang tussen teams. Het resultaat? Projectvertragingen, vaak veroorzaakt door (onvoorziene) afhankelijkheden en miscommunicatie. Deze problemen onderstrepen het belang van het professionaliseren van Agile werkwijzen op grote schaal om efficiëntie en effectiviteit te waarborgen.

Scaling Agile helpt om de Agile-principes toe te passen binnen grote organisaties met veel productteams. Er zijn verschillende frameworks en methodieken die hierbij kunnen helpen. Een bekende keuze is SAFe, het Scaled Agile Framework, maar er zijn ook andere opties zoals LeSS (Large Scale Scrum), Nexus en het Spotify Model.

SAFe, of het Scaled Agile Framework, biedt een structuur die helpt om samenhang en efficiëntie tussen teams te waarborgen. Jeroen van Barneveld: “In mijn huidige opdracht bij Essent heb ik veel ervaring opgedaan met SAFe en gezien hoe het structuur en samenhang kan brengen in een complexe omgeving.” Hier zijn enkele voordelen en nadelen van SAFe:

• Duidelijke structuur en gelaagdheid: Essentieel voor effectieve besturing op grote schaal, en het prioriteren van werk in de verschillende lagen. SAFe helpt complexe projecten beheersbaar te maken en faciliteert samenwerking tussen teams, maar biedt ook handvatten voor prioritering van het complete veranderportfolio (op basis van Lean Portfolio Management), gekoppeld aan OGSMs, KPI’s en budgetten.
• Duidelijke rollen: SAFe beschrijft een aantal cruciale rollen die van belang zijn voor de besturing van de teams. Denk hierbij aan uiteraard de (DevOps) engineers, Product Owner, Scrum Master en Solution Architect. Maar ook de Product Manager, Release Train Engineer, en System Architect, met daarnaast business vertegenwoordiging in de rollen van Business Owners en Epic Owners.
• Voorspelbaarheid door program increments: SAFe introduceert een vaste ritmiek van Program Increments van 3 maanden (in het geval van Essent) met bijbehorende PI Planning Events; big room planning events waarbij alle teams en stakeholders samenkomen voor duidelijke afstemming en begrip van verwachtingen, en het plannen van het werk voor het komende Progam Increment.
• Continue verbetering: SAFe implementeert mechanismen gebaseerd op de plan-do-check-act cyclus, wat leidt tot continue verbetering binnen de organisatie.

• Wendbaarheid: SAFe introducteert door de Program Increments een zekere mate van voorspelbaardheid, die door business stakeholders graag gezien wordt, maar die afbreuk doen aan de wendbaarheid binnen een PI. Een trade-off die bewust gemaakt wordt, maar ook enige rigiditeit tot gevolg heeft.
• Complexiteit van implementatie: Het implementeren van SAFe kan complex en tijdrovend zijn, vooral in organisaties die nog niet bekend zijn met Agile werken.
• Risico van bureaucratisering: Er is een risico dat de strikte structuur van SAFe kan leiden tot bureaucratie en minder flexibiliteit op teamniveau.
• Overhead: Het implementeren en werken volgens SAFe kost de nodige effort en coördinatie, die echter een logisch gevolg is van de afhankelijkheden die ontstaan bij het opschalen in aantal Agile teams.

Bij Next Ground hebben we ervaring met verschillende methodieken voor het opschalen van Agile, waaronder SAFe. We zien SAFe als een waardevol framework, maar niet als de enige manier of een ‘one size fits all’ oplossing. Het is belangrijk om per organisatie en per situatie te bekijken welke methodiek het beste past. Maatwerk is hierbij essentieel, net als het goed bepalen en vastleggen wat de doelen en inrichtingsprincipes zijn.

Staat voorspelbaarheid of wendbaarheid voorop, of is het een mix? Is autonomie van de teams (en Agile Release Trains) het grootste goed, of gaat het om samenwerking en managen van afhankelijkheden als die ontstaan? En is de drijvende kracht achter scaling Agile vooral de IT-organisatie, is het juist een business gedreven beslissing of gezamenlijke missie? Dit soort vragen zijn essentieel om met elkaar te doorleven en te beantwoorden, voor de implementatie van een framework als SAFe wordt overwogen.