Hoe SMURF je integratie in een agile omgeving?

Met een Slimme Mix van Universele Raamwerken én Flexibiliteit

Als je deel uitmaakt van een integratieteam in een agile omgeving, klinken deze vragen ongetwijfeld bekend: Hoe positioneren we ons team binnen het programma (centraal of decentraal)? Wie is waarvoor verantwoordelijk? Hoe kunnen we sneller leveren en afhankelijkheden beter afstemmen? En hoe moeten we omgaan met niet-ingeplande activiteiten zoals incidenten en kleine ‘urgente’ aanpassingen die ná planning pas bekend worden gemaakt? We werken toch agile?

Voor mij (de Scrum Master) en mijn team bleek het antwoord: met een Slimme Mix van Universele Raamwerken én Flexibiliteit. Wat mogelijk generiek klinkt, maar in de praktijk een efficiënte en effectieve wijze is om de productiviteit te verbeteren én afhankelijkheden met andere teams te stroomlijnen.

Achtergrond

Ons integratieteam is een programma-breed ondersteunend team in een SAFe (Scaled Agile Framework) programma. Ruim tien teams zijn verdeeld over twee treinen en wij leveren integraties aan al deze teams. Ze beschikken zelf níet over integratiespecialisten, dus zijn op ons aangewezen voor datamodellering en het ontwikkelen van integraties (op zowel het API platform als het integratieplatform). In het SAFe-overzicht acteren we als Systeem Team en als Shared Services Team.

Ons team bestaat uit:

• Integratie-architect
• Datamodelleurs
• Integratie-ontwikkelaars
• API Platform-ontwikkelaars
• Scrum Master

En onze verantwoordelijkheden omvatten:

• Het opleveren van integraties (op basis van User Stories), inclusief deployment t/m productie
• Testondersteuning en bug-fixing
• Beheer (op basis van tickets)

We werken in Programma Incrementen van vier Sprints/Iteraties van drie weken (plus één week voor Innovatie & Planning)

SMURF-punten

Genoeg context; tijd om de SMURF te smurfen. Waarbij het goed is om in gedachten te houden dat wat voor ons werkt, niet per se voor jou hoeft te werken – het hangt allemaal van de omstandigheden af. It depends. Toch kun je er hopelijk verbeterpunten uit halen voor je eigen team.

Als basis voor onze manier van werken, hebben wij deze vijf punten vastgesteld:

1. Sprint Planning is enkel de basis, niets meer en niets minder
2. Maak gebruik van één enkele bron van waarheid
3. Unieke vaardigheden in één team van specialisten
4. Refinement niet helder uitgevoerd? Weg ermee!
5. Fijnmazige planning voor kortere doorlooptijden

1. Sprint Planning is enkel de basis, niets meer en niets minder

Geheel in lijn met de rest van het programma maken we iedere drie weken een Sprint Planning. Omdat niet al onze werkzaamheden planbaar zijn (zoals beheertaken en incidenten) plan ik slechts een deel van de teamcapaciteit in als ‘beschikbaar’ voor User Stories. Voor geplande deployments reserveer ik ook capaciteit. Als we te vol zitten, vraag ik ‘het programma’ om prioritering. Dan plaatsen we wat te veel is als ‘optioneel’, of ik verklein de capaciteit voor niet-ingepland werk. Regelmatig komen er nog extra User Stories binnen ná de Sprint Planning – daar kijken we dan op dat moment naar of wie die alsnog kunnen inplannen, al dan niet ten koste van iets anders.

Met alle onzekerheden verwacht niemand meer dat de Sprint Planning vast staat voor de gehele Sprint. En dat is prima – ik zie het als een basisplan. Tijdens de Sprint werken we meer Kanban-stijl en kijken we waar nodig wat we met ad-hoc verzoeken en urgente beheertaken moeten en kunnen doen. Hiervoor hebben we afspraken gemaakt (nou ja, medegedeeld) met de diverse teams – zodat helder is hoe we werken en wat de mogelijkheden zijn ná Sprint Planning.

Als we over (dreigen te) lopen qua hoeveelheid werk,dan escaleer ik dit naar Solution Management. We hebben zelf geen Product Owner, en het maakt ook eigenlijk niet uit wáár we aan werken, als we maar lekker bezig zijn. Ook dit is vooraf bekend gemaakt, zodat alle teams weten waar ze aan toe zijn.

Uiteindelijk werkt deze flexibiliteit het beste voor iedereen, omdat we altijd in programma-context werken aan wat het meeste waarde oplevert. Dat kan soms pijn doen voor afzonderlijke teams, maar ja – we kijken altijd naar het grote plaatje.

2. Maak gebruik van één enkele bron van waarheid

Het is zó fijn om één online platform te hebben dat we bijna overal voor gebruiken. Gelukkig zien ook steeds meer mensen dat het het beste werkt als er één enkele bron van waarheid is voor alle documentatie, ontwikkelverzoeken etc. Zeker nu we meer thuiswerken dan -zeg- 2 jaar geleden, zie je dat een planning op basis van geeltjes aan de muur niet meer werkt.

Met de Increment Planning werden vroeger overal gele briefjes op bruin papier op de muren geplakt en moesten wij als integratieteam bij alle andere teams langs om te kijken of er iets voor ons tussen hing. Dit is nu omgezet in een brengplicht voor de teams. En als het niet centraal online staat, dan bestaat het simpelweg niet.

En oké, ik sla er persoonijk wellicht een beetje in door. Want ik maak dus overal User Stories voor aan. Niet voor de andere teams, maar voor interne zaken en planning maak ik aan: kopie-van-bug (omdat ik niet één overzicht heb met én User Stories én Bugs), incidenten (tickets staan in een ander systeem), en alle andere beheertaken. Ik maak zelfs User Stories aan voor… vakanties! Op deze manier heb ik altijd inzicht in de taken die we moeten doen én de beschikbaarheid van het team (en de skills in het team). Dus eigenlijk geldt voor alles waar ik rekening mee moet houden tijdens de Sprint Planning: Daar is een User Story voor!

Ik moet wel toegeven dat ik één groot voordeel heb: Ik hoef amper te rapporteren op basis van kengetallen. Dus dat ik al die extra User Stories maak, daar heeft niemand last van.

3. Unieke vaardigheden in één team van specialisten

Omdat onze integratievaardigheden redelijk specifiek zijn én omdat het niet om grote werkvolumes gaat én omdat een deel van het werk onvoorspelbaar is, is er gekozen voor één centraal team van specialisten dat als onderaannemer functioneert voor de andere teams.

Ons takenpakket omvat grofweg datamodellering, API administratie en het bouwen van integraties op het integratieplatform. Doordat we de integratiespecialisten niet hebben verdeeld over meerdere teams, scheelt dit al het bijwonen van alle SAFe/Agile-ceremonies. Dus slechts één Daily Stand-Up van het integratieteam in plaats van die van de 10 andere teams bijwonen. En onze eigen Daily is 2 x per week verplicht, anders houden de part-timers geen werktijd meer over. De algemene ‘connect’ tussen het integratieteam en de andere teams loopt via de Scrum Masters. En zodra het User Story specifiek wordt, neemt de integratie-specialist rechtstreeks contact op.

Bijkomend voordeel voor het datamodelleren is dat er één centraal inzicht is op het centrale datamodel. Zo houd je de opbouw consistent en kun je makkelijk datablokken hergebruiken.

Werken met één centraal teamheeft wel een aantal gevolgen: We hebben bijvoorbeeld geen Product Owner. En ons werk komt van diverse kanten:

• User Stories die andere teams opstellen voor ons,
• Deployments – in principe volgens vaste planning, maar vast blijkt niet altijd even vast te zijn,
• Testondersteuning en bug-fixing,
• Operationele incidenten (tickets).

Dit in aflopende mate van voorspelbaarheid – en door met één team te werken, is dit vele malenmakkelijker uit te balanceren dan wanneer alle teamleden verspreid door het programma zouden zitten.

4. Refinement niet helder uitgevoerd? Weg ermee!

Tsja, hier maak je niet per se vrienden mee. Maar je moet streng zijn op de kwaliteitseisen van je opdrachten (User Stories). Ze moeten duidelijk genoeg zijn om zowel een inschatting te kunnen maken, als om ze op te kunnen pakken. Dit hoeft niet hetzelfde te zijn: Het toevoegen van twee velden is makkelijk in te schatten qua werkvolume, maar zolang je niet weet wélke velden, kun je niet daadwerkelijk beginnen. Andere teams besteden vaak meer tijd en aandacht aan eigen User Stories dan aan degenen die naar ons gaan. Dan zijn ze bijvoorbeeld procedureel incompleet. Terwijl User Stories zonder (wens) Sprint of User Stories die niet op ons team staan, simpelweg niet in mijn overzichten terechtkomen. En dan worden ze dus ook niet ingepland en opgepakt.

Wanneer een User Story niet goed is opgesteld, loop je een grote kans dat je ‘m niet binnen de tijd kunt opleveren. Waar anderen vervolgens weer last van hebben. Dus wees streng – wij hebben de duimschroeven ook steeds harder aangedraaid. Nu worden User Stories die we niet kunnen inschatten per definitie doorgeschoven naar de volgende Sprint. Dus: Zijn ze niet helder? Weg ermee!

Wij doen onze Refinement wekelijks iets voor het eind van de week – en is het de laatste week van de Sprint? Dan noemen we ‘m Sprint Planning voor de volgende Sprint. We lopen hiermee voor op de algemene cadans, zodat we de andere teams over onze plannen kunnen informeren vóór zij hun Sprint Planning doen. Dan weten ze ook tijdig welke zaken we niet kunnen oppakken (of omdat we vol zitten, of omdat de specificaties niet helder zijn). Verrassingen zitten daar dan meestal niet bij, omdat ik een week eerder al een ‘schaduw Spint Planning’ maak en naar de Scrum Master rondstuur met een indicatieve planning en onderbouwing.

5. Fijnmazige planning voor kortere doorlooptijden

Voor de meeste integraties zijn twee onderdelen nodig: Datamodellering en het bouwen van de integratie. In het beginwerden deze twee onderdelen meestal in twee Sprints na elkaar ingepland – oftewel zes weken doorlooptijd. Dat deed soms een beetje pijn… Daarom stapten we over op een fijnmazige planning op weekbasis. Tijdens de Sprint Planning zetten we alle User Stories in een specifieke week van onze Sprint (dat kan makkelijk, de meeste User Stories zijn 1-3 dagen werk). Hierdoor kunnen we meestal ál het werk binnen één Sprint opleveren, en soms zelfs zo dat het aanvragende team zelf in de derde week nog iets gerelateerds kan inplannen. De teams zijn hier zo enthousiast over, dat ze nu graag op dagniveau zouden willen plannen. Wat niet mogelijk is, in verband met wisselende part-time dagen en ad hoc werkzaamheden, maar het is een welkome reactie!

Conclusie

Staar je niet blind op een raamwerk of methodiek omwille van het raamwerk of methodiek. Als het begint te knellen – niet alleen voor je eigen team, maar ook voor andere teams – dan moet je een andere oplossing vinden. Haal overal de krenten uit de pap en vind zó de beste manier van werken. Gebruik of creëer de flexibiliteit die je (nodig) hebt en vergeet ook vooral het ‘gezonde boerenverstand’ raamwerk niet. Pas het overal toe!

Integratie een handje geholpen

Heb jij een heel integratieteam nodig, of is het waardevol als iemand meekijkt naar jullie way-of-working voor een optimalisatieslag? We zetten graag onze jarenlange kennis en team van specialisten in om jouw organisatie te ontzorgen op gebied van integratie. Neem contact met ons op voor een verkennend gesprek waarin we samen bekijken hoe we jullie het beste kunnen ondersteunen.

Dit artikel verscheen eerder in een iets afwijkende Engelstalige versie op LinkedIn.