Blog

Integrale test bij meerdere scrumteams. Noodzaak of niet?

Indien er aan wijzigingen wordt gewerkt aan dezelfde componenten in meerdere scrum teams (bijvoorbeeld in een Service Oriented Architecture of in programmaverband), dan wordt er vaak gekozen om voor de live-gang van de release eerst een afzonderlijke integrale ketentest en/of acceptatietest uit te voeren. De vraag is echter waarom?

Meestal komt dit voort uit het feit dat ieder scrumteam een stukje heeft gemaakt van een groter geheel en dat deze stukjes nog niet zijn samengekomen tot een integraal systeem en dat er dus (en waarschijnlijk ook wel terecht) grote risico´s worden voorzien om deze stukken zo maar naar productie te brengen zonder dat ooit is gekeken naar deze onderlinge samenwerking en samenhang.

Dit is een situatie die een heel groot deel van de kracht van Agile en Scrum teniet doet en is ook niet nodig als je ervoor zorgt dat je aan een aantal randvoorwaarden voldoet voor je start met meerdere scrum teams die aan dezelfde componenten werken.

Wat zijn die randvoorwaarden voor een succesvol project met meerdere scrum teams? Hoe kun je teams geïsoleerd van elkaar laten werken aan een brug, zodat de twee helften van de brug ook bij elkaar uit komen en op dezelfde hoogte en dat ze dezelfde breedte hebben ….?

  • Werk vanuit een gezamenlijke roadmap. Het is belangrijk dat iedereen dezelfde richting op gaat en dezelfde focus heeft.
  • Zorg ervoor dat teams onafhankelijk van elkaar en van de (technische) omgeving kunnen werken. Met name het regelen van onafhankelijke testomgevingen is geen sinecure en vaak nogal prijzig. Hierbij kan overwogen worden om gebruik te maken van Provisioning.
  • Teams willen zo min mogelijk last van elkaars impedements (belemmeringen)  ondervinden. Een gezamenlijke impediment list en contact tussen de Scrum Masters (scrum of scrums) hierover is een mogelijk oplossing.
  • Zorg dat er één Product Owner is voor de verschillende teams. Eén kapitein die de prioriteit en richting bepaalt en daarnaast ook budgethouder is. Dit voorkomt dat er voor het ene team de keuze wordt gemaakt functionaliteit A te realiseren en in het tweede team functionaliteit B. Indien er toch per team een Product Owner is, dan is het handig als die zeer frequent samenkomen om te zorgen dat de richting hetzelfde blijft waarin de teams werken (stakeholdermgt bij de PO beleggen, niet bij de scrum teams).
  • Zorg voor afstemming tussen teams door de Scrum Masters van de verschillende teams met elkaar te laten overleggen (zoals genoemd: inregelen van scrum of scrums). Dit geldt overigens ook voor de testers en developers. Praat, controleer, maak afspraken met je evenknie in het team waarmee je een afhankelijkheid hebt. Probeer in de buurt van elkaar te werken (fysiek), doe aan pair-testing (samen stukken testen) en ontwikkelen (pair-development) als dat efficiënter is (maar maak er niet 1 groot team van).
  • Test afhankelijkheden zo snel als ze zijn opgeleverd tot aan de grenzen van je team (via stubs) en indien mogelijk al direct samen met het team waarmee je een afhankelijkheid hebt. Neem deze activiteit op in de sprint planning zodat het ook inzichtelijk is en het ook past in de sprint. Uiteindelijk is dit vele malen efficiënter dan één grote logge integratietest aan het einde waarbij ook niemand eigenlijk meer precies weet waar de risico-gebieden zich nu écht bevinden en het oplossen van issues ook vele malen meer tijd kost omdat iedereen er opnieuw in moet duiken.
  • Doe een gezamenlijke ‘backlog grooming sessie’ met de product owner en de Scrum Masters om een heldere product backlog te realiseren als input voor de pokersessies.
  • Plak een label op stories die in potentie een afhankelijkheid in zich hebben tussen 2 teams en probeer de story zo te plannen of nog beter, zo op te knippen, dat er geen afhankelijkheid meer is in tijd en functionaliteit.
  • Houd bij het plannen van de te realiseren functionaliteit ook rekening met eventuele onontkoombare afhankelijkheden. Laat verschillende teams niet tijdens een sprint aan dezelfde functionaliteit werken of afhankelijk zijn van elkaars sprintresultaat, maar plan dit over verschillende sprints. Hierdoor voorkom je dat, wanneer de functionaliteit onverhoopt uit de sprint valt bij team 1, de overige teams stil komen te vallen en geen werkende functionaliteit op kunnen leveren aan het einde van de sprint.
  • In Scrum is er een hoge mate van autonomie van de teamleden in de keuze voor de manier waarop het resultaat bereikt wordt. Bij een multi-scrum-team-project is het voor een goede afstemming tussen de teams wel van belang dat een aantal standaarden afgesproken worden met betrekking tot tools, documentatie en coding- en test-standaarden.
  • Bouw programmatuur zo flexibel dat features “aan en uit” te zetten zijn op het moment dat het gewenst is. Op die manier kun je al functies realiseren die de buitenwereld nog niet aankan, maar die je wel op elk gewenst moment in een (test)omgeving aan kunt zetten. Hiermee neem je afhankelijkheden weg en kun je zelfs deze delen al naar productie brengen zonder dat het impact heeft op andere teams of de functionaliteit.

LeSS-overview-diagram