De specifieke kenmerken van het werken van een Agile-team in SAFe ten opzichte van Scrum in de praktijk

Na publicatie onder vrienden van het eerste artikel over Burn Down Chart, was de eerste vraag die in de reacties werd gesteld: "Het zou interessant zijn om meer te weten te komen over jullie ervaring met SAFe". Daarom zal ik in dit artikel proberen de specifieke kenmerken van het werken in SAFe ten opzichte van Scrum in onze praktijk toe te lichten. Ik pretendeer zeker niet de waarheid in eerste instantie te bezitten en zal blij zijn met alle correcties en verduidelijkingen van collega's.

Eerst som ik puntsgewijs het belangrijkste op dat het werken in SAFe naar mijn mening onderscheidt van SCRUM.

• Increment in Scrum en Program Increment in SAFe
• ART - Agile Release Train
• Aantal samenwerkende teams
• PIPE
• SOS
• PO - geen eigenaar van het bedrijf
• RTE
• De vijfde sprint voor leren
• System Demo

Increment in Scrum en Program Increment in SAFe. Eigenlijk zijn het verschillende termen, maar het is gemakkelijk om in de war te raken, omdat niemand bij ons de term Program Increment gebruikt, iedereen zegt gewoon Increment - en dat is alweer een andere term, die in SCRUM wordt gebruikt. Maar over het algemeen lijken ze qua betekenis behoorlijk op elkaar, naar mijn mening. Increment in SCRUM - dat is in feite het huidige product + de geplande stories voor de sprint in voltooide staat (die de DOD van het team hebben doorstaan). Program Increment - dat is het tijdsinterval waarbinnen de trein (Agile Release Train) incrementele waarde aan productie levert. Qua duur is dat bij ons 4 sprints van 2 weken voor ontwikkeling en één sprint voor leren.

Agile Release Train - dat is een team van teams die werken aan één waardestroom. Wij noemen dat gewoon de trein, maar volgens het framework is het correct om dit "Solution" te noemen. In ons geval wordt deze regel niet volledig nageleefd en werken teams vaak aan verschillende producten vanuit technisch oogpunt, omdat de meeste businessfeatures complex worden geïmplementeerd en meerdere producten raken. Dat is vanuit technisch oogpunt. Maar ik ben ervan overtuigd dat iemand alle it-systemen als één product van het bedrijf beschouwt en dat is misschien zelfs juister.

Aantal samenwerkende teams is bij ons in SAFe aanzienlijk groter, in totaal wordt tot 125 personen in één trein aanbevolen. Wij hebben 3 treinen en niet in elke trein wordt deze regel nageleefd, er zijn treinen met meer dan 125 personen. SCRUM beschrijft niet hoe je met andere teams moet samenwerken, voor zover mij bekend, in tegenstelling tot SAFe, waar zeer duidelijke aanbevelingen hierover zijn. Het meest opvallende artefact daarvoor is naar mijn mening het Program Board.

Daarop worden de onderlinge verbanden tussen de teams van de trein weergegeven en al besprekend ervan vinden bij ons de wekelijkse Scrum Of Scrums (SOS)-bijeenkomsten plaats.

Ongeveer elke 2,5 maand (elke 5 sprints) vindt het evenement PIPE - Programm Increment Planning Event. Dat is wanneer alle gedistribueerde teams gedurende 2 dagen in één zaal samenkomen en hun werk voor de volgende 2,5 maanden plannen. Tijdens dit evenement ontstaan artefacten zoals bijvoorbeeld het Program board, waarop alle onderlinge afhankelijkheden van de teams voor elk van de treinen worden weergegeven; hierboven heb ik al laten zien hoe dat eruitziet. De taak van de Scrum Master van elk team bij dit evenement is het faciliteren van het identificeren van zoveel mogelijk afhankelijkheden, en vervolgens waar mogelijk het verwijderen ervan (door bijvoorbeeld competenties mondeling over te dragen van team aan team of door een afhankelijkheid van het ene team naar het andere over te hevelen, zodat het team autonoom zijn feature kan realiseren zonder van iemand afhankelijk te zijn). In de praktijk gebeurt dat bij ons ook zo. Eerst worden features gedecomponeerd in User Story, User Stories worden verdeeld over 4 sprints. Features worden op het Program Board geplaatst en de afhankelijkheden van andere teams worden weergegeven. Tijdens het evenement wordt dit besproken en bijgesteld.

SOS - Scrum Of Scrum. Dit evenement vindt één keer per week plaats, voor elke trein afzonderlijk. De Scrum Masters van alle teams van de trein komen online samen, het Program Board van de trein wordt getoond en de statussen van alle afhankelijkheden en features van de teams van de betreffende trein worden besproken. In feite is dit evenement nodig voor gecentraliseerde synchronisatie van de teams binnen de trein. Zoiets als een standup, maar één keer per week en niet voor het team, maar voor de Scrum Masters.

PO (Product Owner) - geen eigenaar van het bedrijf. Er is een Product Manager - die werkt met Business Owners van de betreffende bedrijfsrichtingen en in feite features aan de Product Owners uitdeelt. De Product Owner werkt al direct in het team - splitst features op in User Stories (in ons geval samen met het team) en splitst ze niet altijd op, maar we boeken voortdurend vooruitgang in die richting.

RTE (Release Train Engineer - treinmachinist. Scrum Master Scrum Master van Scrum Masters. Voert SOS-evenementen uit van zijn trein. Werkt samen met de Product Manager op feature-niveau. Faciliteert PIPE.

De vijfde sprint voor leren - ja, in tegenstelling tot Scrum is hier een hele sprint aan het einde van het increment voor het team gereserveerd voor leren. In de praktijk gebruiken we die in de eerste plaats voor het bijwonen van interne trainingen, onder andere over SAFe, maar niet alleen. Privécursussen en meetups proberen we waar mogelijk op deze tijd te plannen. Ook hebben we ontwikkelaars die hun stack gedurende de 5e sprint uitbreiden, zodat er een mogelijkheid is om iemands competentie in het team af te dekken (indien nodig achter de hand te hebben).

System Demo. Als resultaat van PIPE heeft elk team een lijst met doelen voor het increment en elk van deze doelen is door de Business Owner van de trein beoordeeld op een schaal van 10. Dit heet Business Value. Deze doelen zijn verdeeld in hoofd- en uitgebreide doelen. Hoofddoelen zijn doelen waarbij het team geen enkel risico ziet om ze te behalen. Uitgebreide doelen zijn doelen met risico's op het behalen ervan. Alle doelen zijn verplicht en de omvang van het werk wordt voor alle doelen gepland. Op de System Demo accepteert de Business Owner de resultaten van het werk voor het increment. Stel dat een team 3 hoofddoelen had met scores 10, 6, 8 en 2 uitgebreide doelen met scores 10, 3. Stel dat de Business Owner respectievelijk de volgende scores heeft gegeven: 8, 6, 4, 2, 0. Nu kan het percentage behaalde doelen worden berekend: voor 100% wordt de oorspronkelijke som van punten voor de hoofddoelen genomen, in ons geval is dat 10+6+8=24. De behaalde punten worden berekend met inachtneming van de uitgebreide doelen (d.w.z. 20 van de 24 heeft het team behaald), dus als resultaat is het percentage behaalde doelen van het team (20*100)/24 = 83,3%. Een normaal resultaat wordt beschouwd als het behalen van 80% tot 100%.

Voor het overige werken we volgens SCRUM. Nou ja, of bijna overal :) Wat onze ervaring betreft: ik kan zeggen dat, vanuit mijn standpunt, de evolutie duidelijk is. In een jaar tijd zijn de teams sterk gegroeid, ze zijn zelforganiserend geworden, sommige teams zijn inderdaad uit elkaar gevallen, maar ook daarin is een zekere evolutie zichtbaar. Er is ook nog ruimte om te groeien.

Opmerkingen van collega's van facebook

«Zjenja, hallo! Gaaf dat je schrijft, goed gedaan! Ik zal het een beetje corrigeren over de treinen - ze worden niet rond het product gevormd, maar rond de waardestroom. En in retail hebben we vanuit SAFe-perspectief geen trein, maar een Solution. Alleen voor het gemak van communicatie en om het begrip te vereenvoudigen, blijven we het een trein noemen)»

– Konstantin Voronin (vertegenwoordiger van het projectbureau van Ingosstrach)

«En misschien merkt iemand op dat vanuit SAFe-perspectief de beoordeling van doelen plaatsvindt op de I&A; (waar de SD als onderdeel in zit, maar niet direct met de beoordeling verbonden is) en de SD's zelf elke sprint moeten plaatsvinden (na de demo's van de teams). Maar daar zijn we voorlopig nog ver van verwijderd, dus noemen we alles bewust zoals het in jouw artikel staat)»

– Konstantin Voronin (vertegenwoordiger van het projectbureau van Ingosstrach)

«Zjenja, ga alsjeblieft door, heel nuttig!»

– Aleksej Ionov (Gecertificeerd SAFe-trainer)