Creative Commons License by Eneas

Het leuke van een groot bedrijf is dat je de hele tijd nieuwe mensen blijft ontmoeten. Zo hoorde ik bij de koffie automaat een paar, voor mij tot dan onbekende, collega’s praten over hun Daily Scrum. Ik kon even stiekem mee blijven luisteren en aangezien ze mij ook niet kenden verwachtten ze geen inbreng van mijn kant.

De Daily Scrum deden ze inderdaad dagelijks, en met het hele team. En zover ik begreep voldeed het redelijkerwijs aan het formaat van ‘wat deed je, wat ga je doen en wat zat er in de weg’. Alhoewel, dat laatste weet ik niet heel zeker.

Hun gezamenlijke klacht was echter dat ondanks de Daily Scrum de Sprint niet gehaald werd. Iedereen noemde de dingen die hij gedaan had en na de Daily Scrum ging men gewoon verder. Aan het eind van de Sprint was wellicht 60% van de dingen gedaan. Dit ging Sprint na Sprint zo.

Voor mij was dit het moment waarop ik mij afvroeg of ze dan de volgende Sprint wat met het bereikte resultaat deden voor hun nieuwe planning en dus besloot ik mij in het gesprek in te mengen. Ze wisten mij te vertellen dat ze inderdaad hun velocity bij hadden gesteld maar dat dit probleem echter bleef.

Hun eigen observatie was dat de Daily Scrum niet leidde tot aanpassing binnen de Sprint, maar ze waren eigenlijk niet zeker of dat wel de bedoeling was van de Daily Scrum. Het gebeurde vaak dat ze op een laat moment – in hun korte sprint – erachter kwamen dat ze het niet gingen halen. De resterende tijd vulden ze dan met het oplossen van diverse bugs. Nuttig werk, maar niet dat waarop de rest van het project gerekend had,

Ik denk dat er meerdere teams zo Scrum doen. Elke dag weer vertellen ze elkaar wat ze gisteren van plan waren te doen – maar niet gedaan hebben – wat ze vandaag zouden willen gaan doen  en dat er niets is wat ze in de weg zit.

Ik denk ook dat er vele “Team Leads-als-ScrumMasters” het niet eens zo erg vinden. De Daily Scrum is voor hen meer een manier om een status rapport te ontvangen en te controleren of hun mensen aan de juiste dingen werken en niet om problemen voor het team op te lossen. En dat is jammer. Door op deze manier er mee om te gaan verwordt het tot een vervelende en nutteloze activiteit.

De Daily Scrum zit niet zomaar in Scrum opgenomen. Een van de basis gedachten onder Scrum is dat je continu moet kijken of je je aan moet passen aan de laatste gegevens die je tot je beschikking hebt. Voor een release doe je dat door je Sprint Planning en Sprint Review, voor het team door middel van een Retrospective. Maar in de Sprint doe je dat door je Daily Scrum.

Door dagelijks naar je taken en je Sprint Burndown te kijken zou je een goed beeld moeten krijgen over waar je staat, maar dat wil nog niet zeggen dat je even stil staat bij je situatie. En dus kom je als team er te laat achter dat je de Sprint niet meer gaat halen en rest alleen nog de optie om een aantal Backlog Items te schrappen en je stakeholders teleur te stellen.

Als ScrumMaster kan je dit verbeteren door dagelijks van de Daily Scrum een STEP moment te maken. De STEP afkorting – Stop, Think, Evaluate & Proceed – helpt je om uit de routine te stappen om je bewust te laten observeren welke keuzes je hebt.

Stop – Het ideale moment wordt je al reeds op een presenteer blaadje aangeboden. De Daily Scrum is het moment om stil te staan bij wat er de rest van de Sprint nog op je pad gaat komen. Toch moet je even expliciet stilstaan bij dit doel. Voorkom dat je het slechts gaat hebben over de inhoud, door middel van de drie vragen, maar het doel, het halen van de Sprint Goal, daarmee uit het oog verliezend.

Think – Waar staan we in de Sprint? Wat moeten we doen om de Sprint Goal te behalen? Als alles goed lijkt te gaan is de verleiding groot om te besluiten door te gaan zoals we reeds deden, maar is dit terecht? Is er nieuwe informatie beschikbaar? Als het krap lijkt te worden, welke opties hebben we voorhanden? Je kunt bijvoorbeeld de scope van een aantal items vereenvoudigen dusdanig dat ze nog wel binnen het doel vallen. Overwerk, ‘s avonds of in het weekend is ook een reële mogelijkheid. De Sprint kan ook geannuleerd worden om aan te geven dat het helemaal niet realistisch meer is. Opties genoeg.

Evaluate – De informatie en de opties zijn hiervoor zonder filtering vergaard en er moet een beslissing genomen worden hoe door te gaan. Wat acceptabel is hangt van het team en bedrijf af. Zo zou overwerk vanuit sustainable pace af kunnen vallen, maar juist weer acceptabel zijn vanuit een team commitment. De scope aanpassen gaat prima in een omgeving die gewend  is om flexibele omschrijvingen te geven, maar is onacceptabel voor bedrijven die gedetailleerde requirements voorschrijven. Wees je bewust van deze filters en stel deze eventueel aan de kaak als ze te benauwend zijn.

Proceed -  Als team neem je een besluit. De uitkomst van deze stap is duidelijk en daarmee ook de verantwoordelijkheid van het team. Ook als het besluit was om gewoon door te rennen in de richting die ingeslagen was.

Om het team vloeiend door deze stappen heen te helpen is goede facilitatie van een proces coach – de ScrumMaster- nodig. Het is een natuurlijk gedrag om zonder stil staan door te lopen om er te laat achter te komen dat je eerder een andere keuze had moeten maken. Het is een natuurlijk gedrag om bij het nadenken over je opties al diverse mogelijkheden uit te sluiten. De ScrumMaster kan het team helpen deze natuurlijke neigingen te overwinnen.

Door elke dag een STEP moment in te bouwen help je het team om eigenaarschap te verkrijgen over het behaalde resultaat en de verwachtingen naar andere stakeholders waar te maken. Op deze manier groeit niet alleen het vertrouwen van de organisatie in het team, maar ook het vertrouwen in eigen kunnen wordt groter. Daarmee wordt uiteindelijk de spiraal omgebogen naar een team wat steeds meer en meer kan en durft te doen.

Een dōjō is de zaal waarin men op een veilige manier werkt aan zijn of haar vaardigheden van diverse Japanse vechtkunst en -sporten zoals Jiu-Jitsu, Judo, Karate en Aikido. Dit gebeurt onder andere met kata’s (型) en randori’s (乱取り).Een kata is puur gericht op de vorm en kent vaststaande stappen en technieken. Een randori is vrijer en interactiever. Een deelnemer wordt geplaatst in een gecontroleerde en veilige aanvalssituatie.

Een coding dōjō is een bijeenkomst van een aantal ontwikkelaars die bij elkaar komen om een uitdaging aan te gaan en om daarmee hun vakmanschap te verbeteren door te delen en te observeren en plezier te hebben. Dit kan met behulp van een oefening met vaststaande stappen (kata) of met een interactievere vorm (randori).

Een randori stijl coding dōjō is eenvoudig op te zetten. Het enige wat je nodig hebt is een ruimte waarin je een computer op een beamer kan aansluiten en voldoende stoelen om iedereen plaats te geven. Er zijn steeds twee mensen bezig met het probleem verder te brengen en de rest van de aanwezigen mag zich actief bemoeien met de oplossing. Om de paar minuten (5…7) wisselt een van de twee voor iemand uit het publiek en begint een nieuwe ronde. Interactiviteit en plezier verzekerd.

In lijn van de toepassing van de Japanse vechtsport termen wordt bij de coding dōjō de facilitator sensei genoemd, maar het blijft uiteindelijk faciliteren. Mocht je de rol van facilitator op je nemen dan zou ik je de volgende punten willen meegeven die ik ervaren heb:

1. Vraag je ten eerste af of de groep deelnemers die je uitgenodigd hebt überhaubt wel de technieken onder de knie heeft. Is er een groep die eigenlijk nog nooit iets met Test Driven Development gedaan heeft dan zullen zij niet spontaan begrijpen hoe ze het moeten aanpakken en wat de anderen eigenlijk aan het doen zijn. Voor hen is het verloren tijd, met veel discussies over het nut van TDD. Wellicht is het dan een betere optie om eerst een keer uit te leggen hoe TDD werkt.
2. Voor het kiezen van een opdracht zijn diverse voorbeeld kata’s beschikbaar op internet en vaak ook uitwerkingen. Stel jezelf dus de vraag hoe vroeg je van te voren bekend wil maken welk kata je wilt gaan gebruiken. Een aantal deelnemers zullen van te voren gaan kijken naar mogelijke oplossingen van iemand anders. Daarna is het moeilijk om niet het idee van die ander als basis te nemen als je het gezien hebt. Het beperkt dus de creativiteit.
3. Ook zijn er altijd mensen die die voorbereiding niet gedaan hebben, het gevolg kan zijn dat zij minder gaan participiëren. Je geplande randori stijl sessie veranderd daarmee meer naar een demonstratie, kata stijl. Dat hoeft niet fout te zijn, maar neem het mee in je overweging.
4. Zorg voor voldoende kopieën van de opdracht. Iedereen moet de opdracht tot zijn of haar beschikking hebben om zo het op zich in te laten werken, om het proces te laten werken. Een opgehangen opdracht heeft als probleem dat het niet leesbaar is vanuit de zitplaatsen van de deelnemers. Die moeten dan actief naar de opdracht toe lopen. Velen zullen dat niet doen, of uitstellen, en vergeten dan de details. Met als gevolg dat het niet meer te volgen is en ze dus minder mee gaan doen.
5. In tegenstelling tot een retrospective is het verstandig om actief te faciliteren. Het is geen oefening in groepsdynamiek, maar het zal blijken dat als je niet actief stuurt op de groepsdynamiek het meer een probleem gaat worden van hoe een groep mensen actief moet samen werken dan een oefening in de aangeboden kata. Leg desnoods af en toe de sessie stil en vraag de groep om eerst even na te denken. Het kan blokkerend werken voor hen die achter het toetsenbord zitten als de rest van de aanwezigen vol enthousiasme allerlij aanwijzingen zitten te roepen. Stimuleer hun om zelf te bepalen welke eerstvolgende test ze wensen te gaan implementeren. Ook bij een randori geldt dat als je niet weet waar je heen wilt je er ook niet gaat komen.
6. Verder kan ook blijken dat er sterke meningen zijn over stijl en aanpak. Deze sterke meningen kunnen tot verhitte discussies leiden die de aandacht weghalen van de eenvoud van de opdracht en zorgen voor een negatieve sfeer in de groep. Deze negatieve sfeer beïnvloed het vermogen van alle aanwezigen om te leren. Een coding dōjō gaat niet om stijl maar effectiviteit.
7. Dezelfde sterke meningen kunnen er ook voor zorgen dat bij elke ronde een stuk werk van de vorige weer wordt weggehaald. Daar waar de ene het prima vindt om een variable array door te geven veranderd de andere dat weer doodleuk in een lijst. Waar de ene een for-each loop gebruikt verandert de andere dat weer in een gewone for loop. Refactoren is prima, maar men kan er ook in blijven hangen.
8. 5..7 minuten wissel regel kan er voor zorgen dat de twee mensen die de oplossing ontwikkelen steeds in de fase blijven hangen om bij elkaar af te tasten wat zij als oplossing denken te zien. Dit met de druk dat je voor een groep mensen met ‘betere meningen’ zit kan een writer’s block veroorzaken.

Een sessie is geslaagd wanneer binnen de beschikbare tijd de oplossing gemaakt is en de deelnemers het gevoel hebben dit ook zelf te kunnen doen. Het is een succes als in ieder geval een aantal deelnemers het gevoel heeft dat ze iets van een ander geleerd hebben, een nieuwe strategie of techniek die ze zelf graag willen gaan toepassen.

はじめ!

Er is vaak wel aandacht voor het doel dat het team dient te halen. Het ‘wat & hoe’ is één as die nodig is om tot een team te komen. Traditionele projecten proberen dit vanaf het begin af aan vast te leggen en spenderen veel tijd en energie in het controleren en bijwerken van dit aspect van een project. Hiermee wordt een groep mensen echter geen team. De onderlinge taken zijn wellicht vastgelegd, maar een team is geen groep individuen die slechts zijn taken uitvoert. Een team is een groep mensen die op een effectieve manier kan reageren op onverwachte gebeurtenissen, buiten hun eigen taakstelling.

Er is echter nog een as nodig, het proces. Door toevoeging van proces kunnen mensen met elkaar gaan samenwerken. Het maakt duidelijk wie wat van elkaar mag verwachten en waar de grenzen liggen. Traditionele en agile projecten voegen beide een nog een ‘proces’ aspect toe. Traditionele processen richten zich echter vaak op het ‘wat & hoe’ zoals risico management, exception management en change control boards. Agile frameworks richten zich vaker op het kunnen reageren op onverwachte gebeurtenissen – ze verwachten het onverwachte – door middel van iteraties, daily standups en retrospectives.

Deze aspecten worden het ‘harde proces’ genoemd en Scrum stelt hiervoor de ScrumMaster verantwoordelijk. Hij is uiteindelijk degene die ervoor zorgt dat het team het proces volgt. Hij zorgt ervoor dat de Product Owner voorbereid is als hij bij de Sprint Planning aan schuift, hij zorgt ervoor dat de juiste aspecten besproken worden tijdens de Daily Scrum. Bij niet iedereen doed de ScrumMaster dit zelf, maar het voordeel van iemand die zich met dit aspect bezig houdt is dat de rest van de teamleden zich met de resultaten kunnen bezighouden zonder dat het proces er onder gaat lijden. Het combineren van een ScrumMaster en ontwikkelaarstaak is om deze reden heel moeilijk te doen.

Om het team nog succesvoller te maken moet er ook aandacht zijn voor de zachte kant van het proces. Hoe voelen de teamleden zich? Kunnen ze het werk nog aan? Hebben ze te veel hooi op de vork genomen of maken ze zich er gemakkelijk van af? Werken de afgesproken processen werkelijk of blijkt dat het onderhuids toch stiekem irriteert?

Alhoewel een retrospective de ultieme plek lijkt om aandacht te hebben voor de zachte kant is het de vraag of dat gebeurt. Teams die onvoldoende aandacht hebben gehad gedurende de iteratie voor die zachte kant zullen die niet plots gaan uiten bij een retrospective. De retrospectives blijven oppervlakkig en de onderhuidse gevoelens onuitgesproken. Dit resulteert in geen of wellicht slechte acties, en in de volgende keer nog meer onuitgesproken emoties.

Een lastig aspect van gevoelens is dat ze niet oppervlakkig meetbaar zijn. Ze zijn niet op te delen in deeltaken, noch te beschrijven in ceremonies. Degene die de emotie waarneemt neemt slechts zijn interpretatie van de emotie waar, beïnvloed door zijn eigen perspectief en emoties. Degene die de emotie heeft hoeft zich niet bewust te zijn van deze emotie of drukt deze weg, onzeker of de rest van het team op het uiten hiervan zal reageren.

Het wordt als professioneel beschouwt om je niet te laten beïnvloeden door je emoties. Toch bepalen die emoties direct hoe je je werk uit voert. En het team wordt beïnvloed door de diverse emoties van elk individueel team lid. Het niet onderkennen van deze emoties, het niet bespreekbaar maken zorgt voor een team waarin iedereen afstand houdt.

Als ScrumMaster kan je je effectiviteit verhogen door oog en oor te hebben voor dit zachte aspect. En door je eigen effectiviteit hierin te verhogen vergroot je de cohesie en effectiviteit van het team. Je creëert een vangnet waarin mensen zich veilig gaan voelen, wetende dat als het mist in gaat iemand dat op zal merken om ze op te vangen. Door dit vangnet kunnen de angsten waardoor men zich inhoudt vrij gelaten worden en gaat het team verder dan ze eerder durfden te gaan.

Bedrijven worstelen met de rol ScrumMaster. De toegevoegde waarde lijkt lastig te definiëren en vervalt soms tot een taak die eenvoudig te roteren is onder de teamleden. Daarmee is het een overhead taak geworden, een taak die weg geoptimaliseerd zou kunnen worden. Door je als ScrumMaster niet alleen te richten op de harde kant van het proces, maar ook te richten op de zachte kant, maak je de taak van een ScrumMaster zeer waardevol en geef je het team de kracht om tot volle wasdom te komen.

Om acht uur gaat Toms wekker af. Om kwart over acht gaat hij naar de keuken en zet een grote pot thee. Rond een uur of half negen komen zijn vrouw en kinderen uit bed en gaan ze ontbijten. Om negen uur kust Tom zijn vrouw en kinderen gedag en rijdt hij naar zijn werk.

Gelezen? Beantwoord de vragen, zonder het verhaal opnieuw te lezen met ja, nee, of ik weet het niet. Dat laatste kan natuurlijk gebeuren als je het te snel leest.

Stond Tom om acht uur op? Ging hij om kwart over acht naar beneden naar de keuken om een grote pot thee te zetten? Heeft hij samen met zijn vrouw en kinderen rond half negen thee gedronken? Heeft hij twee kinderen? Reed hij met zijn auto naar zijn werk?

Bron: Psychologie Magazine mei 2011

Dit is een eenvoudig verhaaltje met niet al te moeilijke vragen. Als je echter een van de vragen bevestigend of ontkennend hebt beantwoord dan moet je het verhaal nog eens lezen. Voor elke vraag kan slechts gezegd worden dat het niet bekend is.

Hoe we het beantwoorden hangt af van onze eigen situatie en gewoontes. We vullen dus in naar dat zelf gewend zijn om te doen. Sta je gelijk op als je wekker gegaan is dan heb je de neiging om aan te geven dat Tom inderdaad om acht uur uit bed ging. Ben je gewend om nog even in bed te leggen dan heb je wellicht aangenomen dat Tom om kwart over acht in zijn pyjama naar beneden ging om de thee te gaan zetten.

Je hersenen doen dat niet voor niets. Ze moeten uit de continue stroom van de je omringende informatie zo snel mogelijk de kern weten te extraheren zodat je er op kan reageren. Indelen in voor jou bekende patronen helpen de hersenen om dat efficiënt te doen.

Hetzelfde fenomeen doet zich ook voor bij requirements documenten of design modellen. Voor de schrijver van het document is het duidelijk wat er geschreven staat, is het klip en klaar wat er bedoeld wordt. Voor de lezer is het net zo duidelijk, maar wel op zijn eigen manier.

Heb je veel achtergrond in enterprise projecten dan zal je automatisch de patronen toepassen die daar gebruikelijk zijn. Je zal ze als het ware zelf invullen in de UML diagrammen die voor je liggen. Groot zal de verrassing zijn als niet zo gedaan wordt als je dacht. De auteur kijkt je verbaast aan, je had het toch kunnen lezen?

Waar je bij UML diagrammen nog potentieel het voordeel hebt dat het minder ambigu zou moeten zijn, bij geschreven documenten is het nog lastiger. Menig document wat een project beschrijft en menig document waarin de requirements staan worden door de ontvanger gelezen om zijn manier, met zijn gedachtegang.

Bij de mogelijke antwoorden heb ik aangegeven dat je het ook zou kunnen beantwoorden met ‘ik weet het niet’, naar nu blijkt het juiste antwoord. Ik heb je echter proberen te beïnvloeden dat niet te doen door te stellen dat dat zou betekenen dat je waarschijnlijk de tekst te snel gelezen hebt, en dat is een beetje dom.

De angst om een beetje dom gevonden te worden speelt ook parten bij het lezen van documenten. Niemand wil dom gevonden worden en het is makkelijker om kleine vragen niet te stellen. Intelligente mensen begrijpen het namelijk wél.

Hieruit volgt dat dergelijke documenten slecht dienst doen als contract. Je kan als schrijver nou eenmaal niet bewust zijn van de onbewuste aannames van je potentiële lezers. Zelfs als je een review sessie organiseert weet je nog niet zeker of iedereen het invult zoals jij dat hebt gedaan, want ook jouw aannames zijn onbewust gemaakt.

Wees je bij elk geschreven document wat vast probeert te leggen wat en wat je gaat maken ervan bewust van de beperkte waarde ervan. Probeer het niet te compenseren door nóg meer te gaan schrijven. Eerder minder, je lezer gaat toch invullen.

Het Agile adagium “working software over comprehensive documentation” is niet zomaar een advies geboren uit frustratie of vanuit een Lean gedachte dat tussenproducten vermeden dienen te worden. Het is een gedegen advies, gesteund door de psychologie.

Onbewust viel het me al een tijdje op, maar de eerste bewuste ervaring had ik vorig jaar bij Agile Open Holland. Ik was geïntereseerd in hoe anderen hun Sprint II planning doen en had dus een sessie voorgesteld. In plaats dat er verhalen kwamen over hun ervaringen kreeg ik een spervuur van vragen over mij heen die mij eigenlijk er van probeerde te overtuigen dat ik het fout deed. Zo waren volgens mijn gespreksgenoten de stories véél te groot, die moesten in kleinere stukjes opgehakt worden.

De aannames die hier gemaakt werden was dus dat je stories moet gebruiken en dat je ze in kleine stukjes moet verdelen. Jazeker, dit is een advies dat je vaker hoort en wellicht in veel gevallen een goed werkend mechanisme, maar het moet niet. Voor ons voegde het simpelweg niet zo veel toe. Wij hadden een goed werkend mechanisme, passend bij onze omgeving.

Maar dat is blijkbaar onvoldoende. Zo lijkt het tegenwoordig verboden om een Sprint Burndown bij te houden, je moet eenvoudig taken tellen. Taken maken? Is ook overbodig en een waste. En waste moet je met harde hand uitbannen. Nadenken voordat je iets doet? Verspilling! Niemand doet dat meer. Dus wat betreft mijn vraag over Sprint II planningen, zo old school.

Schrijf je nog code zonder xUnit tests? Heb je geen geautomatiseerde acceptance testen? Fout, fout fout. Sprints langer dan één week? Onmogelijk! Release je nog om de 6 maanden? Ben je gek? Reken je nog met uren? Oh, zelfs voor taken? Mag niet, had ik al gezegd dat taken ook verouderd zijn?

Het is zelfs al teveel om te pogen om Scrum ‘puur’ te implementeren, wat dat is te verstorend voor de organisatie, en kom zeg, je gaat toch niet Scrum by the book doen? En hele Sprint lang de inhoud constant houden? Dat kan geen enkelijke organisatie meer volhouden. Veel te lang.

Ooit, in het begin van Agile schreef men Individuals and interactions over processes and tools.Ik denk dat men zat was dat er vele ‘verplichte’ werkzaamheden waren die niet werkten en afhankelijk van de context waren. Soms konden ze best werken en hadden ook hun waarden, maar vaak ook niet.

Tien jaar later zitten we met een Agile community die proces wel degelijk stelt boven personen en hun interacties. Het corset wordt strakker en strakker getrokken.

Behalve verplichte werkwijzen is ook de groei aan tools enorm. Nu hoeft er niets mis te zijn met tools, toch is het tekenend hoeveel er zijn en hoe veel ze gebruikt worden. Zijn er überhaubt nog mensen die Post-Its™ gebruiken voordat ze een tool gaan toepassen?

Scrum is een licht gewicht framework. Er wordt heel veel niet in bepaald. Dat is voor jou om te bepalen hoe je dat doet. Geniet van die vrijheid en bepaal dat lekker zelf. Nét genoeg, niet meer.

Maar is het ook werkelijk het geval? In het boek ‘Waarom we allemaal van Mars komen’ onderzoekt de schrijfster de aangehaalde onderzoeken om vervolgens te concluderen dat de resultaten gefilterd worden om de stelling te bekrachtigen.

Het is naïef om te denken dat dit niet zou gebeuren in ‘onze’ agile community. Ook de boeken die tot de vaste literatuur behoren staven hun uitspraken met referenties. Maar kloppen die referenties wel?

In ‘De Slinger van Foucault’ zijn de hoofdpersonen werkzaam voor een uitgeverij die wat we nu ‘New Age’ boeken noemen. Het boek haalt aan hoe die boeken door naar elkaar te refereren hun eigen waarheid creëren. Klakkeloos citeren ze elkaar. Omdat het hier en daar staat is het dus waar.

Steeds meer boeken over Agile doen dat ook. Waar het originele Scrum boek het vooral moest hebben van externe studies hebben de nieuwere boeken het vooral over reeds bestaande boeken over Agile en refereren ze aan totaal oncontroleerbare bronnen zoals blogs. En hoera, ze zijn het allemaal met elkaar eens en verkrijgen daarmee een status van juistheid.

De uitdaging die blijft is het kritisch lezen van boeken en blogs, hoe fijn het ook mag zijn dat ze je denkbeelden bevestigen. Waar haalt de auteur zijn informatie vandaan en on hoeverre misbruikt hij die om zijn ideeën een waarheid mee te geven?

Dit artikel kan natuurlijk niet compleet zijn zonder dat ik als auteur openheid van zaken geef. In ‘Mannen komen van Mars,Vrouwen van Venus’ heb ik ooit een paar bladzijden gelezen om het vervolgens verveeld aan de kant te gooien. De laatste keer dat ik de ‘Slinger’ heb gelezen is denk ik meer dan 15 jaar geleden. Een ‘Waarom we allemaal van Mars komen’ heb ik helemaal niet gelezen, ik heb slechts een artikel in “Psychologie Magazine” erover gelezen…

Voor hen die dankzij (A)TDD en wat nog meer 100% correcte programma’s opleveren is dit artikelen weinig interessant. Voor hen die toch nog, ondanks al hun moeite en effort geconfronteerd worden met defects biedt dit artikel advies over hoe defects te schedulen. En, als lezer mag je ook stiekem toegeven er nog steeds fouten in de software zitten. Niemand zal het horen….

Defects kunnen zowel binnen als na de sprint gevonden worden. Bij die defects die binnen de sprint gevonden horen is het, als het bij een huidig backlog item hoort, nog gewoon bij het werk wat gedaan moet worden. Het maakt dan niet uit of we eerder dachten dat het item af was, voldeed aan de DoD en de reeds de zegen van de Product Owner heeft gekregen. Op zich is er nog niets aan de hand, als we tenminste nog niet geleverd hebben.

Het eenvoudigst werkt het als de ontwikkelaars ook degenen zijn die die fouten vinden. Vinden mensen buiten het team ze, of zijn het gespecialiseerde testers op een andere locatie, dan onstaat al snel de werkwijze om het in een defect tracking systeem op te slaan, met z’n bijbehorende lifecycle, overhead en deprimerende uitstraling. Liever niet, en een goede reden om aan kwaliteit te werken.

Vind je een fout vlak voor het einde? De Product Owner is uiteindelijk degene die aangeeft of hij wel of niet het backlog item goedkeurt, maar ik zou hopen dat de Scrum master de Product Owner stimuleert, of in ieder geval de optie geeft, om het item af te keuren. Dit is moeilijker dan op het eerste ogenblik lijkt, meestal willen we het toch nog net goed vinden. En dus maken we van de kleine foutjes een release note en een nieuw defect die we ooit nog eens gaan doen. Mocht de Product Owner het item niet afkeuren dan zou het alsnog een goed teken zijn als het team bij de volgende sprint planning minder inhoud accepteerd. Ook daar is als Scrum master een rol weggelegd om bij de sprint planning een spiegel voor te houden.

Maar nu, het product is geleverd en wordt door echte gebruikers in gebruik genomen, of wordt, in complexere omgevingen, door product testers onder handen genomen. En die vinden alsnog fouten. Ondanks alle moeite die we erin gestopt hadden om die fouten te voorkomen. Die defects horen op de product backlog thuis, net zoals al het ander werk dat gedaan moet worden.

Dat laatste wordt als lastig ervaren door teams die met User Stories, Story Points en Velocity werken. De velocity is bedoelt om de capaciteit in te schatten waarin nieuwe, waarde toevoegende, functionaliteit toegevoegd kan worden. En defects gaan dan weer over dingen waar we de punten al verwerkt hebben in onze berekening en ze voegen geen nieuwe functionaliteit toe.

Bij het klakkeloos op de backlog zetten van defects en ze net zo behandelen als andere user stories onstaat een moeilijker in te schatten plaatje, neemt de transparantie af. Het is alsof je afdrijft, de snelheid die je meet is niet de snelheid die je werkelijk hebt. Moet je dan maar voor elk item dat je op de backlog lijst zet alvast een een blokje defect fixing opnemen? Dat is wel de standaard praktijk bij veel plannings processen, maar daarmee red je het ook niet, je keurt als het ware goed dat er fouten in je software zitten.

Als je op een velocity gebaseerde plannings techniek gebruikt wil je dat de velocity die je meet, en dus gebruikt als voorspelling, af neemt. Dat is eenvoudig op te lossen door defects geen story points te geven. Als ze opgelost zijn leveren ze geen bijdrage aan de snelheid op.

Defects kosten natuurlijk wel tijd om op te lossen, maar daar is de sprint planning voor. De Product Owner selecteert de items van de backlog, maar het team geeft aan wat hun capaciteit is. En die wordt voor een sprint uiteindelijk berekend in uren die nodig zijn om de items te realiseren, niet in de punten die bij het item staan.

Voor de Product Owner zal dit helaas niet voldoen. Hij gebruikt die punten dus wel als voorspeller en hij zal toch vaak moeten aangeven wanneer het opgelost is en of het de planning in gevaar gaat brengen. Hij zal dus wel behoefte hebben aan een inschatting met story points, om zo te kunnen zien in welke sprint ze terecht gaan komen. Wel inschatten, maar niet meerekenen…

Maar dan klopt de velocity ook weer niet. We rekenen met een lagere snelheid omdat we weten dat we defects moeten gaan oplossen, maar die staan ook al in de backlog en dus rekenen we ze twee keer…

Niet alle defects zijn echter gelijk. Sommige zijn zeer urgent, vragen om actie op dit moment, andere zijn de kleine schoonheidsfoutjes, de dingetjes die net beter gekund hadden. De meesten zullen dus ook wel werken met een prioriteits systeem, zo heb ik ooit het MoSCoW systeem toegepast zien worden op defects, of krijgen ze een prioriteits indicatie met een getal. Als team en als Product Owner helpt dit niet veel, de hiervoor genoemde problemen blijven bestaan.

Bij elk defect moet uiteindelijk de afweging gemaakt worden “doen we het nu of doen we het straks“, geheel in lijn van Getting Things Done. Deze defects dragen dan niets bij aan de velocity. Bij een overvol sprint programma zal de capaciteit afnemen en kunnen niet alle items gedaan worden. Eigenlijk zou dat als resultaat moeten hebben dat de sprint gestopt wordt, maar ik ben nog geen team tegen gekomen wat dat daadwerkelijk doet.

Mocht je zoveel doe het nu defects hebben dat ze niet in je huidige sprint passen dan schuiven ze door naar de volgende, waardoor de velocity nog meer daalt, theoretisch tot het nul-punt. Een krachtig, maar niet zo leuk, signaal.

De Doe het straks hebben dezelfde status als de andere user stories. Wat dus betekent dat het product ook zijn waarde zou kunnen hebben zonder dat ze opgelost zijn. Ze worden, net zoals andere backlog items, gewoon ingeschat en op de backlog gezet. Mocht je veel meer doe het straks dan doe het nu defects hebben dan zou je, nadat je even tevreden bent over jezelf, de criteria kunnen aanscherpen over wat nu en straks betekend.

Los van hoe je ze inschat, blijf defects zien als afwijkend, iets waar je vanaf wilt. Als je ze gaat accepteren als gegeven dan zal je geen manieren meer gaan zoeken om ze te gaan voorkomen. En de meeste defecten kunnen met een lagere inspanning voorkomen worden dan dat ze opgelost moeten worden.

Eigenlijk is dat belangrijker dan defects correct in te plannen.

Aangezien er geen voor opgestelde presentatie was, het zou een interactieve avond worden was het voor Ken duidelijk even moeilijk om te beginnen. Er kwam niet direct veel input van de aanwezigen – de cursisten hebben natuurlijk de hele dag alle vragen al kunnen stellen. Met het verzoek vanuit het publiek “hoe ‘verkoop’ ik Scrum aan mijn management” kon hij beginnen om zijn verhaal op te hangen.

“Scrum is en was niet wat ik er van dacht”, begon hij, “en het is op plaatsen gekomen waar in nooit verwacht had dat het zou komen”. Hij vertelde dat nadat ze de normale waterval cyclus in stukjes hadden opgehakt ze er achter kwamen dat ze minder documenten nodig hadden, dat ze sneller ontdekten dat ze nog technische zaken moesten doen en dat ze meer behoefte hadden aan contact met de klant. Dingen die tegenwoordig eigenlijk als ‘normaal’ beschouwd worden, maar het klonk alsof het voor hem eigenlijk meer een verrassing was dan een vooruit gestippeld plan, een met visie opgebouwde methode.

Zijn verwachting dat de programmeurs het zouden omarmen en er mee aan de haal zouden gaan, dat de klanten zouden staan te juichen om zo vaak releases te krijgen kwam niet uit, in ieder geval niet zomaar. Gebruiken zitten erg diep en je veranderd niet zomaar 20 jaar. De meeste successen werden dan ook bereikt door bottum-up implementaties waar klanten eigenlijk helemaal niet door hadden wat er aan de hand was.

Zodra hij het aan het management begon te verkopen dan kreeg hij reacties dat hij gek was! Ze gingen vragen of het wel kon, of het wel veilig was en welke waarborgen er allemaal in zouden zitten. Uiteindelijk veranderen de meeste managers of bedrijven pas als ze ingehaald worden door een concurrent en niet meer kunnen negeren dat ze het anders zouden moeten doen.

Als tips had hij ‘ga voor een snelle winst’ en zorg dat je niet per definitie langs de managers moet, maar zoek uit wie de beïnvloeders binnen het bedrijf zijn en beïnvloed hun weer. Ik denk dat menig lobbyist dit zal herkennen als zijn strategie.

Ik vroeg mij af of hij spijt had van de term Scrum Master. Het Master gedeelte van de term suggereert voor velen meesterschap in kunde, niet ceremonie meester. Zeker door de term Certified Scrum Master geeft voer tot veel discussies. Dat mensen hun titel opblazen en anders interpreteren was niet zijn verantwoordelijkheid vond hij. De term was per toeval ontstaan bij een van de eerste keren dat ze aan anderen uitlegden wat Scrum was. Er was nog geen naam voor de rol en iemand vroeg ‘en wat ben ik nou in het team, de ceremonie meester van Scrum, de Scrum Master?‘ .

Waar hij wel spijt van had was de term ‘commitment’. De term werd te vaak misbruikt om het team op te hangen aan hun belofte. En dan is uiteindelijk de kwaliteit van het product de kind van de rekening. De bedoeling was ‘we denken echt dit te kunnen doen, we gaan zeer serieus ons best doen om het te gaan halen, maar als het niet gaat dan gaan we samen overleggen om te kijken wat we wel kunnen doen’. Klinkt natuurlijk niet zo spannend en is te lang om steeds op te noemen.

Beide kanten zijn lastig, de tweede definitie loopt weer het risico om misbruikt te worden door mensen die met na halfslachtige poging zeggen dat ze het echt niet kunnen. Maar de primaire aanname is voor Scrum dat men werkt met volwassenen die het werk wat ze doen zo goed mogelijk willen doen, niet omdat ze slechts brood op de plank willen hebben.

Natuurlijk vroeg ik mij ook af hoe hij tegen Kanban aankeek, om vervolgens te duiken in de domeinen ‘Simpel, Complicated en Complex’. Voor mij zat hier de toevoeging ten opzichte van ‘het boek’ dat processen in Complicated, al heeft het een mindere voorspelbaarheid, geregeld wordt door meetgetallen die aangeven of het proces nog enigszins op schema zit. En als dat niet is het systeem gestopt kan worden, oftewel ‘stop the line’. Dat hij van mening is dat Scrum en Kanban een totaal ander domain verwachten (Scrum complex, Kanban Complicated) zal niet vreemd klinken.

Alhoewel Ken alle tijd nam om rustig de vragen te beantwoorden en zijn verhaal te vertellen denk ik dat hij dolblij was dat hij zijn hotelkamer kon gaan opzoeken om de volgende dag de tweede cursusdag te gaan geven.

The Agile Stammtisch Düsseldorf is a local, Düsseldorf based (suprise, isn’t it?) iniative. Despite that the people present were German, Dutch and Norwegian. So at a single evening we represented a network of European Agile enthousiasts. At that evening we strengthened the nodes between at least three countries (and that doesn’t even include the Country of Cologne…).

To me this is what the ALE could be: meeting people from other countries, building up a network of likeminded people over Europe. Maybe the ALE movement brings us that we should, as Europeans, be aware that we must actively be aware of opportunities to connect to other countries, to look over our bounderies, creating an open mind to do so. How much more ALE than this could this evening have been?

I’m hoping I will return to Düsseldorf once in a while, despite that it is every time at my busy, completely booked, Thursday evening. If so I will at least have done a small part to strengthen the European Network.

De appelbomen in de kwekerij hier vlakbij waarvan hun vruchten gebruikt gaan worden in Echte Limburgse Kruutje (appelstroop) beginnen weer bloesems te krijgen. Maar voordat dit product bij u op tafel staat zullen vele stappen genomen moeten worden en moeilijkheden overwonnen. Het moeilijkste werk wordt door de boom gedaan. Deze zal de vruchten moeten voortbrengen die gebruikt gaan worden.

Uiteindelijk heeft de boom geen keus, het zit in zijn lot ingebakken om appels te maken. Ook in het realiseren van onze wensen doorlopen wij mensen dezelfde stappen als de boom doet voor zijn voortbrengende werk. Scrum is een cyclisch framework dat de Creatiespiraal vanuit zichzelf lijkt te volgen, wat gemaakt lijkt te zijn met de Creatiespiraal in gedachten.

In de lente ontwaakt de boom, maakt zich klaar voor de zomer. De bloesems dragen een belofte in zich, een verbeelding van warme dagen vol zon. Weldra zullen ze appels gaan dragen, zullen ze de kleine vruchten met al hun kracht omzetten tot vruchten. Totdat het tijd is om de appels te laten gaan en uiteindelijk de bladeren te laten vallen in de herfst. Gedurende de winter trekt een boom in zichzelf terug, rust hij uit om in een nieuw jaar weer een nieuwe voortbrengende cyclus te doorgaan.

Dit beeld van vruchtbomen is het beeld van Marinus Koope, uitgedrukt in ‘De Creatiespiraal‘. Het omschrijft hoe dromen en verlangens van mensen tot uiting komen via wens naar werkelijkheid. Hoe ideeën ontstaan in de winter, hoe ze langzaam tevoorschijn komen in de lente, tot wasdom in de zomer en hoe uiteindelijk de herfst het tijd wordt om te genieten van de resultaten.

Deze cyclus herhaalt zich, continu. Elke cyclus bouwt voort op de volgende. Goede, energieke cycli dragen beloften in zich voor de toekomst, slechte, donkere, cycli het verlangen om het af te sluiten en opnieuw te beginnen.

Elke sprint doorloopt de twaalf stappen van de Creatiespiraal. Elke stap verbeeldt een van de activiteiten en de gebeurtenissen die een team ervaart tijdens een sprint, gedurende het project, de uitvoering.

Lente, zomer, herfst en winter zijn terug te vinden in een sprint. Zoals het jaar verdeelt is in twaalf maanden, zo is de Creatiespiraal verdeelt in twaalf stappen. Daar waar de maanden gedreven door de wetten van de natuur, ongeveer even lang duren duren de stappen in Scrum natuurlijk niet even lang. Sommige duren slechts uren, anderen dagen, maar het zijn dezelfde stappen.

Laten we de stappen volgen en ontdekken hoe we ze terug vinden in een sprint.

1. wensen

Het begint bij wensen, bij verlangen, bij willen. Scrum heeft al een prachtige lijst daarvoor, de backlog lijst. De backlog list is niets anders dan een lijst van wensen, van dromen. De backlog list is dus geen lijst van eisen, geen requirements document, maar een levende lijst van verlangens van wat het product zou moeten kunnen. De wensen zijn actueel en aangepast aan waar we nu staan. De wensen rijpen op deze lijst. Er hoeft nog geen rekening gehouden te worden hoe ze gerealiseerd moeten worden, dat komt later wel!

2. verbeelden

De sprint begint, met de sprint planning. De product owner legt uit aan het team welke wensen hij heeft en wat het zou betekenen. Hier ontstaat het sprint doel, de visie, het eindbeeld. De rest van de sprint staat tot doel dit eindbeeld te gaan halen. Bij latere stappen gedurende sprint vallen we terug op de hier geschetste verbeelding om weer te bedenken waarom we eigenlijk doen wat we doen.

3. geloven

Het team snapt wat de product owner wilt, vult de product owner aan, droomt met hem mee. De product owner krijgt vertrouwen in dat wat hij wil kan en begrepen wordt. Het verbeelden wordt geloven, door hem en het team.

4. uiten

Iedereen denkt het te kunnen, de selectie uit de backlog list wordt vastgelegd. Dit gaan we doen, dit gaan we maken! De product owner verlaat de sessie en begint al te vertellen wat er deze keer aan zit te komen. Wellicht is niet iedereen gelijk enthousiast, wellicht hadden anderen liever gehad dat het iets anders was geworden, maar dit is het, dit gaat het worden.

5. onderzoeken

Het team gaat onderzoeken, gaat ontwerpen, gaat bedenken. Hoe moeten we dit maken, welke dingen moeten we doen, wat gaan we veranderen.
De product owner heeft zijn droom kenbaar gemaakt, maar staat natuurlijk het team bij om te helpen verder te onderzoeken en aan te scherpen, te veranderen opdat de verbeelding haalbaar is.

6. plannen

Allles heeft tot nu toe plaats gevonden in de fantasie. Het zijn slechts droombeelden, vergezichten, schetsen op een whiteboard. Het wordt tijd om te kijken hoe deze droom om te zetten naar werkelijkheid. Taken worden gemaakt, ingeschat en sommigen onder ons verdelen zelfs al wie wat zou gaan doen. En, ondanks de weerstand die ‘wij’ massaal lijken hebben gekregen tegen plannen, helpt het wel om daadwerkelijk te zorgen dat het gaat gebeuren.

7. beslissen

De plannen zijn gemaakt, de uren zijn geteld. Kan het wensbeeld inderdaad gemaakt worden, durft het team het aan? Zo ja dan geeft het team zijn commitment af aan de product owner. “Ja, dit kan, we kunnen het en we gaan ons er hard voor maken om het inderdaad te doen”. Door de vorige stappen is het team naar dit moment toegegroeid, het is geen moeilijke stap meer. Sla je de vorige stappen over dan merk je hier de twijfel, de angst, ‘kunnen we het wel?’

8. handelen

Nu wordt het tijd om te gaan doen wat wat we in de vorige stappen gezaaid hebben. Het product wordt verder ontwikkeld, het creatieve proces manifesteert zich, iedereen zet zijn talenten in om het doel te gaan halen.

9. volharden

Er komt een moment dat het tegen valt. Zelfs met alle voorgaande stappen hoeft het niet te gaan zoals gedacht. Het werkt niet zoals bedacht, het duurt langer, het is moeilijker en de deadline lijkt altijd weer sneller te komen dan gewenst. Het  ‘geloven’ van stap 3 lijkt naïef, onzinnig. De voorgaande voorbereidende stappen lijken onzinnig, verspillend en verkwistend. Door terug te grijpen op de verbeelding, op het doel, kan er weer grip gekregen worden, kan er weer een nieuw pad ontdekt worden en is stap 8 weer in zicht.

10. ontvangen

Genieten van het behaalde resultaat is een belangrijke inspirator voor toekomstig werk. De sprint review is het moment om aan iedereen te laten zien wat het werken opgeleverd heeft, om nieuwe ideeën op te doen en te genieten van het succes.

11. waarderen

Gedurende de sprint is er nieuw gebied ontdekt, zijn teamleden gegroeid, maar er zijn ook dingen onbesproken gebleven, er zijn dingen blijven liggen. Het is tijd geworden om te te evalueren wat er gedaan is. Is er gerealiseerd wat er gedroomd is? Kan het de volgende keer anders, beter. De retrospective biedt de mogelijkheid om de volgende keer beter aan te sluiten bij de verbeelding, of de
verbeelding beter te laten aansluiten aan de aanwezige capaciteiten.

12. ontspannen

Tijd om tot rust te komen, om even te ontspannen en te genieten. De tijd tussen de retrospective en de volgende sprint planning waar de volgende cyclus van de spiraal weer opnieuw begint. De tijd om dingetjes uit te zoeken, om even te proberen wat er nog is blijven hangen in je hoofd als experiment. Nieuwe verlangens, nieuwe ideeën ontstaan in dit gebied.