x

Inloggen

Je bent nog niet ingelogd. Aanmelden of een nieuw account Registreren

Agile in de praktijk, deel 01. Het teamoverleg

Door Suzefred gepubliceerd op Sunday 20 July 11:30

“Want nergens leer je zoveel, als in een opdracht waar niets valt te leren”

deel 1

303798c57fd91b3142dffa52b14dcb49_1405852

 

Het is het moment waarop heel veel samenkomt en wat mij doet besluiten om dit vast te leggen voor diegenen die wellicht hetzelfde meemaken en benieuwd zijn naar ervaringen van voorgangers.

Wat speelt er allemaal:

Een klant waar ik ingezet ben om te komen testen. Een klant die beweert Agile te werken want “we staan elke dag bij elkaar en maken geen documentatie”. Een opdracht ook waar regelmatig gezegd wordt ‘een zesje is goed genoeg’. De applicaties waar het hier om gaat, zijn applicaties die door het eigen personeel gebruikt worden, waardoor ook regelmatig gezegd wordt "als er iets niet goed is, dan horen we dat snel genoeg". De prioriteit ligt dan ook niet in eerste instantie om perfecte software naar de klant (de eigen medewerkers) te brengen, maar lijkt eerder te liggen in de kracht die we hebben, het snel oplossen van eventuele productiebevindingen en het snel opnieuw kunnen releasen.

Als tester heb ik dit eens een tijdje aangekeken en ik heb me meerdere malen lopen verbazen.

Na mijn vraag waar ik de documentatie kon vinden, wat resulteerde in het antwoord ‘die hebben we niet, want we werken volgens Agile’, besloot ik naar de bouwers te gaan om daar informatie in te winnen. Dat werd echter niet gewaardeerd want "de bouwers hebben het druk dus die moest ik maar niet lastig vallen". Toen ik begon uit te leggen dat ik toch wel iets van informatie op prijs zou stellen zodat ik kon gaan testen kwam het bijzondere antwoord dat ik juist geen informatie zou moeten willen hebben, "omdat ik dan niet objectief meer was. Kijk maar gewoon of je rare dingen ziet".

Het bleek een bijzondere opdracht te worden. Een opdracht waar sommige collega’s het dan ook niet volhielden en weg wilden. Om meerdere redenen, maar ook "omdat er toch niets te leren viel en dat is slecht voor mijn carrière en groeipad". Ik besloot het anders aan te pakken.

Want nergens leer je zoveel als op een opdracht waarin niets te leren valt.

Als mijn rol niet meer blijkt te zijn dan een vinkje achter de regel 'is er getest?’, dan ligt daar een kans om juist heel veel te leren. En te verbeteren.

Hieronder een verzameling van leer- en verbeterpunten, uit eigen praktijk.

 

Agile in name only. Het teamoverleg.

Het bij elkaar komen, de zogenaamde daily-standup, bleken ze inderdaad te doen. Elke dag, om half 9 kwam het team bij elkaar. Soms, als bleek dat collega’s ‘pas’ om half 9 binnenkwamen, laste de teamleider een overleg in om 8 uur waarbij iedereen vriendelijk doch dringend verzocht werd om daarbij aanwezig te zijn. Het was mijn eerste ervaring met wat ik zou willen kwalificeren als de Management by Fear-stijl.

En daar stonden we dan, met een man of 20 in een cirkel, te praten over wat er allemaal gaande was. Soms gingen de discussies alle kanten op en stonden we een uur bij elkaar. Mijn ervaringen met Agile waren tot die tijd nul komma nul, tot nu toe had ik enkel de zogenaamde waterval-projecten gehad en als dit dan de zogenaamde daily standup was, nou ja, dan zal dat wel zo horen.

Maar omdat ik nu eenmaal graag lees en leer, begon ik me ook eens te verdiepen in de wereld van Agile. Ik ging eens te rade bij collega’s met wie ik in de cirkel stond. Een ervan deelde de mening dat er weliswaar beweerd werd Agile te werken, maar dat dit niet Agile was. Een standup zou niet langer moeten duren dat 15 minuten, het team was veel te groot, de discussies waren voor 18 van de 20 mensen niet interessant, eigenlijk was het zonde van de toch al beperkte tijd.

Ik was blij dit te horen want het is best wel krom om te horen dat je de bouwers niet lastig mag vallen omdat ze het druk hebben om ze vervolgens verveeld in een cirkel te zien staan.

De persoon zelf bleek gecertificeerd Scrum-master te zijn. Een mooie kans om dus eens te peilen hoe een en ander dan eigenlijk zou moeten gaan. En kunnen we dan niet meteen wat wijzigingen doorvoeren? Kunnen we het bijvoorbeeld niet gewoon wat beperkter houden, dat overleg.

En ja hoor, de eerste wijzigingen werden zachtjes aan doorgevoerd. De eerste keer tijdens de afwezigheid van de teamleider. Afspraak: we vertellen waar we mee bezig zijn en waar we tegenaan lopen. Volgt er een discussie uit of zit je ergens mee waar een andere collega mee kan helpen, dan zoeken die 2 collega’s elkaar na de meeting op.

Het is nog even wennen, maar het went snel. Het overleg gaat meteen een stuk vlotter, iedereen vertelt de status aan elkaar, het is een overleg geworden door en voor collega’s. In sommige gevallen worden afspraken gemaakt tussen een paar collega’s om elkaar na het overleg even op te zoeken en gaat de rest weer aan het werk.

De eerste de beste keer dat de teamleider er zelfs ook bij is, gaat het echter meteen weer mis. In plaats van dat het gesprek er door en voor de collega’s is, lijkt het meer een statuspraatje richting de teamleider te zijn. Deze gaat er steeds dieper op in, waardoor even later weer de discussies plaatsvinden waar 18 van de 20 mensen geen belang bij hebben.

De rest kijkt elkaar even aan en kijkt vervolgens toe. Ik besluit de stoute schoenen aan te trekken en de teamleider erop aan te spreken.  Ik voel de blikken van de collega’s op me gericht en daarna op de teamleider, wachtend wat de uitwerking van mijn verhaal en vraag is. Waarschijnlijk tot ieders verrassing pakt hij het goed op, breekt het verhaal af met de melding aan een van de collega’s om de discussie na de meeting even voor te zetten en bedankt me. Van een enkele collega krijg ik een knipoog, van een ander een duim. Het is een rare ervaring.

Het sterkt me om er meer mee te gaan doen.

 

(advertentie)

Lees meer over Agile

 

09e00e2808c23813a6008833164a4b1e_medium. Fred Steenbergen is beroepsmatig Testspecialist. Zijn vrije tijd gaat grotendeels op aan het vrijwilligerswerk voor Stichting Dierenopvang Bosnië Hiermee gaat hij meerdere keren per jaar naar Bosnië om daar te helpen met het steriliseren van zwerfhonden.
Wilt u ook helpen? Helpen kan gratis!
U kunt bijvoorbeeld een verschil maken met Douwe Egberts Punten.
En wanneer deed u voor het laatst iets met uw Air Miles?
Ik flikker hem nog liever in de sloot!!!” Waar dat op slaat? Dat leest u hier.

Anderen lazen ook:

    b5e864d1cb867ef6794a99a0114c8347_medium.
   

Agile, deel 2

Bij elkaar zitten

Reacties (8) 

Voordat je kunt reageren moet je aangemeld zijn. Login of maak een gratis account aan.
haha, mooi beschreven, en er floept meteen een advertentie bij van certifieid scrum.org training.
Het is allemaal zo doorzichtig: een of andere goeroe (bij selfproclamatie) verzint een managmentstijl, die wordt hopeloos verkeerd gekopieerd, neen beter: dingetjes die wel aardig lijken worden overgenomen, en vervolgens wordt het gezond verstand overboord gegooid.

Die spagaat over dat testen laat zich het best vergelijken met het controleren of je huis wel inbraakvrij is: laat je dat doen door een willekeurig iemand die niet weet waar hij naar moet kijken, of laat je dat doen door een specialist die precies weet waar hij naar moet kijken.
En vervolgens: als je iets aanpast omdat het niet goed was, bijvoorbeeld het zolderraam aan de zuidkant, laat je dan vervolgens wéér alles testen, of wijs je de teester meteen op het zolderraam aan de zuidkant.

Miischien niet zo slim om deze kritiek zo open en bloot op het www te gooien ?
Hoi De-realist,
dankjewel voor je reactie, en bedankt ook voor die laatste zin,
daar heb ik zelf natuurlijk ook over nagedacht,
en misschien komt dat in dit stuk nog wat te weinig naar voren, (zeker een punt waarop ik het even terug moet lezen, dank daarvoor dus), maar hoewel het kritiek is vanuit mijn testvisie, is het ook juist een leerpunt gebleken voor mij.
Waarmee ik bedoel dat wat hier misschien nog als kritiek klinkt, in sommige gevallen juist meer aan mezelf bleek te liggen.
Het komt bij de vervolgdelen ongetwijfeld meer tevoorschijn, dat ikzelf juist ook een omslag moet maken.
Als tester ben ik redelijk perfectionistisch en wil dat 'alles perfect is' voordat het doorgaat naar de volgende fase.
Als ik zelf zie dat anderen uitgaan van een houding als 'een zesje is goed genoeg', dan gaan bij mij de nekharen overeind staan.
Echter, nu ik wat langer meega (de ervaringen die ik hier beschrijf startten al een tijd terug), merk ik ook dat veel punten juist wel hout snijden. Alleen de '6 is goed genoeg' is op een andere manier bedoelt dan wat ik daarin hoorde. Hopelijk komt dat in de komende delen nog wat meer naar boven, en blijkt het dat we het juist heel goed doen, alleen vanuit mijn testblik richt ik me eerder op de punten die beter kunnen ;-)
Groetjes,
Fred.
ik heb de hele agile-filosofie ook even nagekeken. Het gaat dus met name om softwareontwikkeling. Wel opvallend als je het at kritischer leest, want dan heb je dus geen plan, geen contract met de klant, geen documentatie en (en daar is de 6-jesgedachte) niet te perfectionistisch, maar vooral blijven bouwen, blijven verbeteren, maar ook blijven opleveren. Niet te lang alles van tevoren maar proberen helemaal uit te stippelen, want dat gaat je toch niet lukken. In die zin nogal een omslag i n denken inderdaad. Goed mogeljk dat er bepaalde omgevingen zijn waarin dat beter werkt: snel veranderende omgevingen met name.

Het is nu vakantie, en vanuit die vakantie-filosofie kun je dus de hele vakantie plannen, uitstippelen en alles voorkauwen, en het tegenovergestelde is zonder enige voorbereiding maar van huis gaan, en dingen gaandeweg oplossen.

Je haalt wel dingen aan, zoals het overleg, waarin jij niet de enige bent die nog moet leren.
Het is inderdaad een leerproces, voor heel veel mensen. Het vraagt inderdaad ook een andere kijk op de zaak. De vakantievergelijking is een mooie, daar zou je een beetje het verschil kunnen zien tussen heel lang discussiëren over waar we nu naartoe zouden gaan en uiteindelijk nergens naartoe gaan, of juist inderdaad maar 'op pad gaan' en steeds aan het eind van de dag kijken of we nog ongeveer de goeie kant opgaan en zo nodig bijsturen. Misschien kom je uiteindelijk tot de conclusie dat het einddoel niet realistisch meer is, en besluit je alsnog naar huis te gaan, maar dan heb je in ieder geval een stuk vakantie gehad. (vergelijk met het bedrijfsleven, de bekende projecten van 2 jaar waarbij aan het eind 'niks is opgeleverd', maar wel veel geld in geïnvesteerd is. Agile is dan meer met de klant om de tafel en meer in kleinere delen denken en samen besluiten welke kleine delen als eerste opgepakt worden. Elk opgepakt deel moet dan aan het eind van die korte periode 'af' zijn, klaar om in gebruik genomen te worden. Daarna herhaald het zich met wederom een klein deel (of meerdere kleine delen). In dezelfde tijd, tegen dezelfde kosten, met hetzelfde team. En ook hier kijk je aan het eind weer. Het kan zijn dat uiteindelijk besloten wordt dat het ooit gedachte einddoel helemaal niet meer gewenst is, dan stuur je bij, of blaast de boel af, maar dan heb je dus wel een aantal keer waardevolle delen gehad, in plaats van nog nooit iets (en de angst om te stoppen omdat er al zoveel geld in is gestoken).
Ik ben er nu ook actiever mee bezig en ik zie er de voordelen wel van in, het vraagt alleen wel wat van het team en de omgeving.
Dank voor je reactie!
het grappige is dan weer: het is dus een filosofie van iets totaal anders aanpakken, maar ....stelt het je in staat om zélf, als project, iets totaal anders op te leveren ? Want je bent natuurlijk, met die hapklare kleine blokken, incrementeel aan het veranderen ! Wie heeft er dan nog de visie, het overzicht en de resources om iets te bedenken wat totaal verschilt qua bedrijfsvoering dan dat je het nu deed ?