Over Agile principles en practices

Agile werken is fiundamenteel anders dan planmatig werken. Het enige overeenkomst is dat het wordt uitgevoerd door mensen. En daarin zit ook weer een risico besloten. Vandaag nog werd mij gevraagd: "Is het erg als ik niet alles van Agile en Scrum doe, maar wel stand-up meetings en een planbord ga gebruiken?"

Komische vraag. Maar toch vond ik het lastig om deze direct af te serveren.

Het doet me terugdenken aan implementaties van bijvoorbeeld PRINCE2 en RUP. Daarbij was een ieder ook erg snel geneigd tot 'cherry picking': dat wat makkelijk is te implementeren en het snel tot zichtbare verbeteringen lijkt te leiden, dat wordt ingevoerd. Lastigere zaken laten we liggen. Niets menselijks is ons vreemd.

Lopen we nu met het adopteren van Agile, en het invoeren van practices zoals Scrum, hetzelfde risico?

Ik ben benieuwd naar jouw reactie. Laat hem hier achter, of op deze LinkedIn poll.

Een stoel als User Story

Binnen Scrum is een User Story het ankerpunt voor alles. De Product Owner stelt deze op en, als het Scrum team vindt dat het voldoet aan de Definition of Ready, dan kan het de Sprint Planning Meeting in.

Hoe maak je nu een willekeurige User Story tot een Ready User Story? Laten we daarvoor eens een analogie maken met een niet-ICT product: een stoel. Nu is een stoel een tastbaar product en geen User Story, dus dit is het eerste dat ook een echte Product Owner moet besteffen: hij/zij moet geen producten willen, maar oplossingen! En dan ook nog verwoord in een verhaalvorm. Laten we dat eens proberen...

• <Als Product Owner wil ik kunnen zitten zodat ik niet moe wordt als ik eet.>

Dat is al duidelijk zat, nu alleen nog even de 'How to demo' en we kunnen aan de slag.

• <Ik ga vijf minuten zitten en zal niet moe worden.>

Ook dat lijkt al duidelijk genoeg: hup, de Sprint Planning Meeting er mee in!

Zal dit goed gaan? Als oud-watervaller bekruipen mij de kriebels al. Toch kan dit goed gaan, maar de Kritische Succes Factoren worden nu wel mooi duidelijk:

1. In de Sprint Planning Meeting, en in de Sprint, moet de Product Owner echt aanwezig zijn en vragen van de Scrum teamleden adequaat beantwoorden.
2. De Scrum teamleden moeten goede vragen weten te stellen.

Vervolgvraag: Wat zijn goede vragen?

Dat zijn niet de vragen naar de functionals, maar naar de kwaliteitsattributen! Kai Gilb (zoon van Tom Gilb) noemt dat' Stakeholder Values and Product Qualities'.

Achterhalen van alle kwaliteitsattributen is iets wat voorheen een kwaliteitsmanager, requirements engineer en/of een testmanager deed. Die taken komen nu bij de Product Owner en in het Scrum team te liggen. En hier ligt een groot winstpunt te halen om een Scrum team echt naar 'Hyper Productiviteit' te brengen. Anders hebben we 4 sprints nodig om, via zitzakken, bierkratjes en tronen te komen tot een acceptabele eetkamerstoel: zelfde functionaliteit, andere 'Qualities'.

Hoe je de hele wedstrijd wint

In mijn vorige blog, van berg tot siergrind, heb ik al aangegeven dat niet alles Scrummend is op te lossen. Gelukkig wordt mijn mening bijgestaan uit onverwachte hoek: de rugby-spelregels!

Daarin staat dat het doel van dit spel is om ‘te proberen een ovale bal over de tryline van de tegenstander te drukken of tussen de palen te schoppen om zo punten te scoren’. Daarbinnen is een Scrum ‘een spelhervatting na kleine overtredingen of als de bal onspeelbaar is geworden, bijvoorbeeld wanneer een speler de bal laat vallen’.

Terug naar onze projectenpraktijk. Ook daarin zien we dat we niet alles met Scrum kunnen oplossen. Het spelletje heeft ook nog wat activiteiten voor en na de sprints!

Vaak zie ik dat na een aantal (ontwikkel-)sprints, er nog een ander traject gaat lopen. In dat traject worden dingen gedaan om de ‘Potential Shippable’ code verder af te testen en/of om zaken te regelen om het acceptabel te maken voor de beheerorganisatie. Om de bal over de lijn te brengen, zo gezegd.

Ook zie ik dat voorafgaand aan een Scrum-sprint nog het een en ander moet gebeuren voordat de Sprint Planning Meeting kan plaatsvinden. In het bijzonder is dat het afbreken van gecompliceerde Business wensen tot te verwerken User Stories, die voldoen aan opgestelde ‘Definition of Ready’.

En nu is de vraag: hoe doen we nu dat afbreken op een effectieve en efficiënte wijze? De Scrum Guide geeft aan dat dit proces ‘Product Backlog Grooming’ heet. En dat goed 'groomen' heel belangrijk is. Helaas geeft het weinig houvast over ‘hoe’ je dat moet doen. Het ligt redelijk voor de hand om voor dit probleem ook een ‘Lean’ manier te zoeken, en gelukkig is die er ook: Kanban.

Met de Kanban methode worden alle halffabricaten om te komen tot Ready User Stories, just-in-time gemaakt. Analisten, de Product Owner en het team gaan pas aan het Groomen van User Stories doen als er een echte klantvraag (pull) is. Zo wordt en geen onnodige voorraad opgebouwd en wordt de werklast in balans gehouden.

Voorwaarde is wel, dat de mensen in het Scrum team niet 100% op het Scrummen worden gealloceerd. Immers, met alleen maar Scrummen win je de wedstrijd niet: je zult ook moeten voorbereiden en afmaken!

Van berg tot siergrind

Onlangs was ik met de kids naar Naturalis. Daar waren ze erg onder de indruk van het proces ‘van berg tot klei’.  Hoe door eeuwenlang slijpen van de elementen, zoals wind, regen en stroming, een berg verwordt tot grind en klei.

In mijn werkomgeving zie ik een ontwikkeling die ik hier tegen aan wil houden: alles moet tegenwoordig gescrumt worden. En als toch al wat oudere rot in het vak, krijg ik de kriebels. Is er weer een silver-bullet ontdekt? Weer een wonderpil voor al uw kwalen?

Niet dat ik tegen Scrum ben, integendeel. Als ik hovenier zou zijn, en mijn klant wil een tuinpad aangelegd hebben dan zal ik dat al Scrummend met een grote berg siergrind goed kunnen aanpakken. Maar een berg omzetten naar siergrind zal toch iets meer voorbereiding vereisen dan ik in een sprint van twee weken aankan.

Op zoek naar een onderbouwing mijn gevoel hierover, kwam ik onlangs het Cynefin model tegen dat Dave Snowden al in 1999 heeft opgesteld voor het classificeren van uitdagingen. Dat model kan goed gebruikt worden om te bepalen of, en zo ja: hoe, een probleem met Scrum (of een andere Agile methode) kan worden opgelost.

Het geeft vijf gebieden waar een probleem of uitdaging zich in kan bevinden. Ik richt met nu even op de twee meest relevante voor projecten: Complex en Gecompliceerd. Beide worden getypeerd dat er een verband is oorzaak en gevolg, maar niet een heel simpel verband.

Complex is als je vooraf geen eenduidige gevolgtrekkingen hiertussen kunt maken. Dit soort uitdagingen zijn perfect om op een Scrum manier op te pakken. Het Cynefin model geeft aan, dat de beste response in een complexe situatie ‘Sense - Analyse – Respond’ is.  Oftewel snel bouwen, demonstreren en als het nodig is aanpassen.

Gecompliceerd is als er wel vaste relaties bestaan tussen oorzaken en gevolgen, maar dat deze niet direct zichtbaar zijn en dus eerst ontdekt en daarna grondig onderzocht moeten worden alvorens men er conclusies uit trekt. Het Cynefin model geeft aan in dit soort gevallen de meest aangewezen reponse ‘Sense - Categorise – Respond’is. Oftewel systematisch denken: het hele systeem in kaart brengen en relaties tussen de verschillende elementen beschrijven. Daarna het geheel analyseren om te zien waar er versterkende of compenserende oorzaak-gevolg relaties in werking zijn. Het is pas als al deze interacties duidelijk zijn, dat je het probleem kunt beginnen oplossen.

Hoe om te gaan met gecompliceerde problemen?  Of met User Stories die te complex en/of gecompliceerd zijn? Gelukkig is daar wel een oplossing voor: Product Backlog Grooming. Daar zit volgens mij de sleutel tot succesvol Agile ontwikkelen. Later hierover meer...

Over slechte huwelijken

Voor velen is CMMI de richtlijn en meetlat voor projecten in het land van systeemontwikkeling. En niet ten onrechte, want het is een geaccepteerde meetlat en, omdat het is gebaseerd op best-practices, een goed referentiekader om projectmanagement in te richten of te verbeteren. Net zoals PRINCE2 dat is.

Met de huidige opkomst van Agile en Scrum wordt er driftig gezocht naar hoe dat past binnen bestaande referentiekaders, zoals PRINCE2 en CMMI. Er wordt al gemompeld over het maken van een CMMA, een CMM voor Agile. Dit lijkt me een goed plan, want andere pogingen die worden ondernomen lijken me slechte 'match making'.

Zo is het SEI zelf gekomen met concessies in de laatste versie van CMMI (versie 1.3) aan het Agile gedachtengoed. Met wat side-notes in de verder bijna ongewijzigde procesbijbel, wordt Agile er bij ingehuwelijkt.

Volgens mij gaat dit niet lukken. Als we namelijk teruggaan naar waar CMMI voor was bedoeld, legt het zich vanzelf aan ons uit: CMMI was opgezet omdat grote projecten veel risico liepen op uitloop, budgetoverschreidingen en ontevreden klanten. Daarom is gekeken de best-practices voor relevante processen. En die zijn beschreven in CMMI.

Maar, als we nu afstappen van grote projecten en gaan Scrummen, omdat we minder kans willen lopen op uitloop, budgetoverschreidingen en ontevreden klanten, dan moeten we op zoek naar nieuwe kritische succesfactoren. En daarna best-practices verzamelen, bundelen en delen. Dus geen huwelijken forceren, als de gemeenschappelijk basis niet matcht.

Het vriendelijke geestje in Scrum

Jeff Sutherland zelf adviseert om, als je Scrum gaat invoeren, te beginnen met Scrum volledig in te voeren. En pas als je er handig in wordt, het aan te passen aan jouw situatie. Hier ben ik het wel mee eens, maar werpt wel gelijk de andere vraag op: "Wat betekent dat eigenlijk: Scrum helemaal invoeren?" of te wel: "Wanneer is Scrum Scrum?".

Je zou kunnen zeggen: we bemensen alle Scrum rollen, voeren alle Scrum rituelen uit en gebruiken alle Scrum artifacts. Of te wel: we zeggen wie de ScrumMaster is, wie de Product Owner, we doen de stand-up meetings en demo's en we plakken de muren vol met geeltjes. Maar iets in mij zegt mij dat er meer nodig is dan dat.

Volgens mij gaat het om de geest. Net zoals (vroeger) bij het invoeren van PRINCE2: het gaat niet alleen om de templates en het jargon, maar het gaat erom dat je vooral en bovenal de geest invoert. En bij Scrum is dat gelukkig een heel vriendelijk geestje.

Ik zie de geest van Scrum vooral in het empoweren van het team. En dat betekent dus dat de Product Owner niet voorkauwt hoe iets gemaakt moet worden, maar alleen wat hij wilt hebben. En dat lijkt eigenlijk wel wat op de zelfde geest die in PRINCE2 zit: product gebaseerd werken boven activiteit gericht plannen.

Hierbij wil ik niet zeggen dat Scrum en PRINCE2 hetzelfde zijn.Geestelijk gezien zijn er wel degelijk overeenkomsten en verschillen. En zo zal ook bij Scrum invoeren gelden: als we de geest invoeren, volgt het lichaam vanzelf.

Over oude wijn en nieuwe zakken

Scrum wordt op veel IT afdelingen in Nederland ingevoerd. Ieder zoekt daarin zijn eigen weg en loopt tegen issues op. O nee: tegen impediments. Zou er een top-40 zijn van veelvoorkomende impediments? Ik heb hem niet gevonden. Maar in mijn omgeving ben ik er drie tegengekomen die zondermeer hoog op zo’n hit-parade kunnen scoren.

De eerste is het ‘oude wijn in nieuwe zakken’ syndroom. Daarmee bedoel ik dat we bestaande werkwijzen, rollen, processen en procedures (oude wijn) proberen te plooien om te passen binnen de nieuwe Scrum werkwijze (de nieuw zak). Daarbij bedoel ik dus niet dat Scrum oude wijn is in een nieuwe verpakking. Nee, vaak wordt onbewust krampachtig  bestaande werkwijzen in de Scrum wijze van ontwikkelen gepropt. Het effect is dat we alsnog veel  ‘non value-adding waste’ introduceren.

De tweede lijkt hierop, maar is toch anders. Het punt is dat we Scrum maar ten dele invoeren. Meestal in het software-  of systeemontwikkelingsproces. Maar de muren tussen de IT afdeling en ‘de business’ blijven staan. Een IT projectleider wordt de Product Owner en gaat voor ‘de business’ bepalen wat ze willen. En omdat zeker te stellen grijpt hij/zij terug op klassieke methoden zoals stakeholdermanagement en ‘management by jumping around’.

De derde is de partiële optimalisatie . Of zoals Eli Goldratt zegt: ““A system of local optimums is not an optimum system at all.” Wat ik zie, is dat er in een deel van het totale veranderproces (voorheen ‘project’ genoemd)  met Scrum wordt gewerkt, maar dat daarvoor en daarna nog standaard watervalfasen worden uitgevoerd met veel langere doorlooptijden dan de gemiddelde sprint. Ik denk dan aan Impact Analyses, FAT en GAT testen et cetera.

Dit is de top-3 van mij. Ik ben benieuwd wat jij vandaag als nieuwe binnenkomer ziet!

Hoeveel Product Owners heb je nodig?

‘Business Value’ is een belangrijk begrip in Scrum. En niet ten onrechte. In PRINCE2 is het ook een belangrijke pijler onder de methode, maar daar heet het de Business Case: de zakelijke rechtvaardiging. Het mooie, vind ik, van Scrum is dat er nu ook een duidelijk rol aan wordt gekoppeld, namelijk die van een Product Owner.

Maar is er wel 1 Product Owner aan te wijzen? Is een product of service in een bedrijf niet het kindje van velen? De eigenschappen van een product, vooral de niet-functionele, zijn slechts indirect aan hard ‘Business Value’ te koppelen. Ik denk daarbij aan Security eisen, Architectuur eisen, Compliance eisen, en zo kunnen we nog wel even door gaan.

Hoe bewaken we nu dat er een juiste balans is tussen productfocus, op functionele eisen met ‘Business Value’ enerzijds, en focus op de niet (direct) functionele eisen. Volgens Scrum is dat gewoon even iets dat de Product Owner moet doen. Mooi gezegd en lastig gedaan. De Product Owner krijgt zo wel heel veel op haar (of zijn) bordje.

Een oplossing is het regisseren van belangen onderbrengen bij een onafhankelijke en objectieve rol. Die rol bestaat nu nog niet in Scrum, en ook niet in PRINCE2. Hoewel, in PRINCE2 is er Project Assurance. Maar in de praktijk wordt dat meer ingevuld als procesborging. En wordt vandaar uit getoetst of de Project Manager wel goed aan stakeholdermanagement doet. In Scrum is dit 'gewoon' de taak van de Product Owner.

Ik pleit voor het benoemen van de rol 'QualityDirector', of in het Nederlands: 'Kwaliteitsregisseur'. Iemand die de balans bewaakt tussen de realisatie van directe ‘Business Value’ (de belangen van de Product Owner) en die van de realisatie van de niet-functionele eisen (de belangen van het hele bedrijf).

Over Scrum, PRINCE2 en Waste

Agile projectmanagement, en Scrum in het bijzonder, wordt steeds populairder. Er lijkt een tendens te zijn om alles wat riekt naar overhead, 'waste' in goed Leans, lekker weg te snoeien. En het mag! Want Lean gaat over het wegwerken van alle 'waste'. Alles wat niet waarde toevoegt is 'waste' en het voorkomen van 'waste' is de eerste en groots haalbare verbetering die je kunt doen.

In Nederland is PRINCE2 zeer breed ingevoerd als projectmanagementmethode. Voordelen zijn er genoeg, maar er zijn net zoveel nadelen. Het meest genoemde, terecht of niet, vooronderstelling tegen PRINCE2 is dat er zoveel documentatie is te maken. Helaas is het vaak nog waar ook. Niet door PRINCE2, maar door de implementaties bij veel organisaties.

Maar waarom hebben veel organisaties besloten om veel te laten documenteren? Omdat dat moest van PRINCE2? Dat kan toch nooit de enige of grootste reden zijn geweest!

Nee, de reden is volgens mij een andere. Onzekerheid!

Als je een nieuwe manier van werken introduceert, zoals jaren terug PRINCE2, is dat voor de gebruikers daarvan wel even wennen. En als we iets anders moeten doen dan we gewend waren, dan  worden we onzeker: 'hoe moet dat dan?'. Om daar aan tegemoet te komen worden de PRINCE2 processen uitgeschreven tot op het niveau van procedures. Maar dat is dan toch nog niet genoeg: 'hoe moet het resultaat van die procedure er dan uit zien?', 'is daar geen template voor?'.

En zo komen de verplichte templates onze wereld in. Dezelfde templates die later zien als 'waste'. En ja, in zekere zin zijn die ook 'waste'. Maar geen pure 'waste' die moet, maar 'value enabling waste' die we zelf wilden.

Na Pino nu Sino

Toen PRINCE2 in Nederland voet aan de grond kreeg, kwam snel daarna het begrip 'Pino' op. Dit betekent 'PRINCE2 in name only'. Velen waren gecharmeerd door PRINCE2, maar gingen het vervolgens maar een beetje adopteren. Klinkt als een beetje zwanger. Om het netjes te maken werd het fenomeen van 'wel PRINCE2 noemen, maar niet geheel invoeren' Pino genoemd.

Nu zie ik steeds vaker om mij heen Scrum ingevoerd worden. En  daarbij speelt hetzelfde als met PRINCE2 en Pino: de makkelijke krenten worden uit de pap gevist, en we roepen dat we druk aan het Scrummen zijn. Maar welke krenten zijn het? En hoe erg is het eigenlijk?

'Krenten uit de pap vissen' heeft volgens mij het risico in zich dat de gehele kracht van de methode, keurig vastgelegd in het Agile Manifesto, niet worden gehaald. Maar ten koste van alles alleen maar Scum in zijn geheel invoeren is een ander uiterste. Volgens mij ligt de waarheid, zoals zo vaak, weer eens ergens in het midden: kijk met gezond verstand naar wat je doen en pas Scum toe zoals het in jouw situatie gepast is en je het meeste oplevert. En probeer het een paar sprints. Maar als je alleen maar de Scrum-ceremonies gebruikt en dan toch noemt dat je Scrumt, dan is het 'Sino'. Sorry.