Redactie: Paul Beving
Auteur: Gerben de la Rambelje ● g.delarambelje@maxmin.eu
De term Scaling Agile zie je de laatste tijd regelmatig voorbijtrekken via allerlei kanalen. De vraag is: wat is het eigenlijk? Afgelopen donderdag 17 januari werd bij TestNet de thema-avond ‘Scaling Agile’ gehouden om hier meer duidelijkheid over te verschaffen. Han Duisterwinkel, consultant bij CGI, mocht het spits afbijten. De eerste vraag van Han aan het publiek was: ‘wat is Scaling Agile en wanneer wordt dit toegepast?’ Er kwamen verschillende antwoorden terug, één daarvan was dat het wordt toegepast wanneer vijf tot tien Scrum-teams in een organisatie actief zijn, wat volgens Han een goed antwoord was. Volgens Han kunnen we de volgende definitie aan Scaling Agile toekennen: ‘het op grote schaal toepassen van Lean Agile principes in een organisatie’. Kennelijk ontstaat bij een groeiend aantal Scrum-teams in een organisatie, vaak ook de behoefte of noodzaak de werkzaamheden tussen deze teams te coördineren, om zo het eindresultaat van alle teams tezamen te optimaliseren.
Om dieper op de materie in te gaan, behandelde Han een aantal frameworks waarmee je Scaling Agile kan toepassen, zodat je als organisatie verder kan groeien.
Scrum of Scrums
De ‘Scrum of Scrums’ is een opzet, waar veel organisaties al mee werken. Met behulp van Scrum of Scrums gaat elk afzonderlijk Scrum-team op de Agile manier te werk. Het enige verschil is dat er per team één persoon wordt aangewezen die het gehele team vertegenwoordigt bij de Scrum of Scrums meeting. Tijdens deze bijeenkomst komen alle vertegenwoordigers van de teams samen om zo het werk van alle Scrum-teams gezamenlijk te coördineren.
Frequentie Scrums of Scrums:
- 2 à 3 keer per week;
- Alleen teamzaken worden besproken;
- Behandel vier vragen;
- 15-60 minuten maximaal.
Scrum of Scrums verder uitgelegd: https://www.youtube.com/watch?v=JmtanE5O2fY (Scrum of Scrums)
Spotify model
Het Spotify model is een vreemde eend in de bijt, omdat het geen framwork is. De muziekdienst Spotify is in 2008 met Scrum gestart en is daarmee verder gegaan. Dit heeft uiteindelijk geleid tot het ‘Spotify model’. Dit model wordt inmiddels door veel organisaties gebruikt als blauwdruk om te kunnen opschalen in een Agile omgeving.
Uitgangspunten Spotify model:
- Agile boven Scrum;
- Principles boven Practices;
- Servant boven Master;
- Tribes, Squads, Chapters, Guilds;
- Minimaliseer grote projecten;
- Teams zijn autonoom, maar hebben wel dezelfde doelstelling.
Spotify model verder uitgelegd:
- https://www.youtube.com/watch?v=dtzPtFi8jiQ (Spotify Engineering Culture part 1 Agile Enterprise Transition with Scrum and Kanban)
- https://www.youtube.com/watch?v=v6gQuVCHJ1Q (Spotify Engineering Culture part 2)
Han Duisterwinkel
LeSS Framework
LeSS is gewoon Scrum met een aantal speerpunten:
- Klant staat centraal;
- Focus op product;
- Meer met minder: wel opschalen, maar niet meer rollen, T-shape komt hier om de hoek kijken;
- Meer leren;
- Meer verantwoordelijke teams;
- Definition of done is voor alle teams gelijk.
LeSS is bedoeld voor twee tot en met acht teams. Met meer dan acht Scrumteams kun je LeSS Huge gebruiken. Dit is overigens een aanvulling op LeSS, met extra regels en procedures. Een belangrijk punt dat LeSS wel aanstipt en Scrum niet, is dat er een constante communicatiestroom moet zijn tussen de verschillende teams en alle betrokkenen, die een rol spelen bij de ontwikkeling van het product. Denk hierbij aan development teamleden, product owner maar ook stakeholders. Er wordt daarom gestimuleerd om zoveel als mogelijk ‘walk en talk’ sessies te doen. Dan hoef je niet al die onnodige overleggen te hebben.
De periodieke sprintplanning bestaat uit twee delen:
- Sprintplanning I -> over meerdere teams heen
- Sprintplanning II -> per team, waarin Sprintplanning I wordt meegenomen / besproken
Focus op:
- Test Driven Development(TDD);
- Unit testen;
- Automated testen.
LeSS Framework verder uitgelegd: https://www.youtube.com/watch?v=cvz4364pC0g (LeSS Complete Picture, 3-minute introduction to Large Scale Scrum)
SAFe framework
Het SAFe framework is op dit moment veruit het meest gebruikt door organisaties (28%), die willen opschalen met Agile. De herkomst van het SAFe framework komt van Rationial Unified Process (RUP). Het SAFe framework is een verzameling van Agile praktijken die gebruikt worden op team-, project- en portfolioniveau. Op teamniveau lijkt het erg op Scrum. Op project- en portfolioniveau heeft SAFe een uitgebreide set aan hulpmiddelen om ervoor te zorgen dat de prioriteiten van de business goed vertegenwoordigd zijn. Hiervoor introduceert SAFe diverse rollen en verantwoordelijkheden, zoals onder andere: Portfolio Manager, Release Manager, Enterprise Architect en Release Architect.
SAFe onderkent negen Lean-Agile principes:
- Neem je besluiten op basis van economische feiten;
- Pas de systeemtheorie toe;
- Veronderstel veranderlijkheid, houd je opties open;
- Ontwikkel incrementeel met korte, geïntegreerde leercycli;
- Hanteer integratiepunten om het product objectief te beoordelen;
- Maak zichtbaar dat er gewerkt wordt met kleine, in aantal begrensde, batches;
- Hanteer een standaard cadans en synchroniseer de werkzaamheden;
- Spreek de intrinsieke motivatie van de kenniswerkers aan;
- Decentraliseer besluitvorming.
Op het programmaniveau zien we de volgende events: Program Increment (PI) Planning, Scrum of Scrums, PO Sync, System Demo, Release Management, Inspect and Adapt en PI Planning Preparation. Verder vinden we specifieke events terug op valuestream- en portfolioniveau.
Eén keer in de vijf sprints wordt een PI-planning georganiseerd, waar alle Scrum-teams bij aanwezig zijn. Dit duurt twee dagen en hier worden alle geplande wijzigingen voor de komende sprints besproken.
SAFe Framework verder uitgelegd: https://www.youtube.com/watch?v=tmJ_mJw8xec (SAFe 4.0 in 5 minutes)
SAFe framework implementatie bij APG
In het tweede gedeelte van de thema-avond werden we verder meegenomen in de wereld van het SAFe framework, door Edwin van Loon en Rebekka van Gent, beiden werkzaam bij APG. Edwin is QA/testmanager van GPS dat de drie grootste fondsen vertegenwoordigt binnen APG. Rebekka van Gent is tester bij ‘mijnFondsen’, een frontend applicatie.
In de rol van QA/testmanager is Edwin vanaf 2014 verantwoordelijk voor het QA gedeelte van de implementatie van het SAFe framework binnen GPS. Bij GPS zijn 13 ontwikkelteams en 22 testprofessionals werkzaam. Daarnaast zijn er ook nog 14 testprofessionals ‘Shared services’ werkzaam.
Waarom er is besloten om het SAFe framework te gaan implementeren bij APG? Edwin geeft aan dat de volgende argumenten hieraan ten grondslag liggen:
- APG moet voldoen aan wet- en regelgeving (AFM en DNB);
- Meerdere teams werken aan 1 systeem (gezamenlijke source çode base);
- Systeem overstijgende testen (value streams).
Omdat er bij APG Systeem overstijgende ‘value streams’ zijn, hebben ze de Large solution van SAFe geïmplementeerd. Vier keer per jaar wordt een PI planning georganiseerd, die ze in één dag proberen af te handelen, in plaats van de voorgeschreven twee dagen. Goede afstemming is heel belangrijk met alle deelnemende Scrum-teams, tussen PO en stakeholders. Verder worden er twee à drie releases per kwartaal uitgebracht.
Testen bij APG binnen het SAFe framework
Edwin geeft aan dat het uitgangspunt van testen binnen SAFe bij APG is: ‘testen moet beter, sneller en goedkoper’.
Testen binnen het SAFe framework heeft bij APG een centrale rol. De testverantwoordelijkheid ligt volledig bij de Scrum-teams, daarbij wordt de acceptatietest ook meegenomen. Edwin gaf aan dat de acceptanten zo snel mogelijk worden aangelijnd in het Scrum-proces. Om het testproces goed te kunnen beheren wordt de tool HP ALM gebruikt en wordt onder andere UFT ingezet voor het automatiseren van de testgevallen. Interface-testen worden met SOAP UI gedaan. Bamboo en JUnit worden ingezet om unit-tests te schrijven.
Edwin van Loon en Rebekka van Gent
Metrics zijn belangrijk
Om het SAFe framework goed te laten functioneren, zijn metrics heel erg belangrijk. Dashboard zijn continu in ontwikkeling om analyses snel te kunnen maken. De volgende metrics zijn onder andere ontwikkeld:
- Defects meten: Defect Detection Percentage (DDP%);
- Testen: Unit coverage;
- Testautomation: percentage geautomatiseerde regressietesten.
Een verhaal uit de praktijk
Rebekka van Gent is een zeer ervaren IT’er, de laatste zeven jaar actief als tester. De stream waarin zij werkzaam is, werkt ook volgens het SAFe framework, alleen is dit een andere omgeving/organisatie dan GPS. Rebekka werkt vanuit MijnFonds heel nauw samen met GPS, voor het uitbrengen van releases. In de praktijk blijkt dat er veel coördinatie nodig is om releases met succes te kunnen uitbrengen. Hierin is een cruciale rol voor de testers weggelegd, die vaak alle zeilen moeten bij zetten om de testomgevingen up-to-date te houden. Rebekka geeft aan dat alertheid en diepgaande kennis van het applicatielandschap nodig is om opleveringen van frontend en backend soepel te laten verlopen. Afstemming tussen GPS en MijnFonds is heel belangrijk. Deze is (gedeeltelijk) opgelost door:
- De testers van MijnFonds te laten deelnemen aan de Community of Practice meetings van GPS;
- De Product Owner te laten deelnemen aan het Productowner Management Team (van GPS);
- De PlanningsIncrement dag van GPS.
Edwin geeft aan dat ze in de praktijk ertegen aan lopen dat MijnFonds en GPS niet in dezelfde Scaled omgeving zitten. SAFe biedt dan niet de oplossing voor alles. Volgens Edwin zullen er in grotere organisaties meerdere Scaled omgevingen ontstaan en daarin moeten keuzes gemaakt worden. Hierin kun je nooit de volledige keten en onderliggende systemen in één scaled omgeving krijgen en moet er ook een Scaled overkoepelende afstemming plaatsvinden.
Samenvatting van Scaled Agile binnen APG
Voor Edwin is de samenvatting van Scaled Agile binnen APG, dat QA en testen op alle niveaus in SAFe zijn vertegenwoordigd:
- Team (als test professional);
- Systemteam (ondersteuning test automatisering en Non functional testing);
- Community of Practice (ontwikkeling en afstemming rondom WoW op het gebied van testen);
- Shared services (algemene diensten op het testen – inclusief ontwikkeling);
- Metrics (metrieken op het gebied van testen – basis voor continu verbeteren);
- Release niveau (release train) – operationeel QA en testmanagement rondom releases – met name deze is leuk om te noemen, hier hebben we de test manager ‘opnieuw’ geïntroduceerd (maar wel met andere verantwoordelijkheden).
Tot slot
Het was een reuze interessante avond bij TestNet, met grote dank aan Rebekka van Gent, Edwin van Loon en Han Duisterwinkel. Door de perfecte introductie van Han sloot het verhaal van Edwin en Rebekka naadloos aan en werd het een compleet verhaal over Scaling Agile. Welk framework het beste gebruikt kan worden, is altijd weer per type organisatie en per situatie verschillend. Voor APG werkt het SAFe framework heel erg goed en zijn ze goed op weg om verder te kunnen opschalen en verbeteren om op die manier betere resultaten te halen. Feit is dat goede interactie tussen teamleden (Agile Manifesto) niet genoeg is, als er meerdere Scrum-teams in een organisatie actief zijn. Om het geheel beter te laten functioneren is de interactie en harmonie tussen teams, net zo belangrijk. Hoe dat moet? Daar zijn management boeken vol van geschreven. Wie weet hoe dat het beste kan, mag het zeggen.
Meer informatie
Voor meer informatie verwijs ik naar de volgende presentaties: