scrummaster.nl

Een belangrijk gegeven in Agile is het verzamelen en reageren op feedback. Hoe meer en hoe eerder hoe liever, en “fail fast”. Maar je kan ook teveel en te vroeg feedback krijgen.

Op het moment dat ik dit schrijf is mijn vrouw onderweg naar de andere kant van het land. Ik kan precies zien waar ze rijdt door middel van de EnRoute applicatie op haar smartphone. Ik zie precies wanneer ze van snelweg wisselt of in een file terecht komt, waarbij ik gelijk maar even de informatie over de file stuur.

Maar het komt ook wel eens voor dat er geen informatie verstuurd wordt. Als dat iets langer duurt dan een paar minuten merk ik dat er toch een ongerustheid ontstaat. Zou er wat gebeurd zijn? Voor de zekerheid bel ik maar even… Gelukkig, een nieuwe update! Gefascineerd blijf ik kijken hoe de reis verder gaat.

Eigenlijk krijg ik teveel informatie. Ik weet hoelang de reis gaat duren en ik hoef helemaal niet van minuut tot minuut te zien hoever deze gevorderd is. Eigenlijk zorgt de hoeveelheid informatie voor meer onrust zodra deze me niet meer brengt wat ik zou willen.

In het pre-agile tijdperk werd er nauwelijks vanuit de feedback gedachte gewerkt. Je maakte een plan en voerde het uit. En als de werkelijkheid niet overeenkwam met het plan dan was de werkelijkheid fout en diende je maar harder te gaan werken zodat het wel weer met elkaar in overeenstemming kwam. Of in ieder geval totdat het verschil dusdanig groot was dat het niet meer te ontkennen noch te repareren was. Met de introductie van Scrum kwam daar verandering in. Hier werd expliciet gesteld dat je een software project beter kan sturen door middel van meten en voorspellen.

Die boodschap is wel aangekomen en deze wordt doorgetrokken tot het extreme. Als feedback en het reageren daarop goed is dan is continue feedback en continue aanpassing nog beter. En dus moeten sprints korter. Vier weken? Veel te lang om een sprint stabiel te houden! Twee weken? Hoe hou je het vol, laat het idee van sprints toch los! Elke negen maanden een release? Dan gaan we failliet! We moeten na elke build vrijgeven, dan verdienen we onze investering tenminste gelijk terug en krijgen we snel feedback uit de markt!

Echter, om de analogie uit mijn vorige artikel door te trekken, een goede zeiler is iemand die niet op alle golven en windvlagen reageert, slechts op de belangrijke. Te snel reageren haalt de snelheid uit de boot en maakt dat het schip zich veel onrustiger gedraagt, wat weer invloed heeft om de opvarenden.

Je kunt wel zodra je een item af hebt gelijk een soort mini review houden, maar het risico dat je hier mee loopt is dat je gaat reageren op alle opmerkingen die dan gemaakt worden. Ik heb tenminste nog nooit meegemaakt dat er iemand was die niet iets wist op te noemen waarvan hij dacht dat het beter was dan hij voor zich zag.

Als persoon moet de ontwikkelaar al sterk in je schoenen staan om daar positief op te blijven reageren (“het is geen kritiek, maar constructieve verbetervoorstellen…). Ook de Product Owner moet wel heel goed kunnen balanceren wat nou nog wel en niet belangrijk is. De verleiding om dan toch nog net wat van de opmerkingen mee te nemen is moeilijk te weerstaan. De meeste mensen zijn nou eenmaal genegen om een ander een plezier te doen en we willen graag horen dat we het goed gedaan hebben.

En dus wordt er langer gesleuteld aan functionaliteit dan nodig. En zo vertraagt het project weer een beetje, bijna onmerkbaar maar opgestapeld genoeg. Net als vroeger, voordat we Agile deden. Behalve dat we het nu niet meer ‘te laat’ noemen, maar ‘we passen de op te leveren inhoud aan’.

Bij feedback uit de markt onstaat het risico voor handelen naar de waan van de dag. Een dergelijke reactieve houding zorgt ervoor dat de originele visie uit het oog verloren wordt, de visie die het bedrijf een voorsprong zou moeten geven op de concurrentie. Die het gat tussen ”hun” en “ons” dusdanig zou moeten maken dat ze het er warm van zouden krijgen. Het blijkt dat die zeer urgente features in praktijk helemaal niet zo urgent waren. Als we even gewacht hadden dan hadden we dat best kunnen inzien en hadden we beter aan belangrijke dingen kunnen werken in plaats van steeds te blijven rennen.

En je gebruikers? Zitten die echt te wachten op elke week weer een andere versie? Voor je gebruikers is je software slechts een hulpmiddel in het leven wat ze hebben. Niets anders dan hun stoel, bureau of bril. De meesten willen best af en toe een betere stoel, een hippere bril. Maar niemand zit te wachten op een monteur die elke dag een beetje aan je stoel komt sleutelen, of aan de opticien die steeds aan de pootjes van je bril zit te morrelen. Ondertussen willen ze doorgaan met wat ze willen of moeten doen, hun werk of hobby. Jouw software moet daar inpassen, het liefst zonder dat ze eigenlijk doorhebben dat ze het überhaubt gebruiken.

Als je nieuwe versie van software krijgt moet het verschil groot genoeg zijn om een klein beetje spanning op te bouwen. Om enthousiast te worden van de leuke dingen die nieuw zijn. Bij te veel, te vaak en te kleine wijzigingen ontstaat irritatie. Weer een update? Van mij hoeft het niet.

Natuurlijk is het niet goed om vast te blijven houden aan verwachtingen en plannen die verouderd zijn en niet meer realistisch, maar schiet niet door naar de andere kant en laat je niet gek maken door alle adviezen die beweren dat nog meer feedback nog sneller moet. Fail fast is geen houdbare strategie.

“Nog een half uur”. Dat was het antwoord van mijn vader als we vroegen hoe lang het nog zou zijn voordat we eindelijk in de haven zouden bereiken. Dat half uur bleek in praktijk geregeld een paar uur te duren. Om een of andere reden gaf mijn vader nooit het juiste antwoord.

Ik als baby aan boord

Hoe simpel is het: met behulp van de passer bepaal je in hoeveel uur je aan kan komen, en met behulp van de plotter bepaal je de koers. Dan ga je op weg en stuur je met behulp van het kompas naar de juiste richting. En dan toch zo’n foute schatting afgeven…

De backlog verleidt tot dezelfde vraag. Hoe lang nog. Dan niet tot de haven, maar tot een bepaald feature gerealiseerd is, of tot ‘alle gevraagde’ functionaliteit opgeleverd is. En graag nauwkeurig want er zijn stakeholders die er afhankelijk van zijn. En tenslotte zijn we toch professioneel bezig, dus weten we wat we doen en wanneer. Natuurlijk accepteren we wat variatie, maar niet te veel graag.

Aan boord wisten we dat er veel kon gebeuren dat de boel in de war zou kunnen sturen. De natuur gaf niet zo veel om onze plannen en deed haar eigen ding. Natuurlijk verschoven terwijl wij op zee waren de tektonische platen en het magnetische noorden. Natuurlijk bewogen zandbanken om ondieptes te vormen die er eerst niet waren. Maar de kaart, onze representatie van het domein, bleef accuraat genoeg voor de tijd die wij nodig hadden om ons doel te halen. Het was de wind, de stroming en de golven die er voor zorgden dat we niet daar heen gingen waar we heen wilden. Als voor zover je oog kan reiken er uit ziet als dezelfde zee met dezelfde golven wordt het moeilijk om te bepalen waar je bent en waar je heen gaat.

Het maken van software heeft dezelfde ‘onzichtbaarheid’ als het gaat om te bepalen waar je precies bent. Ja, je hoopt dat je de prioriteiten goed gedaan hebt, je hoopt dat je hebt gemaakt wat je afnemers nodig hebben, maar zeker weten… dat weet je pas als je enige tijd op de markt bent. En al had je de juiste keuze gemaakt, er zijn alweer veranderingen geweest waardoor je nu waarschijnlijk een andere keuze zou hebben gemaakt.

Tijdens het zeilen bepaalden wij om het uur onze positie. In de periode voordat de GPS voor normale mensen te betalen was ging het  net zoals het al eeuwen gebeurde: een gegist bestek. Met behulp van een sleeplog werd de snelheid vastgesteld en tesamen met de gevaren koers dacht je dan te weten waar je was. Het is trouwens nog steeds verstandig om deze vaardigheden onder de knie te hebben als je gaat zeilen.

Het doel van deze regelmatige controle was niet om te bepalen hoe laat we aan zouden komen, maar om te bepalen wat we moesten aanpassen om veilig aan te komen. Dat betekent niet alleen de koers, maar ook een inschatting wat het weer gaat doen, welk invloed het getij gaat hebben en welke gevaren de zee verbergt zoals zandbanken, venijnige stromingen of drukke scheepsvaartslanen. Ook met GPS is dat nog steeds noodzakelijk.

Noordzee 1977

De sprint van Scrum bestaat voor dezelfde reden. Op de grens van de sprint bepaal je positie door middel van de Sprint Review, al blijft het een gegist bestek. De Product Owner gebruikt deze informatie en alle andere informatie die hij verkregen heeft om te bepalen wat de volgende koers moet zij om het eindresultaat van de release veilig te kunnen stellen. De eerstvolgende Sprint Planning is het moment waarop de vergaarde informatie leidt tot uitvoering van het nieuwe doel. Wat bij ons aan boord gebeurde door wind, stroming en golven gebeurt bij software ontwikkeling door veranderende inzichten, marktomstandigheden en verwachtingen.

In mijn kindertijd ging al die navigatie compleet langs mij heen. Voor mij was de enige vraag die belangrijk was “hoe lang nog”. Hoe lang nog tot ik weer kan gaan spelen, hoe lang nog totdat ik niet meer zeeziek over de reling hoef te hangen. En omdat mijn vader wist dat het echte antwoord complexer was dan ik wilde horen was het antwoord ‘een half uur’.

De ‘hoelang nog?’ vraag vanuit een organisatie is dus zeer begrijpelijk, maar het is de verkeerde vraag. Waar zijn we? Waar moeten we heen? Wat is daar voor nodig? Het delen van de resterende hoeveelheid werk met de snelheid van opleveren geeft een naïef en vertekenend beeld.

Hoe lang nog… een half uur.

De software industrie heeft er een nieuw soort adviseur bij: de Agile Coach. De Agile Coach is niet zoals de andere adviserende beroepsgroep, hij belooft echte verandering voor de organisatie, en geen stapel rapporten. Wilt u echt de verandering naar Agile maken dan kunt u eigenlijk niet zonder Agile coach, zo is de claim.

Maar wanneer is een coach een coach en wanneer niets anders dan een consultant met een mooiere titel?

Tijdens mijn opleiding tot coach – 1:1 coaching – was een regelmatig terugkerend onderwerp wanneer een coach een coach is en wanneer een therapeut, counsellor of consultant. Als coach is het belangrijk om je grenzen te weten, je wilt voorkomen dat je je cliënt schade berokkend.

Een precieze bepaling van de grenzen is lastig te geven, maar laat ik een poging doen om te omschrijven wat je mag verwachten van een coach en om te ontdekken of jouw Agile coach eigenlijk een consultant is.

Wat is dan een coach? Een coach is iemand die iemand anders helpt te ontdekken wat diegene eigenlijk al wist.

Een coach komt dus niet met een oplossing, draagt geen kennis aan en stelt geen behandelplan op.

Een coach is iemand die je helpt bij een project. Niet een project dat een product oplevert, zoals een stuk software, maar een project waar van een ongewenste situatie naar een gewenste situatie. Niet van binnen uit, als onderdeel, maar juist als buitenstaander.

Daar waar de consultant je helpt door zijn specialistische kennis in te brengen, helpt een coach met je project door je relatie met het project samen met je te bestuderen, je patronen en valkuilen in kaart te brengen.

Er zijn grofweg twee verschillende richtingen voor coaching. De ene richting zoekt samen met de cliënt naar de juiste vormgeving van het project, de andere richting onderzoekt de coach samen met de cliënt naar welke belemmeringen de cliënt ervaart bij het uitvoeren van het project. In het eerste geval is er sprake van onvrede en heeft de cliënt geen beeld van de gewenste situatie, in het tweede geval weet de cliënt wat hij zou willen bereiken, maar loopt tegen zijn eigen belemmeringen op.

De coach richt zich op de manier om van een functioneel handelen tot een effectief handelen te komen, maar bepaalt niet wat het handelen zou moeten zijn of waar het naar toe zou moeten leiden.

De coach heeft geen belang in het uiteindelijke resultaat. Geen verandering is ook goed, mits de cliënt daar natuurlijk zelf voor kiest.

Hij zal ook in mindere mate geïnteresseerd zijn in hoe de situatie ontstaan is. De huidige situatie wordt geaccepteerd als fait accomplis en het onderwerp gaat vooral over de toekomst.

Het kan zijn dat de cliënt te veel verwerkte emoties over het verleden heeft. In dit geval doet de coach er goed aan om te erkennen dat het nog geen tijd is om de blik naar de toekomst te richten en zou de cliënt moeten adviseren om eerst naar een counsellor te gaan, of bij ernstig disfunctioneren een therapeut te bezoeken.

Voor bedrijven kan dit ook op gaan. Als de sfeer on het bedrijf door jarenlange mismanagement verziekt is wordt het voor een coach er lastig om zijn werk te verrichten. Een specialist op het gebied van bedrijfsorganisatie zou dan een betere keus zijn.

Weet de client wat hij wil, en hoe hij zijn belemmeringen effectief kan adressering dan wil het nog niet zeggen dat hij de kennis en competenties daarvoor bezit. Dit is het moment om een consultant in te schakelen.

Zit een Agile coach nou dichter tegen een coach of tegen een consultant aan? Een Agile coach wéét al wat zijn cliënt – ongeveer – wilt. De kans dat een coach gaat ontdekken dat het eigenlijke project zou moeten leiden tot een ander kantoorpand is redelijk klein.

De coach zal zich wel richten op de relatie tot het doel ‘Agile zijn’, met als opmerking dat Agile zijn natuurlijk geen doel op zich is.

Hij zal dus het team helpen te ontdekken waar en waarom het niet zo succesvol verloopt zoals het team graag zou willen. Hij zou echter niet het team moeten vertellen waarom, maar er van uit gaan dat het team het, ergens verborgen, zelf weet en wellicht beter dan de coach.

Toch ontkomt de coach ook niet aan een portie consultancy. Hij wordt geacht om het team ook te helpen met het op doen van concrete kennis. Test Driven Development? Een coach die het team daar niet mee kan helpen staat snel weer buiten.

Het management heeft een concrete verwachting over het resultaat en verwacht dat er sprake zal zijn van kennis overdracht. De Agile Coach zal, als hij nog meer opdrachten zal willen, daar toch aan moeten voldoen.

Dus is de term Agile Coach dan toch gewoon een andere benaming voor consultant?

Als ik mijn oor te luisteren leg bij anderen dan zitten veel obstakels in de relatie tot het project en het ontdekken van effectieve strategieën om daar mee om te gaan. Coach dus.

Luister en lees ik naar wat voor antwoorden gegeven worden dan zijn dat over het algemeen adviezen, vast staande oplossingen. Consultant dus.

Of zouden we eigenlijk toch vaker een counsellor moeten inschakelen?

Met grote verwachting nam ik jaren geleden deel aan mijn Certified ScrumMaster cursus. Ik wist al veel van Scrum, ik deed het tenslotte al een tijdje – zo goed en zo kwaad als ik kon. Mijn hoop was dat ik net dát extra beetje zou opdoen wat het verschil zou maken tussen een goedbedoelende amateur en iemand met kennis van zaken.

Die twee dagen die de CSM duurde waren twee dagen die ik met veel plezier doorgebracht heb. Ik vond het heerlijk om met andere mensen over Scrum te praten en er mee bezig te zijn. Toch heb ik niet het gevoel gehad dat ik, als ik niet al had begrepen hoe het werkte het daar wel zou hebben geleerd.

Ik zal eerlijk toegeven dat ik mij van te voren een klein beetje zorgen maakte over het halen van het certificaat. Deze zorgen bleken helemaal niet nodig te zijn. Het certificaat kreeg je zolang de trainer van mening was dat je goed genoeg mee had gedaan, of eigenlijk niet van mening was dat je niet had meegedaan.

Helaas betekent dit dus ook dat de waarde van de certificering ter discussie staat – of wellicht niet eens meer ter discussie staat. En helaas moet ik toegeven dat het regelmatig terecht is. Veel mensen die CSM zijn geven bar weinig blijk van het begrijpen van Scrum, iets dat je van een CSM wel zou mogen verwachten.

CSM heeft dus de status van ‘geldklopperij’ gekregen en een Scrum Trainer van het eerste uur gaf aan geen trainingen meer te geven omdat in zijn optiek de markt overspoelt was door tweederangs trainers. Zelfs de bedenkers van Scrum zeggen dat 75% van de bedrijven uiteindelijk niet uit Scrum haalt wat er uit te halen valt.

Na het vertrek van Ken Schwaber bij de ScrumAlliance heeft hij een nieuwe training in het leven geroepen. Tegelijkertijd heeft hij iedereen de kans gegeven om zijn assesment uit te voeren, of je nou zijn training gevolgd hebt of niet.

Hij komt tot de conclusie dat het niet uitmaakt of je nou wel of geen CSM bent. Beide groepen weten even veel van Scrum af. Natuurlijk komen de mensen die Kens cursus gevolgd hebben er stukken beter vanaf… De vragen reflecteren ook meer Kens huidige definitie van Scrum, met een aantal subtiele veranderingen ten opzichte van vroeger, dat mag dus geen verrassing zijn.

Uitendelijk heeft een goede ScrumMaster het ‘dienstbaar leiderschap’ in zijn bloed, ongeacht of het nou wel of geen certificaat heeft. Iemand die diep in zijn hart vind dat een leider nou eenmaal de aangewezen persoon is om de groep te leiden zal moeite hebben om een goede ScrumMaster te worden. Ook hier geldt dus weer Individuals and interactions over processes and tools. Waarbij de tool het certificaat is.

Al deze discussies over CSM doen mij laten twijfelen of ik het Certified Scrum Practicioner Professional zal willen halen. Is het slechts een mooie toevoeging voor mijn CV? Toont het aan dat mijn kennis en kunde op een voldoende niveau is?

Mijn werkgever zal weinig baat hebben bij het halen van het CSP. We zijn geen detacheerder die het moet hebben van gecertificeerde medewerkers om hogere tarieven uit de markt te kunnen halen. Het zal dus van mijzelf moeten komen.

Wellicht is het halen van een CSP zelfs een negatieve indicator, iemand die zich verschuilt achter het certificatie circus. Zo heeft voor mij het Certified Java Developer certificaat in waarde ingeboet door een ervaring met een ontwikkelaar die continu schermde met zijn hoge scores en het hebben van altijd de meest recente SCJD certificaat terwijl hij continu code opleverde op een niveau waarvan wij niet heel gelukkig werden.

Twijfel ik aan mijn kennis en kunde? Heeft mijn werkgever wat aan een CSP certificaat? Is de kans groot dat een volgende werkgever het belangrijk vindt? Allemaal vragen die ik met ‘nee’ beantwoord. En toch…

Wel doen of niet doen? Dat blijft mijn vraag.

Twee dagen lang werd in het Beijerse Rückersbach een AgileCoachCamp gehouden voor iedereen die zich bezig houdt met het coachen, trainen of begeleiden van Agile organisaties of teams. Vlak voordat het evenement plaats zou vinden werd bekend dat er doordat een deelnemer zich afgemeld had nog een plaats beschikbaar was. Het leek mij leuk om buiten Nederland agilisto’s te ontmoeten en dus besloot ik de kans te pakken en schreef mij in.

Om een of andere reden zijn de Duitse Autobahn en ik geen goede vrienden en dus mocht ik al vrij snel aansluiten in de Stau, om vervolgens in een andere Stau te geraken. Moet je ook maar niet door het Ruhrgebied rijden.

Het resultaat was echter wel dat bij de openingssessie ik te weinig energie had om ook een Lightning Talk te doen, een spontane, maximaal drie minuten durende, Powerpointloze presentatie voor iedereen die wat wilde delen, zijn verwachtingen wilde kenbaar maken of gewoon zijn aanwezigheid kenbaar wilde maken. Een activiteit waar massaal gehoor aan gegeven werd, maar die ik als toeschouwer over mij heen heb laten komen.

De zaterdag was het tijd om de onderwerpen van de OpenSpace te gaan vullen. Een groot deel van de aanwezigen kondingde één of meerdere onderwerpen aan en de agenda werd zo aardig gevuld met interessante onderwerpen.

Eén van de eerste sessies die ik koos ging over het motiveren van een team dat uit interne medewerkers bestaat. De organisator had moeite om zijn team te motiveren om het commitment ook daadwerkelijk als commitment te beschouwen en niemand leek het veel te doen als het niet werd gehaald. Hij was van mening dat het verschil met externe medewerkers was dat deze meer hun best zouden doen omdat ze anders hun geld niet zouden krijgen.

Joseph Pelrine organiseert een sessie met de provocatieve titel “A team doesn’t organise itself” waarin hij beargumenteerde dat het team een onderdeel van het systeem ‘organisatie’ is en eigenlijk het systeem zichzelf organiseert. Een interessante sessie over Cynefin, zelf-organisatie en de technieken om zelf-organisatie te stimuleren.

Twee sessies gingen over ‘dromen’: hoe zou je ideale agile organisatie eruit zien en hoe zou de ideale product owner eruit moeten zien. Dromen leiden tot een hoog Hippie gehalte, maar daar zijn dromen voor. Het bedenken van de ideale product owner is een moeilijkere discussie, er is meer verschil tussen meningen van wat een product owner nou wel of niet zich moet bemoeien met de technische implementatie. Het is afhankelijk van de (slechte) ervaringen van de mensen wat hun mening omtrent dit onderwerp is.

“Why do so many misunderstand velocity?” was goed voor een paar interessante discussies en vragen. Het blijft blijkbaar moeilijk om het verschil in eenheden tussen inschattingen op de product-backlog (gummybears) en inschattingen in eenheden op de sprint-backlog (bananas) te begrijpen. Het mengen van deze twee, of teveel relatie proberen aan te brengen, helpt niet en maakt het nog onduidelijker.

Bij de sessie “Scaling Scrum” waren een aantal mensen van grote bedrijven aanwezig. Het is opvallend dat veel tot een structuur komen die op elkaar lijkt en die verder gaat dan slechts een Scrum of Scrums. Een SoS wordt als onvoldoende ervaren. Ongeacht hoe je het inricht, het wordt moeilijker.

Zondagmiddag werd het geheel afgesloten met een retrospective over de afgelopen dagen. De deelnemers konden hun ervaringen kwijt over de diverse gebieden zoals het conferentie centrum, de inrichting en de planning. Voor mij tijd om weer richting Autobahn te vertrekken naar Nederland.

Ik vond het een geweldig evenement en hoop dat er weer een georganiseerd zal worden, bereikbaar voor meerdere nationaliteiten. Wellicht dan bij ons?

Managers staan vaak voor de uitdaging om er voor te zorgen dat de opdracht zo goed mogelijk wordt uitgevoerd. Zo goed mogelijk als in efficiënt, kwalitatief, met een tevreden klant en medewerker.

Vaak wordt één van de volgende leiderschapsstijlen toegepast:

• Vanuit controle: Een directieve vorm waarbij veel aandacht wordt geschonken aan welke taken worden verricht, hoe ze verricht moeten worden en wat een acceptabele tijdsduur is
• Vanuit vertrouwen: Hierbij wordt de uitvoerende zijn gang gelaten, er van uitgaande dat de vrijheid en creativiteit het beste resultaat opleveren.

De eerste stijl zorgt bij de medewerker frustraties dat deze voelt zich niet erkend in zijn vakmanschap, en voelt zich gecontroleerd en onvrij. De manager is veel tijd kwijt om de voortgang van de medewerker te controleren, taken bij te stellen en te discussiëren of de taken wel de juiste zijn. Bij het verkeerde resultaat verschanst de medewerker zich achter het feit dat hij de taken correct heeft uitgevoerd en dat hij zijn werk dus goed uitgevoerd heeft.

De tweede stijl is voor veel medewerkers veel prettiger, maar voor managers onzekerder met betrekking tot het resultaat. Hij had zich een andere voorstelling gemaakt en het gevolg is dat het nog nodig is om naderhand bijstellingen te maken. De medewerker krijgt het gevoel dat ondanks zijn goede en gedreven inzet het resultaat niet gewaardeerd wordt.

Het boek Leiding geven zonder bevelen beschrijft een stijl die output management genoemd wordt. Bij output management wordt het resultaat voorop gesteld, niet hoe het bereikt dient te worden. De output verwijst naar het doel, de input naar het middel om het doel te bereiken.

Het klikt gemakkelijker dan het is, het doel vooropstellen. Zo is een resultaatverantwoording of een target nog geen output. Voorbeeld is dat het aantal boetes dat een korps moet uitschrijven lijkt op het eerste gezicht een output, maar is het niet. Zelfs de verlaging van bijvoorbeeld de snelheidsvermindering, die het uitschrijven van boetes zou moeten bewerkstelligen is input. De uiteindelijke reden is het terugdringen van ongelukken. Over het aantal boetes en de hoeveelheid snelheidsverminderingsovertredingen valt te discussiëren, het terugbrengen van ongevallen geringer. Een discussie over het doel is natuurlijk mogelijk, maar zal ingrijpender voor beide partijen zijn.

De uitvoering van een project zoals ik ooit heb opgestoken tijdens het stenen tijdperk op mijn opleiding ging sterk vanuit de input uit. Om een project te kunnen beginnen had je requirements nodig, het liefst als het IEEE goedgekeurde Software Requirements Specifiction opgesteld. Daaruit volgen alle activiteiten die het project moet uitvoeren, de basis voor de planning van het project.

Agile breekt met deze traditie en Scrum blijkt bijzonder goed bij output management te passen. Op verschillende niveaus wordt output management toegepast, en je zou zelfs kunnen zeggen dat het verwacht dat het bedrijf werkt volgens output management.

De eerste plaats waar het duidelijk wordt dat output management een natuurlijke match is komt al boven bij hoe een release gemanaged wordt. In plaats van de eerder genoemde Software Requirements Specification is er sprake van een Release Goal. De Product Owner is vrij om dit doel te behalen, zonder dat hem van te voren wordt opgelegd hoe dat precies gehaald dient te worden. Het doel dient als referentie, de Product Owner kan niet zomaar van het doel afwijken omdat hij toevallig aan iets leukers dacht.

De tweede plaats is de backlog lijst. De orginele literatuur beschrijft de backlog als de plaats waar alle werkzaamheden van het team vermeld staan en heeft geen voorkeur voor de vorm. Binnen onze organisatie zie ik dan ook vaak dat de backlog lijst opgesteld is als input, met een behoorlijk gedetailleerd niveau over het resultaat.

Veel mensen zijn echter met de backlog lijst al, onbewust, omgeschakeld naar output management. Hun backlog items zijn beschreven als User Stories, waar de business waarde centraal staan. User Stories worden vaak beschreven als simpele één-regelige statements in de vorm “As a <user> I want <functionality> so that <goal>“, en nog de nog sterkere variant “In order to <goal>, as a <user> I want <functionality>” benadrukt de onderliggende waarde en laat veel vrijheid in de uiteindelijke uitvoeringsvorm en is dus een prima vorm van outputmanagement.

Het team krijgt geen vorm opgelegd welke taken het moet uitvoeren om het doel te halen, het is vrij om de taken zo op te stellen en onder te verdelen als nodig en is vrij om het aan te passen mocht dat nodig zijn. Het is zelfs vrij om, in samenspraak met de business, de eindoplossing aan te passen, zolang het doel er nog mee gehaald kan worden.

Output management heeft zeker niet in het gedachtegoed van de opstellers van Scrum gezeten toen ze het aan het samenstellen waren, maar het past naadloos in een omgeving waar het toegepast wordt. Wellicht is het juist een van de organisatorische hindernissen die het ondervindt bij organisaties die sterk gericht zijn op inputmanagement.

Altijd gedacht dat Scrum en XP – eigenlijk Agile in het algemeen – een sterke nadruk legt op kwaliteit. Zo sterk zelfs dat het team geacht wordt om elke sprint een werkend product op te leveren, die “in potentie” daadwerkelijk vrijgegeven zou kunnen worden.

Blijkbaar heeft niet iedereen die ervaring. Sterker nog, is de ervaring dusdanig dat er door de NLJug een hele “University” sessie over software craftmanship aan gewijd wordt:

In de afgelopen jaren is de nadruk binnen software development enorm komen te liggen op Agile werken. Hoewel dit absoluut een enorme verbetering is ten opzichte van traditionele project methodieken heeft het ook een minder welkom neveneffect.

Doordat Agile methodieken zoals Scrum heel erg sturen op functionaliteit wordt de kwaliteit van de software op een tweede plek gezet! Dit heeft als gevolg dat de applicatie snel kan worden opgeleverd met een grote hoeveelheid aan functionele wensen van de klant, maar dat de onderhoudbaarheid en beheerbaarheid van de applicatie minder is!

De voor mij opvallendste zin is “Doordat Agile methodieken zoals Scrum heel erg sturen op functionaliteit wordt de kwaliteit van de software op een tweede plek gezet!”

Scrum heeft opzettelijk geen regels over hoe het werk uitgevoerd moet worden, geeft weinig meer richtlijnen dan het product goed genoeg moet zijn om vrij te geven en dat het liever algemene rollen ziet dan specifieke rollen, wat zich te vertalen valt in dat alle team leden verantwoordelijk zijn voor kwaliteit en dat de taken behorende bij de tranditionele rol “tester” door iedereen uitgevoerd moet worden.

Scrum teams hanteren over het algemeen een Definition of Done, een lijst -checklist- van zaken waaraan voldaan moet worden om te kunnen zeggen dat het werk klaar is. Items die niet voldoen aan de DoD worden niet opgeleverd aan het einde van de Sprint, of tellen in het minste geval niet mee met het behaalde resultaat.

In alle DoDs ben ik tot nu toe tegen gekomen staat in ieder geval iets in over dat de ontwikkelaar een poging gedaan moet hebben om de kwaliteit te waarborgen. Oftewel door het handmatig getest te hebben of door voldoende unit tests.

Extreme Programming heeft juist wel regels over de uitvoering van het werk, het is gebaseerd op een aantal principes die elkaar versterken en ondersteunen. Veel mensen die aan Extreme Programming zijn de mening toegedaan dat Scrum zonder de XP regels kan werken. Scrum kan echter ook toegepast worden buiten software ontwikkeling, zoals bijvoorbeeld er in onze organisatie voorzichtig geëxpirimenteerd wordt met het gebruik van Scrum bij het ontwikkelen van trainingen ten bate van onze producten.

De eisen die XP stelt aan het proces die bijdragen aan de kwaliteit zijn:

• Schrijf eerst de unit test
• Alle productie code wordt ontwikkeld met pair programming
• Alle code heeft een unit test
• Alle testen moeten slagen voordat de code in productie kan
• Voor een defect moet een unit test geschreven worden
• Acceptance testen moeten regelmatig worden uitgevoerd en de score gepubliceerd.

Zelfs met zoveel aandacht die Scrum en XP teams over het algemeen hebben voor kwaliteit komt het helaas nog steeds voor dat er fouten in de software sluipen. Een effectief team zal in de retrospective regelmatig proberen te achterhalen hoe dat komt en wat daar aan te doen is.

Dat de kwaliteit van de software op een tweede plaats gezet wordt is in mijn ervaring juist veel meer een eigenschap van traditionele software ontwikkel methoden. Daar worden Functionaliteit, Kosten en Tijd vastgezet, waardoor automatisch, en ongewild, Kwaliteit de variable is. En daarna blijken Kosten en Tijd en ook nog Functionaliteit niet haalbaar. Agile zet juist Kwaliteit ‘vast’, tezamen met Kosten en Tijd. Functionaliteit is daardoor automatisch de variable en die wordt actief en transparant voor iedereen gemanaged.

De aandacht voor kwaliteit komt niet vanzelf. Deed je als bedrijf voordat je met Scrum begon onvoldoende aan kwaliteit dan komt het niet magisch goed als je met Scrum gaat beginnen. Je zal als team en bedrijf daar hard aan moeten werken, maar Scrum maakt dat wel mogenlijk en inzichtelijk.

Ben je overigens geïnteresseerd in de aspecten van software craftmanship dan is het een idee om actief bij te dragen aan het Agile Skills Project, een project door en voor ontwikkelaars waar een algemene set van kunde wordt vastgesteld die een een software ontwikkelaar in agile projecten zou moeten beheersen.

Toen ik de Certified ScrumMaster training volgde ontmoette ik een ScrumMaster die vertelde dat de andere projectleiders van zijn bedrijf het niet prettig vonden als mensen bij hem in het team hadden gezeten. Ze hadden dan met Scrum gewerkt, waren erdoor zeer enthousiast geraakt en wilden eigenlijk niet meer terug naar de oude situatie. Zou het werkelijk zo zijn? Zouden mensen werkelijk het verschil zo ervaren?

Ik vroeg mij af of het ook andersom zou kunnen gebeuren. Iemand die een tijd met Scrum gewerkt had en er blij was er weer vanaf te zijn. Zo ging ik op zoek en kwam iemand tegen waarvan ik wist dat hij in een team zat waar eerst met Scrum gewerkt werd, maar momenteel niet meer. Ik wist dat hij behoorlijk critisch tegenover Scrum stond. Dat Agile gedoe zou best aardig kunnen zijn, maar eigenlijk geen vervanging van gedegen software engineering.

De titel van dit artikel had ik dan eigenlijk al klaar voordat ik het gesprek in ging. Het zou “Gelukkig, geen Scrum meer” gaan heten. Mijn gesprekspartner zou mij haarfijn kunnen gaan uitleggen wat er eigenlijk allemaal mis was met Scrum en dat er nu eindelijk wel fatsoenlijk gewerkt werd. We ontmoetten elkaar in een restaurant dat voor ons beiden makkelijk bereikbaar was en tijdens de maaltijd bespraken we zijn ervaringen. Tot mijn verbazing verliep het gesprek anders dan ik verwacht had.

“Wat ik mis van de Sprint I planning is de inspraak, maar verder mis ik de Sprint I planning niet eens zo. Het is voornamelijk de Sprint II planning die heel veel toevoegde om samen als team te bepalen hoe wij tot de oplossingen gingen komen. De Sprint I liep eigenlijk altijd al moeizaam, ook omdat de Product Owner rol niet goed ingevuld was. Dat is gelukkig nu wel beter.

Nu hebben we eigenlijk alleen een iteratie-start meeting. Ik noem het expres geen sprint-planning, de team-leider verdeelt alle taken aan de team-leden. We houden nog wel een iteratie-backlog bij, maar alle taken zijn omschreven als “doe het”. De burndown grafiek gaat eigenlijk nergens over, we eindigen bijna nooit op nul. Dagelijks worden er nieuwe taken en items bedacht. Had ik vooraf al geen inspraak gehad, veranderd het óók nog gedurende de rit. Ik voel daardoor geen eigenaarschap, het is niet mijn contract, niet mijn commitment. Het is makkelijker om steeds te zien wat het volgende is waar je aan gaat werken zodra je iets af hebt. Al kwamen we de laatste keer overigens aardig in de buurt.

We werken nu meer in silo’s. Omdat we geen Sprint Planning 2 meer hebben weten we veel minder van elkaar wat we doen en hoe de ander het doet. Het hebben van een eigen stuk is wel prettig, al heb ik niet meer de vrijwillige keuze er in. Nu ik er zo over nadenk hadden we eigenlijk ook een eigen stuk toen het nog anders deden, ook al probeerde de ScrumMaster ons op andere gedachten te brengen. We gebruiken nu reviews om elkaars code te controleren en kennis te krijgen van andere stukken.

Het directieve heeft ook wel zijn voordelen. Ik hou er niet van om directief aangestuurd te worden, maar in de crisis situatie van een tijdje geleden snap ik het dat een ander gewoon instructies geeft zonder dat er discussies over ontstaan.

We doen nog steeds een daily-standup. Vond ik het vroeger al niet bepaald behulpzaam, tegenwoordig hoeft het niet van mij. Ik vond altijd al dat mensen niet moesten wachten met het melden van een probleem tot de volgende dag, maar de irritatie-factor was zo laag dat ik er geen punt van heb gemaakt. Tegenwoordig sta ik te wachten tot ik aan de beurt ben. De tijd dat anderen aan het praten kan ik mooi gebruiken om te bedenken wat ik ga zeggen.

We zijn de retrospective wel bijven doen, maar ik weet eigenlijk niet meer wat er de laatste paar retrospectives als resultaat uitgekomen is. Volgens mij hebben we er ook niets mee gedaan. We hebben een keer een akkefietje gehad gedurende een retrospective, waarbij een groeplid nogal scherpe kritiek te verdragen kreeg. Nu is de veiligheid weg en is het een kwestie van de meeting doorkomen.

Al is het lastig om te vergelijken – de werkzaamheden in dit stadium zijn heel anders – heb ik niet het gevoel dat we erg productief bezig zijn.”

Het klinkt eenvoudig een “zelf-organiserend team”, de praktijk is weerbarstiger. Het is lastig om een zelf-organiserend team te creëren en nog lastiger om het in stand te houden. Als je denkt er te zijn door alleen tegen het team te zeggen “en nu organiseren jullie jezelf” maar vervolgens nog alle oude aansturings- en verantwoordingspraktijken in stand houdt dan zal de hoeveelheid zelf-organisatie bitter tegenvallen.

Men zal voelen dat ze afgerekend kunnen gaan worden op zaken die niet zo lopen als gewenst, zonder dat daar tegen over daadwerkelijke invloed tegenover staat. De zelf-organisatie zal voornamelijk bestaan uit individuen die voor zichzelf organiseren dat het niet aan hun ligt dat het niet lukt.

In Scrum wordt het team geacht om zelf-organiserend te zijn, zoals de Scrum Guide meerdere malen benadrukt:

Scrum Teams are designed to optimize flexibility and productivity; to this end, they are self-organizing, they are cross-functional, and they work in iterations. [...]

However, the ScrumMaster does not manage the Scrum Team; the Scrum Team is self-organizing. [...]

Teams are also self-organizing. No one – not even the ScrumMaster — tells the Team how to turn Product Backlog into increments of shippable functionality.

De cultuur verandering van aangestuurde teams naar zelf-organiserende teams is misschien een van de lastigste veranderingen die een organisatie moet doorstaan willen zij de voordelen van Scrum ten volle kunnen gebruiken.

Bij een van mijn eerste opdrachten als jonge, net afgestudeerde, software ontwikkelaar kreeg ik van de projectleider nog precies te horen in welke volgorde ik mijn werkzaamheden moest uitvoeren en hoelang ik geacht werd om daar maximaal over te doen – met bijbehorende spreadsheet. Tegenwoordig kom je gelukkig vaak wel al een vorm van autonomie tegen., de meeste mensen zelf kunnen bepalen hoe ze hun werk indelen.

Het ‘wat’ en ‘hoeveel’ wordt wel bepaald door de team leider. Hij bepaalt op individueel niveau wat er door wie bereikt moet worden, de uitvoerder bepaalt hoe hij het doet. De team leider bewaakt de voortgang van de diverse team leden en zal ergens gedurende de uitvoering bijsturen door bijvoorbeeld een nieuwe verdeling van de werkzaamheden aan te brengen.

Een groep van autonome mensen staat echter niet gelijk aan een team, niet zonder een stukje autonomie op te geven. Sterk autonome mensen werken juist het team tegen. Zij bepalen zelf hoe zij hun werk willen doen en willen geen rekening houden met de groepsdynamiek. Ze willen niet lastig gevallen worden of willen afwijken van het team-doel.

Omdat iedereen in zal claimen ‘goed bezig te zijn’, en het ook oprecht meent, zal het lijken alsof hier een gesmeerd team aan het werk is. Verborgen blijft een stuk inefficiëntie door miscommunicatie en locale optimalisatie. Zelf-organisatie gaat verder. Zelf-organisatie kan een team in staat stellen om een sterk verhoogde effectiviteit te behalen.

Voor effectieve zelf-organisatie heb je om te beginnen een bepaalde groepsgrootte nodig. De Scrum Guide adviseert ongeveer zeven, maar in mijn ervaring is ook een groep van slechts vier personen in staat om in de juiste sfeer te komen:

The optimal size for a Team is seven people, plus or minus two. When there are fewer than five Team members, there is less interaction and as a result less productivity gain. What’s more, the Team may encounter skill constraints during parts of the Sprint and be unable to deliver a releasable piece of the product. If there are more than nine members, there is simply too much coordination required.

Om als groep tot zelf-organisatie te komen moet je als team lid bereid zijn om een stuk autonomie over te dragen aan de groep. Je wordt geacht bij te dragen aan het succes van de groep, niet aan je eigen glorie. Zelf over de finish komen terwijl er nog anderen bezig zijn het parcours af te leggen is geen succes.

Je moet kunnen overleggen met de rest van de groep en je bij de beslissing van de groep – en het dan niet toch stiekem toch doen. De groep moet ook bereid zijn elkaar ter verantwoording te roepen indien afspraken geschonden worden, individuen moeten bereid zijn om niet vast te houden aan hun rollen en veilige havens.

De groep moet ook aangeven wat zij inschatten wat de capaciteit van de groep is, wat kan de groep aan. In Scrum is het dan ook zo geregeld dat het team aangeeft hoeveel van de backlog zij willen accepteren in de sprint. Teams waarbij een autoriteit aangeeft hoeveel gedaan moet worden worden gelijk ondermijnd in hun zelf-organisatie.

Het zelf oppakken ten opzichte van opgelegd worden zorgt ervoor dat de werkdruk in overeenstemming is met de verwerkingskracht van de groep. Het uitvoeren als groep – met z’n allen over de finish – zorgt ervoor dat individuele verschillen geen belemmering zijn en niet gemanaged of gemonitord hoeven worden. De verschillen tussen de mensen wordt eerder een verrijking door de verschillende invalshoeken en capaciteiten.

De stap van een verzameling individuen naar een team is niet voor iedereen een aantrekkelijke stap. Je moet een stuk van je eigen autonomie opgeven en goed luisteren en reageren op de anderen. Het is lastiger om jezelf te verschuilen achter de anderen of je eigen brilliante ideeën niet zomaar uitvoeren.

Scrum leidt dan ook vaak tot vragen ‘hoe moet het bedrijf zijn mensen beoordelen als het om de team inspanning gaat’. In praktijk is dat eenvoudiger dan het lijkt. Zelfs in een goed werkend team zijn er verschillen in mensen, verschillen in kwaliteiten. Een goed bedrijf ziet deze verschillen en weet ze te waarderen.

Een stap verder dan zelf-organiserend is zelf-sturend. Hier bepaald het team niet alleen hoe zij de werkzaamheden uitvoeren, maar bepalen zij ook welke resultaten bereikt moeten worden. In Scrum termen: het Team is ook Product Owner. Dit is een situatie die aangetroffen kan worden in kleine startups waar het nog onbekend is wat het product moet gaan doen of in bedrijven waar er geen duidelijke Product Owner aanwezig is.

Gek genoeg is de productiviteitswinst bij dergelijke teams veel lager dan bij teams waarbij het team zelf niet bepaald wat er gedaan moet worden. Blijkbaar leidt de combinatie van ‘wat en hoe’ voor veel te veel discussie en verstoringen om effectief te kunnen zijn.