Als je als beginnend tester wil leren als tester, dan is alles simpel. Je gaat gewoon naar een senior tester. Testen leer je van collega's, wat anders? Maar dan kom je in aanraking met Scrum, met Agile. Plotseling moet je veel meer dan testen. Je bent misschien geen beginnend tester meer, maar wel een beginnend Scrummer. Je moet niet alleen heel anders testen. Nee, je moet opeens ook heel anders overleggen, om samen met programmeurs tot een aanpak van een story te komen. Je moet mensen corrigeren, omdat je als groep verantwoordelijk bent voor het nakomen van de afspraken. Je moet misschien programmeurs coachen, om ze ook te laten testen. Je moet opeens veel meer.
Dan blijkt de senior tester ook niet van alle markten thuis. Wel goed in samen werken met de programmeurs. Maar minder goed in samenwerken met de productowner. Die is echt nooit tevreden. Hoe vaak je ook afspreekt: dit is hoe het gebouwd gaat worden, die wil toch steeds weer wat anders. "Dit is niet goed genoeg! Dit moet aangepast worden!". En de senior tester gaat er maar in mee. Tenslotte moet de productowner akkoord gaan, toch? Dat is toch Scrum? Dat is toch Agile? Gelukkig is er een programmeur in het team, die grijpt op een bepaald moment in. Stelt de juiste vragen: "Wat wil je nu? Wil je de volgende story in je sprint ook nog bij de oplevering naar productie? Of heb je liever je groene button met precies 10 pixels tussen de tekst en het pijltje in alle verschillende browsers?"
Die vaardigheden wil je ook wel leren. Toch? Tja, in de praktijk blijkt dit een ander verhaal. Als junior tester mag je alle testvaardigheden leren van een senior tester. Maar als het om vaardigheden als overleggen, overtuigen en coachen komt, lijkt het opeens minder logisch om te leren. Als junior tester merk je dat je in het ene deel van testen beter bent dan het andere. Toch probeer je meestal op alle testvlakken te leren. Zeker als je die vaardigheden nodig hebt voor je vak als tester. Maar een junior communicator, die kiest vaak in de praktijk vooral welke communicatie hij of zij goed is en welke communicatie hij of zij vervolgens aan een ander over gaat laten. Ook al heb je al die vaardigheden als Scrummer eigenlijk nodig. Als een ander het al doet, dan is dat voldoende. Beter worden in de communicatie waar je slecht in bent, waarom zou je?
Stel dat je daar niet zo over denkt. Stel jij wil ook die productowner overtuigen. Het is vreemd, hoe Agile en functieloos we ook werken, het leertraject is vaak nog erg hiërarchisch. Als junior tester staat het je vrij om te leren van een senior tester. Je kan rustig overleggen en advies vragen. Je kan terecht bij je teamleider, je scrummaster, en misschien je testcoördinator of testmanager. Ook die staan open om je advies te geven. Maar stel dat jij als junior overtuiger leren wil van een senior overtuiger. Van die programmeur in je Scrumteam die de productowner zo goed kan overtuigen. Mag die persoon dan tijd vrij maken om jou te coachen bij overtuigen?
Ik zou zelf het liefst zien dat we binnen een team niet meer alleen elkaars topvaardigheden zouden weten. En dan bedoel ik dus nu vooral de vaardigheden die buiten de officiële specialisatie liggen, zoals op het gebied van communicatie. Mijn ervaring is dat die kennis meestal in het team wel aanwezig is. Ik zou zelf ook heel graag zien, dat we binnen het team zouden proberen deze vaardigheden van elkaar te leren en aan elkaar te leren. Leren overtuigen van een senior overtuiger. Leren plannen van een senior planner. Leren meeting voor te zitten van een senior voorzitter. En als een vaardigheid in het team niet aanwezig is, zouden we die dan niet van iemand buiten het team kunnen leren? Als het over testen gaat, is dit een vrij logische vraag. Misschien is het antwoord niet altijd "Ja", maar de vraag is logisch. Als het gaat om collega's op de regels te wijzen, iets wat velen in een Scrumteam moeilijk vinden, dan is de vraag opeens veel minder logisch. En het antwoord vrijwel gegarandeerd "Nee". Eigenlijk vreemd, want deze vaardigheden zijn vaak net zo belangrijk als testvaardigheden om een project tot een goed einde te brengen. Zo belangrijk dat ook hier zoveel mogelijk multi-disciplinair zijn, net als bij vakgebieden, hele grote voordelen heeft. Misschien wordt het tijd voor verandering......
maandag 20 juli 2015
zondag 12 juli 2015
Als Scrum de kwaliteit vermindert
Scrum wordt door sommige mensen gebracht als de oplossing voor alle problemen. Maar de praktijk valt soms anders uit. Zo kan kwaliteit ook binnen een Scrum traject erg onder druk komen te staan. En bepaalde sterke punten binnen een Scrum aanpak, kunnen juist nadelig werken voor het testtraject. De terechte vrijheid van het Scrumteam kan leiden tot een slecht product. Maar pas wel op voor je een schuldige aanwijst!
Binnen Scrum heeft het scrumteam, terecht, heel veel vrijheid om het eigen proces in te vullen. Om bijvoorbeeld een eigen Definition of Done op te stellen. Of te bepalen welke testen er uitgevoerd zullen worden tijdens de sprint. Bij veel vrijheid komt veel verantwoordelijkheid. En daarmee veel mogelijkheid om de verkeerde weg in te slaan.
Zo kan je de acceptatiecriteria gebruiken om een story die je nooit in productie zal brengen, toch goed te laten keuren. In de acceptatiecriteria staat vaak echt niet dat bij een proces dat een halve minuut kan duren, de gebruiker moet zien dat hij moet wachten. Bijvoorbeeld met een zandlopertje. Dat zo ongeveer elke gebruiker na ongeveer 10 seconden denkt dat de site niet werkt en weggaat, doet niet ter zake. Het staat niet in de acceptatiecriteria, dus de story is goed.
En je hebt als Scrum team alle vrijheid om voor een website te besluiten om deze nu even niet in verschillende browsers te testen. Een browser is voldoende. Geschikt voor mobiel komt later wel. Dat websites juist regelmatig problemen geven op verschillende browsers, zeker op mobiel, is nu niet belangrijk. Scrum is een ideale methode om je kop in het zand te steken en door te gaan. Dat mag je tenslotte ook, want je bent zelf verantwoordelijk.
Laat ik wel eerlijk blijven: kwaliteit staat misschien bij veel Scrum projecten wel onder druk. Maar situaties die lijken op bovenstaande voorbeelden zal je niet bij alle Scrum projecten zomaar tegenkomen. Naar mijn ervaring staat kwaliteit vooral onder druk bij projecten die niet regelmatig naar productie gaan. Als een applicatie naar productie gaat en de kwaliteit is slecht, dan wordt het Scrumteam vanzelf gedwongen hun kwaliteitsproblemen aan te pakken. Geen enkele organisatie accepteert dat er drie sprints achter elkaar producten worden opgeleverd, die vervolgens weer teruggedraaid moeten worden.
Het probleem ontstaat vooral bij projecten waar de gang naar productie later is. Omdat men eerst een groot deel van de functionaliteit af wil hebben. Vaak is hier sprake van herbouw van een bestaande applicatie. De nieuwe applicatie moet dan toch minimaal vergelijkbaar zijn met de oude, voordat je naar productie gaat. Waardoor kwaliteitsproblemen meer verborgen kunnen blijven. En de redenering "Dat kunnen we in een komende sprint wel oplossen"erg geloofwaardig klinkt.
Juist bij projecten met een herbouw karakter is ook de druk vanuit de organisatie groter. Men wil resultaat zien. Hoe meer nieuwe functies, hoe meer vertrouwen men in het Scrumteam heeft. Om dit vertrouwen te winnen, kan je heel eenvoudig story's met problemen toch als afgerond beschouwen. Bij de Sprint Review kan je om de problemen heen een demo geven. De problemen schuif je door, geen probleem, je hebt nog zo veel sprints. Het resultaat van de sprint lijkt nu opeens duidelijk beter. Het probleem is alleen, dat dit de volgende sprint weer gebeurt. En de sprint erna weer. En de sprint erna weer. Op een bepaald moment heb je een volledige sprint nodig om alle problemen op te lossen. Tijd voor die sprint is er niet. En verwerken in andere sprints is moeilijk. Want op de organisatie komt dat al vrij snel over als "het team levert minder werk".
Andere manieren om veel nieuwe functies op te leveren, is om werk te besparen. En veel testtaken zijn hiervoor ideaal. Regressietesten, performancetesten, compatibiliteitstesten, ze kosten tijd. Maar niemand van de business heeft het door als je ze achterwege laat. Terwijl de extra story's zeer welkom zijn. Bouwen van nieuwe story's is ook goed zichtbaar. Testen daarentegen, je kan er nauwelijks een demo over geven. En zelfs als je het doet, de interesse is niet groot. Dat deze tijd in latere sprints, op deze manier gedacht, ook niet beschikbaar is, is van latere zorg.
Maar niet altijd is druk vanuit de organisatie de oorzaak. Veel ontwikkelaars die beginnen met Scrum hebben ook moeite om om te gaan met de vrijheid die ze krijgen. Kregen ze eerst vaak het proces voorgeschreven. En stond tot in detail de te bouwen functie uitgewerkt. Nu moeten ze het proces bijna helemaal zelf bepalen. En wat ze moeten bouwen, kan je plotseling niet meer alleen lezen... nee, je moet deze zelf bespreken . Soms zelfs zelf beslissen. Dat moet je leren, maar de tijd die hiervoor nodig is krijg je niet. Toch krijg je krijg je wel te horen dat je beslissing niet correct was; het was dan een dom besluit. Veel ontwikkelaars grijpen zo terug naar de oude papieren zekerheid: als het niet is vastgelegd, hoef ik het niet te doen. Dat geeft tenminste duidelijkheid en voorkomt dat jij fouten maakt. Het voorkomt niet dat het fout gaat, maar het voorkomt wel dat jij fouten maakt.
Is Scrum dan niet geschikt voor herbouwtrajecten? Ik denk dat iedereen mijn antwoord kan raden: natuurlijk wel! Er zijn echter in mijn ogen wel bepaalde factoren nodig om een Scrumproject te laten slagen zonder kwaliteitsverlies.
1. Een scrumteam mag door een organisatie niet onder druk gezet worden om meer story's op te leveren. Zeker niet als de organisatie niet in staat is om de kwaliteit van het tussenproduct goed te controleren.
2. Een scrumteam moet in staat zijn om zonder schuldvraag hun fouten vast te stellen. Fouten zijn niet van een persoon, maar van het team als geheel. Het doel van het vinden fouten is niet een zondebok vinden, maar het streven naar een beter product en/of proces.
3. Elk scrumteamlid moet ernaar streven om trots te zijn op de opgeleverde story. Niet alleen op zijn of haar regels code, maar ook op het eindresultaat van de story als geheel. Niet alleen op de story's waar hij of zij een bijdrage heeft geleverd, maar op alle story's. Dit zal zeker niet altijd lukken, maar het moet altijd het streven zijn.
4. Scrumteamleden moeten gemotiveerd worden om kwaliteit te leveren. En gemotiveerd worden om het proces zo in te richten dat ze sneller de gewenste kwaliteit bereiken. Juist in dit laatste moet de organisatie de tijdwinst zien, die ze zo graag willen. Als het Scrumteam eerder problemen onderschept, kunnen ze eerder en vaak sneller opgelost worden. Of de problemen zullen niet eens voorkomen. En daardoor komt er weer tijd vrij om extra story's te bouwen. Maar dan wel met de gewenste kwaliteit.
Uiteindelijk komt de kwaliteit neer op de volgende regel uit de Scrumguide: "Aan het eind van een Sprint moet het nieuwe Increment “Klaar” zijn, wat betekent dat het in bruikbare toestand is en voldoet aan de Definitie van “Klaar” gebruikt door het Scrum Team." Een Increment moet dus niet alleen voldoen aan de Definition of Done, maar ook bruikbaar zijn. Een niet erg duidelijk omschreven criterium. Maar als elk lid van het Scrumteam trots is, inclusief productowner, scrummaster, programmeur en tester, dan is het bijna zeker bruikbaar. Bij elk lid dat de bruikbaarheid ter discussie stelt, blijft het nodig om kritisch naar de kwaliteit te kijken. Want te vaak heeft dat ontevreden lid wel een heel terechte opmerking over de kwaliteit, en als gevolg hiervan vaak over de bruikbaarheid. En hiervoor moet je altijd open willen en kunnen blijven.
Binnen Scrum heeft het scrumteam, terecht, heel veel vrijheid om het eigen proces in te vullen. Om bijvoorbeeld een eigen Definition of Done op te stellen. Of te bepalen welke testen er uitgevoerd zullen worden tijdens de sprint. Bij veel vrijheid komt veel verantwoordelijkheid. En daarmee veel mogelijkheid om de verkeerde weg in te slaan.
Zo kan je de acceptatiecriteria gebruiken om een story die je nooit in productie zal brengen, toch goed te laten keuren. In de acceptatiecriteria staat vaak echt niet dat bij een proces dat een halve minuut kan duren, de gebruiker moet zien dat hij moet wachten. Bijvoorbeeld met een zandlopertje. Dat zo ongeveer elke gebruiker na ongeveer 10 seconden denkt dat de site niet werkt en weggaat, doet niet ter zake. Het staat niet in de acceptatiecriteria, dus de story is goed.
En je hebt als Scrum team alle vrijheid om voor een website te besluiten om deze nu even niet in verschillende browsers te testen. Een browser is voldoende. Geschikt voor mobiel komt later wel. Dat websites juist regelmatig problemen geven op verschillende browsers, zeker op mobiel, is nu niet belangrijk. Scrum is een ideale methode om je kop in het zand te steken en door te gaan. Dat mag je tenslotte ook, want je bent zelf verantwoordelijk.
Laat ik wel eerlijk blijven: kwaliteit staat misschien bij veel Scrum projecten wel onder druk. Maar situaties die lijken op bovenstaande voorbeelden zal je niet bij alle Scrum projecten zomaar tegenkomen. Naar mijn ervaring staat kwaliteit vooral onder druk bij projecten die niet regelmatig naar productie gaan. Als een applicatie naar productie gaat en de kwaliteit is slecht, dan wordt het Scrumteam vanzelf gedwongen hun kwaliteitsproblemen aan te pakken. Geen enkele organisatie accepteert dat er drie sprints achter elkaar producten worden opgeleverd, die vervolgens weer teruggedraaid moeten worden.
Het probleem ontstaat vooral bij projecten waar de gang naar productie later is. Omdat men eerst een groot deel van de functionaliteit af wil hebben. Vaak is hier sprake van herbouw van een bestaande applicatie. De nieuwe applicatie moet dan toch minimaal vergelijkbaar zijn met de oude, voordat je naar productie gaat. Waardoor kwaliteitsproblemen meer verborgen kunnen blijven. En de redenering "Dat kunnen we in een komende sprint wel oplossen"erg geloofwaardig klinkt.
Juist bij projecten met een herbouw karakter is ook de druk vanuit de organisatie groter. Men wil resultaat zien. Hoe meer nieuwe functies, hoe meer vertrouwen men in het Scrumteam heeft. Om dit vertrouwen te winnen, kan je heel eenvoudig story's met problemen toch als afgerond beschouwen. Bij de Sprint Review kan je om de problemen heen een demo geven. De problemen schuif je door, geen probleem, je hebt nog zo veel sprints. Het resultaat van de sprint lijkt nu opeens duidelijk beter. Het probleem is alleen, dat dit de volgende sprint weer gebeurt. En de sprint erna weer. En de sprint erna weer. Op een bepaald moment heb je een volledige sprint nodig om alle problemen op te lossen. Tijd voor die sprint is er niet. En verwerken in andere sprints is moeilijk. Want op de organisatie komt dat al vrij snel over als "het team levert minder werk".
Andere manieren om veel nieuwe functies op te leveren, is om werk te besparen. En veel testtaken zijn hiervoor ideaal. Regressietesten, performancetesten, compatibiliteitstesten, ze kosten tijd. Maar niemand van de business heeft het door als je ze achterwege laat. Terwijl de extra story's zeer welkom zijn. Bouwen van nieuwe story's is ook goed zichtbaar. Testen daarentegen, je kan er nauwelijks een demo over geven. En zelfs als je het doet, de interesse is niet groot. Dat deze tijd in latere sprints, op deze manier gedacht, ook niet beschikbaar is, is van latere zorg.
Maar niet altijd is druk vanuit de organisatie de oorzaak. Veel ontwikkelaars die beginnen met Scrum hebben ook moeite om om te gaan met de vrijheid die ze krijgen. Kregen ze eerst vaak het proces voorgeschreven. En stond tot in detail de te bouwen functie uitgewerkt. Nu moeten ze het proces bijna helemaal zelf bepalen. En wat ze moeten bouwen, kan je plotseling niet meer alleen lezen... nee, je moet deze zelf bespreken . Soms zelfs zelf beslissen. Dat moet je leren, maar de tijd die hiervoor nodig is krijg je niet. Toch krijg je krijg je wel te horen dat je beslissing niet correct was; het was dan een dom besluit. Veel ontwikkelaars grijpen zo terug naar de oude papieren zekerheid: als het niet is vastgelegd, hoef ik het niet te doen. Dat geeft tenminste duidelijkheid en voorkomt dat jij fouten maakt. Het voorkomt niet dat het fout gaat, maar het voorkomt wel dat jij fouten maakt.
Is Scrum dan niet geschikt voor herbouwtrajecten? Ik denk dat iedereen mijn antwoord kan raden: natuurlijk wel! Er zijn echter in mijn ogen wel bepaalde factoren nodig om een Scrumproject te laten slagen zonder kwaliteitsverlies.
1. Een scrumteam mag door een organisatie niet onder druk gezet worden om meer story's op te leveren. Zeker niet als de organisatie niet in staat is om de kwaliteit van het tussenproduct goed te controleren.
2. Een scrumteam moet in staat zijn om zonder schuldvraag hun fouten vast te stellen. Fouten zijn niet van een persoon, maar van het team als geheel. Het doel van het vinden fouten is niet een zondebok vinden, maar het streven naar een beter product en/of proces.
3. Elk scrumteamlid moet ernaar streven om trots te zijn op de opgeleverde story. Niet alleen op zijn of haar regels code, maar ook op het eindresultaat van de story als geheel. Niet alleen op de story's waar hij of zij een bijdrage heeft geleverd, maar op alle story's. Dit zal zeker niet altijd lukken, maar het moet altijd het streven zijn.
4. Scrumteamleden moeten gemotiveerd worden om kwaliteit te leveren. En gemotiveerd worden om het proces zo in te richten dat ze sneller de gewenste kwaliteit bereiken. Juist in dit laatste moet de organisatie de tijdwinst zien, die ze zo graag willen. Als het Scrumteam eerder problemen onderschept, kunnen ze eerder en vaak sneller opgelost worden. Of de problemen zullen niet eens voorkomen. En daardoor komt er weer tijd vrij om extra story's te bouwen. Maar dan wel met de gewenste kwaliteit.
Uiteindelijk komt de kwaliteit neer op de volgende regel uit de Scrumguide: "Aan het eind van een Sprint moet het nieuwe Increment “Klaar” zijn, wat betekent dat het in bruikbare toestand is en voldoet aan de Definitie van “Klaar” gebruikt door het Scrum Team." Een Increment moet dus niet alleen voldoen aan de Definition of Done, maar ook bruikbaar zijn. Een niet erg duidelijk omschreven criterium. Maar als elk lid van het Scrumteam trots is, inclusief productowner, scrummaster, programmeur en tester, dan is het bijna zeker bruikbaar. Bij elk lid dat de bruikbaarheid ter discussie stelt, blijft het nodig om kritisch naar de kwaliteit te kijken. Want te vaak heeft dat ontevreden lid wel een heel terechte opmerking over de kwaliteit, en als gevolg hiervan vaak over de bruikbaarheid. En hiervoor moet je altijd open willen en kunnen blijven.
Abonneren op:
Posts (Atom)