Scrum, de tester en de verborgen succesfactor

Deze case study beschrijft verbeteringen als gevolg van het invoeren van Scrum in een organisatie met veel verschillende betrokken afdelingen. Het verhaal begint echter anders…

Testmanager

In één van zijn opdrachten was Niels Winkel (Quality Consultant bij SYSQA) testmanager bij een webshop. Vanaf het begin was al duidelijk dat het een taaie klus zou worden. Er was niet alleen al 9 maanden niet aan de webshop ontwikkeld, maar ook niet aan een viertal aansluitende systemen. En er waren nog geen testresultaten bekend. De reeds aanwezige testers hadden nog niet veel gedaan, met als argument dat er nog geen representatieve data beschikbaar was. Voor de testers waren de aanleverende systemen buiten scope. Er werd dus voornamelijk gewacht op het team dat aan het aanleverend systeem moest werken.

Vertrouwen in Scrum

Het traject zat wat vast, en om het op de rit te krijgen heeft Niels eerst een bug-run laten uitvoeren. Hij heeft met fictieve data zoveel mogelijk van de functionaliteit laten nalopen. En dat had resultaat: er werden zo’n 200 bevindingen gerapporteerd. De offshore partij die de webshop ontwikkelde kon daar alvast mee aan de slag.

Ook heeft Niels het testteam vanaf het eerste moment volgens Scrum laten werken. Dit heeft als voordelen dat het team nu beter weet welke taken op te pakken zijn en dat zowel het team zelf als alle betrokkenen een beter beeld hebben bij wat er aan het einde van een sprint wordt opgeleverd. Dit gaf de organisatie vertrouwen in de voordelen van de Scrum aanpak.

Data prioriteit

Het dataprobleem was er echter nog steeds. “Het systeem dat de data moest aanleveren was bedoeld voor rapportages en het team dat er aan werkte viel onder de verantwoordelijkheid van een andere projectleider”, aldus Niels.

De primaire verantwoordelijkheid van dat team lag daarnaast ook nog eens bij het terugkoppelingssysteem dat informatie uit de webshop terugkoppelde aan de onderliggende bronsystemen. “We hadden last van het feit dat er prioriteit was gegeven aan het terugkoppelingssysteem, terwijl wij en de ontwikkelaars van de webshop juist zaten te springen om een definitieve interface en aanlevering van correcte data uit het aanleverend systeem.”

Een complicerende factor hierbij was dat de ontwikkelaar van de webshop, een partij in India, de opdracht op basis van fixed-price had aangenomen. Zij zaten te wachten op een afronding zodat ze de software konden overdragen, hun resources konden vrijmaken en betaald konden worden. Het was van belang dat de aanlevering van data de hoogste prioriteit kreeg.

Scrum loste dataprobleem op

Op de vraag hoe hij het dataprobleem heeft aangepakt antwoordt Niels: “Omdat we hadden aangetoond dat onze Scrum-aanpak daadwerkelijk resultaten opleverde, konden we onze scope uitbreiden naar het testen van het aanleverend systeem. Dat resulteerde erin dat ik daar veel aan tafel kwam. Het werd mogelijk de verschillende belangen in de keten onder de aandacht te brengen. Het team heeft daarna een hogere prioriteit gegeven aan de aanlevering van data.” En, omdat de testers volgens Scrum werkten, was het ook mogelijk bij de ontwikkelaars de technieken van Standup, Sprint en Retrospective in te voeren.

Met veel praten en het stimuleren van veel overleg tussen de verschillende partijen wist Niels uiteindelijk het grootste gedeelte van de ontwikkelketen samen te laten werken onder Scrum. Niels: “Uiteindelijk is de test-scope uitgebreid naar de uitgaande interfaces van de bronsystemen, plus het aanleverend systeem, de webshop en het terugkoppelingssysteem. Daarbij hebben we voor elkaar gekregen dat in India het grote team is opgesplitst naar 2 scrumteams en dat voor het aanleverende systeem een scrumteam geformeerd werd.”

“Ik vond het van groot belang dat elk team zijn eigen testers had en dat hebben we kunnen realiseren. Alleen het systeem dat voor de data-terugkoppeling zou zorgen had geen toegewezen testers. De testwerkzaamheden daar werden flexibel opgepakt naar behoefte. Ook heb ik een ‘Scrum of Scrums’ in het leven geroepen. Dat is een regelmatige bijeenkomst van de inhoudelijk deskundigen van elk team, waarin ze samen bepalen hoe zij elkaar kunnen helpen, in plaats van elkaar in de weg te zitten.”

Randvoorwaarden voor goede IT ontwikkeling

Op de vraag of hij er met die maatregelen dan wás, antwoordde Niels: “Nou, alles in Scrum staat of valt met de aanlevering van de input. Deze komt van de Product Owner. Maar deze had veel te veel werk. Om de Product Owner vrij te maken voor het inhoudelijk werk, hebben we het backlogbeheer overgenomen, geholpen met reviewen en eventueel schrijven van user stories. Ook hebben we aan het eind van elke sprint demo’s aan hem gegeven, zodat het hem duidelijk was wat er gerealiseerd was en hoe dat eruit zag.”

“Verder hebben we gezorgd voor verbeteringen aan de data-uitwisseling tussen de verschillende werkomgevingen van de systemen en tussen de systemen onderling, opdat we betere data hadden, waardoor de testen betrouwbaarder werden.”

Resultaten van het toepassen van Scrum

En wat heeft dit allemaal opgeleverd? Niels: “De samenwerking is sterk verbeterd als gevolg van meer duidelijkheid in de communicatie en meer inzicht in elkaars belangen.

De relatie met de ontwikkelaars in India is van een vechtrelatie omgebogen naar een samenwerkingsverband. Men ging beter naar het ketenbelang kijken en kreeg meer begrip voor elkaars situatie. En omdat we successen met elkaar deelden in presentaties, kwamen de verschillende teams ook nader tot elkaar. Verder wordt er nu realistischer gepland, zowel voor de ontwikkeling van nieuwe functionaliteit als voor het herbouwen van stukken bestaande functionaliteit, met een betere technische onderbouwing.”

Wanneer wordt Scrum een succes?

Over hoe Niels tot deze succesvolle invoering van Scrum is gekomen, is hij duidelijk: “Proberen te overtuigen is een valkuil. Het werkte veel beter dat ik zelf liet zien dat Scrum toegevoegde waarde heeft.”

“Doordat de opleveringen van mijn team voorspelbaar werden, zag ook het management er het nut van in. En verder gaat het bij het werken met meerdere partijen altijd om de communicatie. Toen men duidelijk inzag dat niet het eigen systeem, maar de kéten van belang was voor het bereiken van een goed resultaat, en men begrip kreeg voor elkaars situatie, werd er beter samengewerkt. En werden de prioriteiten beter met elkaar afgestemd.”

Ook was het van belang dat de knelpuntfuncties, zoals in dit geval de Product Owner, assistentie kregen om hun werk goed te kunnen blijven uitvoeren.

De verborgen succesfactor

En dan vertelt Niels over de verborgen succesfactor. Hij waarschuwt: “Je moet voortdurend beseffen dat je er nooit bent. Je moet altijd blijven opletten of het proces nog werkt en past op de situatie. In een dynamische, steeds wijzigende omgeving moet je steeds blijven monitoren en zo nodig het proces bijstellen.”

Als je in een project bezig bent, dan is de grootste focus altijd op het systeem, de infrastructuur, de data en de aanpassingen die daarop nodig zijn. Wanneer de druk oploopt, dan wordt er vaak niet meer gekeken naar het proces. Dan kan het gaan voorkomen dat de Scrum-activiteiten, zoals Standup, Retro enzovoorts, alleen maar worden uitgevoerd om het uitvoeren. En dan schiet je je doel voorbij en werkt de methode alleen maar tegen je.

Een retrospective

Een goed voorbeeld van een Scrum actie ‘om-de-actie’ is de retrospective. Het is verleidelijk om dat even snel af te handelen, met telkens ook dezelfde vragen: “Wat is er goed gegaan”, “Waar kunnen we verbetering aanbrengen”. Dat wordt al snel een lijstje van telkens dezelfde antwoorden, vooral over wat er niet goed is gegaan, en vaak ook nog met de kanttekening dat de tegenslagen van buiten het team komen.

Er moet tijd uitgetrokken worden om de uitslagen van retrospectives te beantwoorden, hetzij door een procesverbetering, een functionaliteitsaanpassing of een verantwoording waarom de situatie is zoals die is. Naast het serieus nemen van de uitkomsten van de retro’s , is Niels hier ook wat creatiever mee omgegaan.

Niels: “De retro’s moesten telkens door iemand anders georganiseerd worden, zodat de teamleden er ook beter bij betrokken bleven. En ook week ik wel eens af van het standaard stramien en liet iedereen uit het team, per teamlid, vertellen waarom ze zo blij waren dat het betreffend teamlid in het team zat. Dan moest je na afloop van het overleg de ogen zien van alle teamleden: stralend en vol energie!”

Alleen als het belang van de activiteiten voorop staat en er consistent aandacht wordt gegeven aan de verschillende teams en hun behoeftes, dan hebben de Scrum-activiteiten toegevoegde waarde voor het project.