Scaling agile: Door de tribes, squads en guilds het bos niet meer zien

Michael Klazema
23 feb 2016

Als je agile principes op grote schaal in je organisatie wilt toepassen, loop je tegen verschillende uitdagingen aan. Bijvoorbeeld het kiezen van een framework dat past bij jouw type organisatie. Makkelijker gezegd dan gedaan. Er lijkt namelijk iedere dag weer een nieuw model bij te komen, met ieder hun eigen terminologie.

Kies je voor de squads en tribes van het Spotify organisatiemodel of kan je beter de richtlijnen van Scrum of Scrums volgen? Het is belangrijk te ontdekken aan wat voor type framework de organisatie behoefte heeft. Sommige methoden zijn namelijk bij uitstek geschikt voor grote organisaties, terwijl je andere juist beter in kleinschalige ondernemingen kunt gebruiken. Daarnaast richt het ene framework zich meer op principes, terwijl het andere een volledige blueprint voorlegt en de werkwijze tot in detail beschrijft.

Ondanks deze verschillende aanpakken is het wel mogelijk de frameworks op een aantal aspecten met elkaar te vergelijken. Onder andere Ebba Kraemer van Hansoft ontwikkelde hiervoor een model, waarvan de basis bestaat uit een aantal kernvragen.

1. Zijn er veel afhankelijkheden tussen de ontwikkelteams (intradependencies)?

Sommige teams zijn bijvoorbeeld afhankelijk van elkaar voor de release van nieuwe concepten of aanpassingen, terwijl anderen onafhankelijk van elkaar een release in gang kunnen zetten.

2. Zijn er veel afhankelijkheden tussen de ontwikkelteams en de rest van de organisatie (interdependencies)?

Soms zijn teams sterk afhankelijk van de projecten en tijdslijnen van andere delen van de organisatie, bij weinig afhankelijkheden werken zij vaak los van bestaande processen.

3. In welke mate is het noodzakelijk dat de ontwikkelteams zelf een hoge mate van creativiteit toevoegen aan de oplossing(en)?

Dit heeft betrekking tot de vrijheid en verantwoordelijkheid die het ontwikkelteam krijgt.

Naast deze drie aspecten zien we ook grote verschillen in de mate waarin het framework goed past binnen zeer grote organisaties, zoals banken, verzekeraars, energiebedrijven en telecomproviders. Sommige modellen geven wel antwoord op de vraag hoe een aantal teams samen kunnen werken als ze aan één product werken, maar bieden geen houvast als een organisatie gelijktijdig in meerdere markten actief is met een groot aantal producten of diensten. Tot slot is ook de complexiteit van het product bepalend voor het framework. Soms zijn bepaalde kernproducten of -diensten heel complex of juist niet; de organisatievorm zou zich daarbij aan moeten sluiten.

Hoe scoort het framework SAFe op deze criteria?

SAFe is wellicht het meest bekende en meest gestructureerde framework voor het inzetten van agile op grote schaal. Het framework gaat uit van drie organisatieniveaus: portfolio, program en team. Het beschrijft voor ieder niveau rollen en processen. Daarnaast is het framework van SAFe constant in ontwikkeling. Begin dit jaar ging de 4.0 versie van het framework live.

De nadruk ligt in eerste instantie op samenwerking en afstemming op enterpriseniveau, met als belangrijkste onderdeel een bedrijfsbrede, meerdaagse release planningsessie die veelal ieder kwartaal plaatsvindt. Dit is het antwoord van SAFe op één van de kernvraagstukken van scaling agile: hoe stem je in een organisatie met veel agile werkende teams de afhankelijkheden tussen verschillende teams af? En hoe zorg je vervolgens voor de aansluiting met de business strategie? Deze planningsessie is een soort Scrum of Scrums, alleen dan met alle teamleden en met meer centrale regie over welke teams welke prioriteiten oppakken.

SAFe is dus zeer geschikt in situaties waarin...

  • Scrum of Scrums in combinatie met één product owner niet meer volstaat. SAFe biedt structuur bij het opschalen van de agile organisatie, met name als het de IT organisatie overstijgt. Dit framework geeft bovendien meer houvast op het niveau van programma management dan LeSS of Spotify.
  • Er behoefte is aan een betere voorspelbaarheid met betrekking tot de inhoud van releases. Ieder team neemt namelijk voor een aantal sprints een deel van de backlog voor zijn rekening en in principe is de scope van de release daarmee vastgezet.
  • Er behoefte is aan een geleidelijke invoer van het model. Anders dan het LeSS of Spotify model, start SAFe namelijk vaak met een enkel strategisch speerpunt van de organisatie.
  • Nu nog erg in silo’s wordt gewerkt. Deze aanpak past dus vaak goed bij grote, meer traditionele organisaties.
  • De organisatie nu nog moeite heeft twee keer per jaar een substantiële verbetering van hun producten of diensten in de markt te lanceren.

En minder geschikt in situaties waarin...

  • Er behoefte is aan agility van de organisatie en de teams. Een deel van de agility gaat namelijk verloren, omdat voor een aantal sprints wordt vastgelegd welk team verantwoordelijk wordt voor een aantal items op de backlog. Zaken die af zijn, gaan minder vaak dan bij andere werkvormen onmiddellijk live, maar wachten vaak tot de lancering die elk kwartaal staat gepland. Dat betekent niet dat geen ‘continuous delivery’ mogelijk is (IT taal voor continue verbetering aan de site maken) of plaatsvindt binnen SAFe, maar meer dat er voor bepaalde features of user stories afhankelijkheden kunnen zijn waardoor iets moet wachten tot het einde van de release.
  • De organisatie al in staat is om minimaal maandelijks nieuwe software of online systeemcomponenten te lanceren. Het gaat hier dan niet om cosmetische verbeteringen aan de user interface, maar daadwerkelijk nieuwe functionaliteit. Dan biedt SAFe misschien teveel structuur.

Onze blogs direct in je mailbox?

Interessant? Laat een reactie achter