Wat men kan leren van Agile en Scurm saboteurs?

Iedereen komt ze tegen, dus testers zeker ook: personen die zich verzetten tegen Scrum of Agile. Of steeds protesteren tegen bepaalde aspecten van Agile of Scrum. Regelmatig is het ook de tester zelf die saboteert. Saboteurs zijn lastig, een sta-in-de-weg. Ze beïnvloeden de groep negatief en staan verbeteringen in de weg. Ze maken meetings onnodig lang, doordat ze onderwerpen keer op keer op keer aankaarten, terwijl Scrum en Agile een duidelijk antwoord geven. Ze gaan hun eigen weg, terwijl je juist als team samen een weg wil bepalen. Je zou ze misschien het liefst uit je team halen. Want wat heb je aan ze?

Agile en Scrum saboteurs zijn, naar mijn ervaring, meestal geen mensen die niets geven om werk, team, project of bedrijf. Het zijn vaak mensen, die hun werk werkelijk met passie uitvoeren. En zeer regelmatig hier ook erg goed in zijn. Ze willen goed werk leveren, op een snelle, efficiënte en effectieve manier. Ze willen hun beloftes nakomen. Ze willen ook vaak het beste voor het bedrijf en het team. Hoe ik dat allemaal zo durf te beweren? De mensen, die vaak echt als saboteurs worden beschouwd, zijn de mensen die hun mond opentrekken. Of, netter gezegd, mensen die hun mening naar voren brengen. Mensen, die proberen problemen en risico's naar voren te brengen. Zaken die het bedrijf, het team of het project in gevaar kunnen brengen. Hun toon mag soms erg negatief zijn, hun doel is meestal echt niet om het bedrijf, team of project kapot te maken.

De uitdaging (en ja, het is echt een uitdaging) is om erachter te komen wat de problemen en risico's zijn, die de saboteur ziet. En de nog grotere uitdaging is om hun problemen en risico's op te vangen met behulp van Agile en Scrum. Want alleen als je hun tegenstanders, Agile en Scrum, gebruikt om hun pijnpunten op te lossen, zullen ze echt gaan beseffen wat de kracht hiervan is. Wat voor jou het voordeel is? Het opent je ogen voor zwakke punten in de organisatie, project, proces en team. Zaken, die je zelf gemist hebt.

Maar genoeg theorie, hoe kan dit nou in de praktijk werken?

Testweigerende programmeurs - Verwachtingen tegenstrijdig met Scrum of Agile

Een tester is regelmatig de enige tester in het team. Omdat je als team zo veel mogelijk onafhankelijk wil zijn van niet-teamleden, wordt het testen binnen het team gedaan. Door de tester dus. Maar die gaat ook wel eens op vakantie of is ziek. Om het werk dan niet stil te laten liggen, is het geen rare verwachting, dat er binnen het team bereidheid is om het testwerk over te nemen. Maar bijna elke tester, die dit geprobeerd heeft, is wel tegen een of meerdere teamleden aangelopen, die weigeren te testen. Dat is hun werk niet, zij zijn programmeurs. En het multidisciplinaire aspect doet ze eigenlijk niets.

Terug naar de bron

Scrum wordt vaak ingevoerd in een situatie waarin management of klant ontevreden is over deadline en planning. Niet alleen duurt het heel lang, voordat problemen en wensen worden opgelost. Te vaak is dat ook nog eens veel later dan beloofd. Een methode, waarbij elke twee of drie weken standaard problemen worden opgelost en wensen worden vervuld, lijkt dan ook de ideale oplossing voor de planningsproblemen.

Probleem is dat bij de start van Scrum de klant en/of de manager vaak al ongeduldig is geworden. Hij wacht al vrij lang en heeft vrij weinig gekregen. Dus eigenlijk wil hij zoveel mogelijk, zo snel mogelijk. En dat wordt ook uitgestraald. Nu Scrum is ingevoerd, moet er snel resultaat komen. En het liefst zo veel mogelijk. Zodat de managers en de klanten tevreden kunnen worden gesteld.

Om zoveel mogelijk zo snel mogelijk op te leveren, is het het handigste om de mensen te laten doen, waar ze goed in zijn. Dan kunnen ze veel werk leveren in weinig tijd. En vaak met een goede kwaliteit. Is het dan vreemd dat mensen, bij zulke verwachtingen, eisen dat hun werk op hun eigen specialistische gebied ligt? Ze voelen tenslotte ook de druk om snel veel werk op te leveren. En als ze mogen doen waar ze goed in zijn, dan kunnen ze het beste helpen aan deze verwachting te voldoen.

Scrum heeft echter bewust niet als doel om zo snel mogelijk zo veel mogelijk op te leveren. Iedereen weet ook dat dit vaak een garantie is tot slechte kwaliteit, waardoor je later nog meer problemen krijgt. Bijvoorbeeld ongeplande uitloop van je project. Of een product, wat niet voldoet aan de eisen van de klant. Het doel van Scrum is veel meer om het belangrijkste het eerst op te leveren. En een flink stuk sneller dan het opgeleverd zou zijn met een waterval project. Waardoor de belangrijkste problemen eerder opgelost zijn en de belangrijkste nieuwe functionaliteit eerder geld op kan gaan leveren. Het feit dat de zaken die het meeste geld kosten, het meeste geld opleveren of de grootste problemen veroorzaken, snel worden opgelost, dat is wat managers en klanten tevreden moet stellen. En juist door de druk van "zo snel mogelijk zo veel mogelijk" weg te halen, kan een team veel beter garanderen dat de kwaliteit in orde is. Wat uitloop of ontevredenheid weer voorkomt.

Controleren of de kwaliteit op orde is, doe je onder andere door te testen. Ook als een tester ziek of op vakantie is. Want als niet alles getest is, kan het belangrijkste niet volledig worden opgeleverd. Je weet tenslotte niet of het goed is. Waardoor je alsnog de manager of klant teleurstelt. En de druk op het team nog hoger wordt. Testen dus, ongeacht vakanties of ziektes. Alles om klant en manager tevreden te houden.

De nutteloze stand-up - Schijnbetrokkenheid

Bijna elke Agile tester heeft ermee te maken: de stand-up. Elke dag, als je geluk hebt tenminste, een kwartier informatie uitwisselen. En bijna elk scrumteam wat ik heb gekend, heeft wel een of meerdere personen gehad die het nut in twijfel trokken. Kan je de tijd van een nutteloze stand-up niet veel beter besteden aan het bouwen van nieuwe functionaliteit?

Agile en Scrum zijn beiden voor het afschaffen van nutteloze zaken: nutteloze documentatie moet je niet schrijven en nutteloze overleggen moet je niet voeren. De eis om een nutteloze stand-up meeting af te schaffen is daarmee misschien niet eens zo tegenstrijdig met Agile en Scrum. En, helaas, moet ik toegeven dat veel stand-up meetings vaak ook nutteloos zijn. Iedereen vertelt wat die gaat doen en heeft gedaan en vervolgens weer aan het werk. Informatie, die je ook wel uit het Scrumboard kan halen. Daar heb je geen meeting voor nodig. Dus, vanuit dat oogpunt, is afschaffen eigenlijk de beste optie.

Terug naar de bron

Planningssessies hebben regelmatig dezelfde aanpak: de Scrummaster bepaalt hoeveel het team in de sprint aankan en de Productowner bepaalt wat er in de sprint wordt opgenomen. Het team mag, als het geluk heeft, zeggen dat de planning haalbaar is. Maar eigenlijk is "Ja" het enige juiste antwoord. Hoe zwaar een story is, hebben de teamleden tenslotte zelf bepaalt. De Scrummaster weet, met zijn ervaring, echt wel goed te bepalen wat een team aankan. En de Productowner weet, door zijn contacten met klanten en managers, toch het beste wat belangrijk is. Wel wordt verwacht dat die "Ja" voldoende is om volledige commitment van het team te krijgen. Maar wat er in de sprint zit, is toch eigenlijk 90% van de planning. Als 90% van de planning het team wordt opgelegd, is het dan vreemd dat de betrokkenheid bij de planning laag is? En dat daardoor de commitment ook niet zoveel voorstelt?

De Stand-up heeft als belangrijkste doel om de commitment op het halen van de sprint na te gaan. Als deze commitment slechts schijn is, dan wordt de stand-up dat al snel ook. Als de teamleden zich niet betrokken voelen bij de planning, gaan ze bij de stand-up ook niet kritisch op de planning letten. Als Scrummaster en Productowner samen de planning hebben bepaalt, houden ze deze ook maar zelf in de gaten. Het is tenslotte hun planning. Is deze redenering zo vreemd?

Agile en Scrum-experts zijn altijd voor gezamenlijke overleggen en besluiten. Het heeft zeker nut als testers meepraten over hele technische onderwerpen. En experts van de back-end kunnen best input geven over onderwerpen van de front-end. Maar te veel Agile en Scrum-experts maken hier een hele grote uitzondering op: Agile en Scrum onderwerpen. Het is echt niet mogelijk dat iemand met geen tot weinig kennis van Agile en Scrum serieus mee kan praten over de beste manier om Agile en Scrum toe te passen in het team. Het bepalen van de workload in de sprint en de op te pakken story's zijn onderwerpen waarvoor echt Scrum kennis nodig is. Anders kan je dat echt niet. Dat moet je dus aan de experts overlaten. Ben je dat niet, dan moet je erop vertrouwen dat ze hun werk goed doen.

Het spijt me zeer voor de experts, maar ook het bepalen van de workload en de inhoud van de sprint is een teamverantwoordelijkheid. Een waarover ook Agile- en Scrum dummies mogen meepraten. Zelfs moeten meepraten. Misschien weten ze niet hoe een Velocity chart werkt. Maar ze weten misschien wel dat Pietje, die deze sprint op vakantie is, helaas als enige verstand heeft van database X. En dat story Y daarom in deze sprint nooit opgepakt kan worden, want daarvoor zijn veel aanpassingen in database X nodig. En ze kunnen zich misschien ook herinneren dat Jantje deze week een cursus heeft. Iets wat vergeten is bij het bepalen van de beschikbaarheid. Hoe goed Scrummaster en Productowner ook zijn, ook zij vergeten wel is wat.

Dit meepraten maakt de planning ook meteen veel meer een teamactiviteit. Nu wordt 90% van de planning met instemming van het team gemaakt. Het draagvlak voor de planning is hoger en de commitment is oprechter. Het team zal daardoor automatisch meer inzet tonen om te sprint te halen. En hierdoor eerder de neiging hebben om kritisch naar elkaars planning te kijken. Ook zullen problemen, die ze zelf tegenkomen, sneller aangekaart worden, om de planning niet in gevaar te brengen. De beste manier om deze communicatie te groeperen: elke dag een kwartiertje bij elkaar komen om dit soort zaken te bespreken. Even zeggen wat je hebt gedaan, gaat doen en tegen welke problemen je aanloopt. Even controleren of er niet iemand al 3 dagen zegt met hetzelfde bezig te zijn, terwijl de klus slechts 1 dag zou duren. Even kort vragen of dit niet besproken moet worden. Of de planning nu niet aangepast moet worden. Even kort bespreken hoe problemen aangepakt gaan worden, zodat ze de planning niet in gevaar brengen. Of bespreken wat voor effect deze op de planning hebben. Iedereen wil nu de sprint halen. En dat maakt meteen de stand-up een stuk nuttiger voor iedereen.

De nooit gevolgde Definition of Done - Te veel eisen in een keer

Bijna elke tester, die geeft om kwaliteit, zal de Definition of Done al vrij snel een belangrijk document vinden. Toch komt het regelmatig voor dat de Defnition of Done wel aanwezig is, maar dat opgeleverde story's regelmatig niet helemaal aan de Definition of Done voldoen. Als je dit na gaat vragen, krijg je als antwoord: "Ja, maar daar had ik echt geen tijd voor. " En als je daar tegenin brengt: "Maar dit hebben we afgesproken.", kan je als antwoord krijgen: "Ja, wat wil je nu? Wil je dat ik mijn werk op tijd afrond? Wil je de sprint halen? Of wil je dat ik ontzettend veel tijd steek in dit ene puntje? Wat vind je nu belangrijker? We willen de sprint toch halen? Nou, dan moet je niet zo moeilijk doen over dit puntje van de Definition of Done."

Terug naar de bron

Bij de Defnition of Done wordt vaak uitgaan van de gewenste situatie. Of het is een kopie van een Definition of Done opgesteld bij een ander bedrijf of een Scrum expert. Deze gaan vaak uit van een meer ervaren Scrum organisatie, die ook meer aankan. Op zich begrijpelijk, want het streven is goed.

Het probleem is echter het volgende: Als men leert jongeleren, is het besef dat men eerst moet leren om drie ballen in de lucht te houden. En dat is al een uitdaging, die veel tijd kost. Pas daarna gaat men naar steeds meer ballen. Of naar gevaarlijkere objecten als zwaarden of vuur. Maar als men een Definition of Done invoert, probeert men meteen 10 tot 20 eisen in de lucht te houden. Waarvan sommige zeer gevaarlijk zijn, omdat ze veel tijd kosten. En niemand wil uitleggen waarom de invoering van een Definition of Done leidt tot een halvering van het aantal haalbare storypoints per sprint. Of een bepaalde story qua storypoints plotseling twee keer zo zwaar is. Je kan eigenlijk zeggen dat men voor het in de lucht houden het aantal eisen terugbrengt tot een haalbaar aantal. Geen onlogisch besluit toch? Beter drie eisen in de lucht, dan alle eisen op de grond.

Voor de Definition of Done moet dan ook niet gekeken worden naar een ideaal of een Definition of Done van een te hoog volwassenheidsniveau. De Definition of Done moet onder alle omstandigheden haalbaar zijn. En hier moet ook iedereen van overtuigd zijn. Als een logische eis, bijvoorbeeld unittesten schrijven, nog niet haalbaar is, laat hem weg. Besteed aan de ene kant dan tijd en story's om een goede basis voor unittesten op te zetten en hier goede afspraken over te maken. En vertrouw er aan de andere kant op, dat andere eisen in de Definition of Done uiteindelijk zorgen voor een beter product of beter proces. Hierdoor krijg je vertrouwen, waardoor je meer tijd kan gaan besteden aan deze eisen. En je weer nieuwe eisen kan toevoegen.

Dus wat moet je doen bij saboteurs?

Bovenstaande zijn voorbeelden. Wel gebaseerd op mijn praktijk ervaringen, maar zeker niet direct van toepassing op alle situaties. Zelfs niet soortgelijke situaties. Waar het om gaat, is dat je probeert erachter te komen welke problemen en risico's saboteurs zien. En deze problemen en risico's serieus neemt. Probeer de ander er niet van te overtuigen dat de problemen en risico's er niet zijn. En kom zeker niet met het argument: "Maar Scrum/Agile werkt zo, dus we doen het zo."

Kijk naar de genoemde problemen en risico's. Kijk vervolgens naar welke personen. middelen of afspraken binnen Scrum en Agile dit probleem zouden moeten oplossen of het risico zouden moeten voorkomen. Kijk wat bij deze personen, middelen of afspraken beter kan worden, zodat de genoemde problemen worden opgelost of risico's worden voorkomen. En durf daarbij ook kritisch naar jezelf te kijken. Overleg met de saboteur of je aanpassing inderdaad zou helpen. Leg daarbij ook zeer duidelijk uit welk aspect van Scrum of Agile je gebruikt om de situatie aan te pakken. Dit om Scrum en Agile niet als vijand te tonen, maar als vriend.

Als de saboteur akkoord is, leg dan de aanpassing voor aan het hele team. Vertel waarom je de aanpassing wil doorvoeren. En vraag feedback. Staat er een nieuwe saboteur op, pak dit dan weer opnieuw op de juiste wijze op. Want ook nu blijft: het hele team moet erachter staan. Niet alleen jij en de saboteur.

Hoewel dit misschien werk van de Scrummaster lijkt, kan iedereen dit doen. Tenslotte ben je als heel team altijd verantwoordelijk voor het hele proces. Het kan echter wel verstandig zijn de Scrummaster hierbij te betrekken. Misschien wil de Scrummaster bij een bepaalt deel aanwezig zijn. En het heeft zeker grote voordelen als de Scrummaster al achter de aanpassing staat.

Veel sterkte en succes!!