• 2012/08/01
  • ALbert Mietus
  • Nederlands
  • Narrative Geïntegreerd Agile
  • Pathways Leermomentje Praktijk

Leermomentje: Afspraak is afspraak

We maken fouten om er van te leren! Dat geldt ook bij Geïntegreerd Agile. De ScrumMaster moet daarom alert zijn op denkfouten. Zodat hij zijn team een spiegel voor kan houden.

Een klassieke misvatting is dat we tijd kunnen besparen door stappen over te slaan. Iedereen maakt die fout wel eens; zeker onder tijdsdruk. Het vervelende is bovendien dat dit vaak gebeurt met de beste bedoeling. Zo ook onderstaande voorbeeld. Iemand doet een extra inspanning maar gaat toch de fout in.

Natuurlijk wil je die persoon niet demotiveren. Maar soms moet je reageren op dit soort denkfouten; voordat anderen ze overnemen. Zeker als je scrum of Geïntegreerd Agile aan het invoeren bent.

Mail aan het team

Hieronder mijn reactie per mail naar het hele team. Waarbij het altijd verstandig is om, voor vlak voor het verzenden die persoon even persoonlijk aan te spreken zodat hij snapt dat je zijn actie gebruikt als leerpunt. En niet om iemand af te straffen.

Collega’s,

Afgelopen weekeinde ontvingen we onderstaande mail, waar ik op moet reageren; als leermomentje voor het gehele team.

Ik heb niet alles kunnen testen maar stop er ff mee. […] door tijdgebrek heb ik […] besloten de voorbereiding voor het automatisch testen middels het bekende template niet te doen maar handmatig te testen …

—een teamlid

Deze mail had iedereen kunnen versturen. En laat drie zaken zien; twee goede en één die ik gebruik als leermomentje:

  1. Er wordt hard gewerkt, de inzet is goed. Immers, de mail is op zaterdag verstuurd

  2. Er wordt goed gecommuniceerd, bedankt!

  3. We denken dat we tijd besparen door handmatig te testen en dat het maken van een ATS minder belangrijk is.
    Dit is het leermomentje

De denkfout

Natuurlijk, een ATS (Automatisch Test Script) maken kost tijd; maar het uitvoeren van een handmatige test ook! De vraag is wat is goedkoper?
Het antwoord op deze vraag is afhankelijk van een aantal zaken. Zoals of we kijken we naar de kosten ‘binnen’ de sprint of naar het gehele project. Ook zijn de kosten van een ATS afhankelijk van de bestaande ATS’sen en het testframework concept.
Ook is het aantal testuitvoeringen van belang; in het algemeen geld dat hoe vaker ‘getest’ wordt, hoe groter het voordeel van automatisch testen.

Hier kunnen we een heel rekenmodel voor opstellen, maar dat is niet de essentie van het leermomentje… Het gaat om wat we afspreken en wat we doen.

De afspraak

Of we een feature automatisch testen of niet spreken we in af in de (term:P2) planning-sessie. Daarna geldt afspraak is afspraak. Immers toen hebben we bepaald wat de kosten, de investering en de baten zijn. Mede ingegeven door of we ‘binnen’ de sprint kijken, of globaal; en hoevaak we verwachten dat we de ATS kunnen hergebruiken.

Als we eenmaal aan het sprinten zijn, lopen zaken anders dan verwacht. Iedereen wil features afronden en opleveren, ook als het tegenvalt. Dat laatste betekent overgens dat er te optimistisch geschat is; zo schatten we soms ook te pessimistisch. Of -heel soms- precies goed. Maar gemiddeld, over meerdere features en een aantal sprints, moet de inschatting kloppen; dat is de essentie van het concept.
Om te zorgen het gemiddelde klopt zijn er een aantal rekenfactoren en is de globale planning geschat in relatieve FeaturePoints

Maar daarvoor moeten we ons wel houden aan de afspraak!

De misrekening

Stel, we halen het (een sprint, of een feature) niet en gaan improviseren; of deliverables, zoals een ATS niet opleveren. Rekenkundig lijkt dan alles OK. Wellicht houden we, omdat we een flink deel niet doen, zelfs tijd over. En stel, we doen dat regelmatig. De inschattingen waren dan dus te optimistisch. In het vervolg zouden we dus minder optimistisch moeten schatten, bijvoorbeeld door de k-factor iets hoger te maken. Maar omdat er tijd over leek, kan de k-factor zelfs omlaag gaan.


Het effect van een taakje ‘overslaan’ is dus dat we het drukker krijgen!

De kip en het ei

Daarnaast is er nog een probleem. Handmatig testen is niet goedkoper, het is duurder. Zeker als we kijken naar de testuitvoering. Het opzetten van de eerste ATS is ook duur. Later wordt het (vaak) goedkoper, omdat we ATS’sen kunnen hergebruiken. Die overweging is gemaakt, toen we afspraken een ATS te maken. Wellicht te optimistisch, maar toch…

Gaan we improviseren, maken we geen ATS, en gaan we handmatig testen in een poging de spint te halen, dan hebben we later een probleem. Immers, die niet gemaakte ATS kunnen we ook niet hergebruiken. Niet in een hertest, niet als regressietest en niet bij een volgende Feature of sprint.
En dus is de volgende ATS weer lastig, slaan we die weer over, moeten we weer handmatig testen, etc.

Probeer dit soort zaken dus altijd te voorkomen. Stap één hierbij is beter, nadrukkelijker plannen in de P2 sessie. Denk je dat een ATS geen goede keuze is, laat het dan weten. Kiezen we voor een ATS, laten we die dan eerlijk inschatten. Maar daarna geldt afspraak is afspraak!

Natuurlijk zijn afspraken er ook om van af te wijken. Maar bedenk dan wat het effect is.

  1. Een paar uur duurder?
    Geen probleem gewoon de T2C bijstellen

  2. Heel veel duurder?
    Ook geen probleem! Even overleggen in de standup en of met je ScrumMaster en de T2C bijstellen. Desnoods doen we dan een feature minder.

  3. Het lijkt beter om andere aanpak te kiezen, meer werk te verzetten, of minder op te leveren (hier: geen ATS opleveren. Ook vaak: minder documentatie)?
    Niet zo maar doen! Dit wil zeggen dat afspraken herzien worden. Dat kan, maar moet in overleg met de klant. En met een goed verhaal is dat zelden een probleem. En als het dat wel is, los ik (de ScrumMaster) het op.

  4. Een paar of een flink aantal uren goedkoper?
    Ook geen probleem, gewoon de T2C bijstellen. Desnoods doen we een feature extra, of hebben we ruimte om tegenvallers op te vangen!

Effect

De aanleiding van deze mail was het een mailtje over handmatig testen. Maar de fout die met deze mail opgelost werd was veel groter.
Kennelijk begreep niet iedereen het doel van de planning-sessies. Het gaat niet (alleen) om de planning. Het gaat ook (en vooral!) over een realistisch planning. W waar het hele team zijn zich aan ‘commit’; Zo willen we het gaan doen, dat kost het en die belofte proberen we waar te maken!

Daarom heeft elk teamlid invloed op die planning; zowel in de Planning 1 als in de Planning 2 sessies. Dat is soms nieuw en onwennig. En ‘anders’ dan in traditionele projecten, waar een planning vaak opgelegd word. En als die onrealistisch is, trekt niemand zich er wat van aan…

In Geïntegreerd Agile (en Scrum) is ‘commitment’ belangrijk. We besteden veel tijd aan de planning; anders, maar ook meer dan in een traditioneel project. Zodat we een realistisch planning hebben! Want ‘afspraak is afspraak’; al zijn er altijd uitzonderingen.

In dit projectteam bleek dat we soms niet helemaal realistisch waren. De tijd en kennis ontbrak om goede ATS’sen te maken. Door deze mail kwam dat aan het licht; en konden we dat oppakken.
Zo leerden we dat bijvoorbeeld dat een extra training nodig was om effectief een ATSsen te schrijven. En dat we die taken voorlopig voor een ietsje ruimer, realistischer, moeten plannen.

Disqus

Aardige feedback is altijd welkom, evenals alternative meningen; zolang ze relevant zijn voor alle lezers. Hiervoor gebruik ik momenteel ‘Disqus’.

comments powered by Disqus