Top three daily stand-up failures, and five countermeasures

One of the first and most visible parts of doing Scrum is having a Scrum Board and doing daily stand-ups in front of that board. In this blog I want to address three of the most common daily stand-up failures, and how to solve them.

Theory

In stand-up meeting you are told to keep it in fifteen minutes and to address, person per person, (1) what you’ve done for the team yesterday, (2) what you intend to do for the team today and (3) what is blocking you and the team.

The Good

I really like having short daily meetings, and giving all attendees an equal voice. It’s good that team members get out of their bubble (like most developers tend to have) and synchronize their planned activities and share their teams’ successes. It really fires individuals up to work as team players and start to collaborate.

The Bad

However, I do see many team members having troubles with the daily stand-up meetings. They say that these meetings are not inspiring, but in fact are a waste of time. I’ve actually once heard team members propose to have the daily stand-up meeting only once a week! When you see this happening, as a Scrum Master, Agile Coach or as a fellow team member, you have to intervene. Otherwise you’ll wind up having monthly project status reporting meetings, detailed project plans and you team member getting back into their bubbles again.

The Why

Why does this happen?
I think the most defining factor why teams tend to become grumpy about the daily stand-up, is the result of the success of the daily stand-up! Because team member do communicate far more and better than before the introduction of the daily stand-ups, the need for daily stand-ups seems to diminish.

 

Early warning indicators

There are three patterns that are early warning indicators for daily stand-up failures:

1.  Story telling; the fifteen minute time box is not met because team members are explaining too much about what has happened. And also what (and why) they did and didn’t do in respect to the intentions expressed in the previous stand-up.
2. Problem solving; in the stand-up meeting team members drop their frustration about a problem they are facing, and that they see as an impediment. Most often it is not even a real impediment, but an excuse to explain why they didn’t complete their intended tasks. Helpful as team members are, the problem dropped is directly discussed in the stand-up, resulting in 'one on one' discussions and other team members to dream away. This will not help in keeping the stand-up 'short, snappy and inspiring'.
3. Status reporting to the Scrum Master; team members report their status to the leader. But there should not be a leader in a Scrum Team. The job title of the Scrum Master is not ‘Scrum Manager’ with a purpose. The effect of team members talking directly to the Scrum Master is that team members are waiting for their turn and feel the urge to defend themselves, especially when committed tasks are not completed.

Okay, but how to counteract these patterns when you see them in your team?

 

Countermeasures

What to do:

1. Address the issue directly. Don’t wait till the next Sprint Retrospective meeting, but act on it on the spot.
2. Repeat the reason. Make clear that the daily stand-up meeting is not for the Scrum Master, but for all team members to align and synchronize the work at hand. This is a message to repeat often.
3. Look forward. Stress that we don’t bother about yesterday, but focus on what to do today. This is dropping the first of the Scrum Guide’s three questions to ask at the stand-up. My experience is that achievements made are reported naturally and don’t need to be expressed explicitly. In fact, when you do put explicit emphasis on what has been achieved yesterday, results in negative focus on what has not been achieved. And that results in team members feeling the urge to defend themselves.
4. No impediments. Don’t use the word ‘impediment’, but use the phrase ‘need help’. An impediment is seen as someone else’s problem, resulting in social loafing or even in collective team demotivation. Re-framing it to ‘needing help’ drags problems back into the team’s own circle of influence and is an invitation to work together to tackle the challenge.
5. Insect and Adapt. Ask the team members once in a while, directly after a stand-up, how we could have had the same level of information sharing in a more ‘short and snappy’ way.

Agile levert minder voor minder - over vliegenvangen en Business Value

Managers van IT afdelingen worden klassiek afgerekend op de productiviteit van doorvoeren van veranderingen en de beschikbaarheid van de systemen. Helaas vormt vaak achterblijvende productiviteit de aanjager voor het introduceren van Agile werken. Waarom helaas?

Even een stapje terug: het doel van IT is dat gebruikers optimaal worden ondersteund in wat ze (moeten) doen. Daarvoor is het goed dat ze de benodigde beschikbaarheid van de IT hebben en dat de IT wordt aangepast aan de veranderde omstandigheden. Immers ‘fit for use’ is uiteindelijk waar gebruikers systemen op beoordelen, en voor willen betalen.

Stukje theorie:

Productiviteit is de relatie tussen efficiëntie en effectiviteit. Efficiëntie is de mate van gebruik van middelen om een bepaald doel te bereiken. Het doel van de gemiddelde IT manager is het aanpassen van de IT systemen aan veranderde omstandigheden, zoals nieuwe gebruikerswensen. De mate waarin dat lukt noemen we effectiviteit.

Als IT managers worden afgerekend op productiviteit, leidt dit tot het najagen van ‘veel voor weinig’. De belofte van Scrum, zoals door Jeff Sutherland zelf ook vaak geuit, van ‘hyper productive software development’ valt daarom goed bij de IT manager. En dat is goed te begrijpen, want het lijkt de weg naar ‘meer voor minder, precies waar hij/zij op wordt beoordeeld.

Maar zijn we wel op zoek naar ‘meer voor minder’? Volgens mij is het beter als we voor elkaar hebben gekregen dat we ‘minder voor minder’ krijgen. En dat klinkt wellicht gek, maar laat ik dit eens verduidelijken met een voorbeeld.

Als we last hebben van vliegen, kunnen we ze meppen. Als het doel is om zoveel mogelijk vliegen te meppen, kan het slaan met een opgerolde krant erg effectief zijn. En als we twee vliegen in een klap weten te raken, lijken we ook nog efficiënt. En voor je het weet lijkt het  investeren in een high-tech vliegenmepper aantrekkelijk. Maar slimmer is het om te kijken wat het echte probleem is en hoe we dat kunnen wegnemen (effectief) met de minst kostende middelen en inspanningen (efficiënt). Dat zou, in dit voorbeeld, het verwijderen van rottend fruit van de fruitschaal kunnen zijn J

Bestaande metrieken binnen IT afdelingen zijn gericht op productiviteit ten aanzien van bestaande (IT) oplossingen. Dit optimaliseren is blijven meppen en investeren in mep-technieken. Maar de echte verbetering zit in het daadwerkelijk snappen van wat de gebruikers doen en weten waarop zij de IT ondersteuning daarvoor beoordelen.

En laat ik een tip van de sluier oplichten: gebruikers zitten niet te wachten op een opeenstapeling van features. Dit wordt het best samengevat door Antoine de Saint-Exupéry (1900-1944): “Perfectie wordt niet bereikt als er niets meer valt toe te voegen, maar als er niets meer is weg te laten”.

Daarom is het jammer dat, omdat de achterblijvende productiviteit vaak de aanjager is voor het introduceren van Agile werken, het succes van Agile teams wordt gemeten in resultaat-meeteenheden, zoals functiepunten. Veel beter is het om het succes te meten in effect-meeteenheden, zoals ‘Business Value’. En deze is te bepalen: door te praten met de gebruikers en te meten hoeveel features er nog zijn weg te halen.

Principes achter de Scrum principes

Als je de Scrum Guide van Sutherland en Schwaber leest zijn er drie principes: Transparency, Inspect and Adapt. Niets mis mee. Sterker nog: ik ben het geheel eens met deze drie principes. Maar alleen met deze principes in de hand, en het invoeren van de Scrum events en rollen, zijn we er nog lang niet.

Welke principes zijn er nog meer achter het succesvol werken met Scrum?

Er schieten er mij zo een paar andere te binnen:

• Onderken dat Scrum voor complexe problemen is – Ik kom nog wel eens tegen dat standaard werkzaamheden geforceerd worden om uit te voeren op een Scrum manier. Doe dat niet. Voor standaard werkzaamheden zijn passendere oplossingen, die ook veel makkelijker zijn aan te passen aan jouw situatie, zoals Kanban en Lean.
• Stimuleer directe samenwerking – Dit komt namelijk niet vanzelf. Veel te vaak zie ik teamleden terugschieten in hun eigen kenniscontainer (silo). “Dat is van mij.” “Dat moet een tester doen, niet ik.” En meer van dit soort citaten horen niet bij Scrum, maar sluipen er toch wel her en der in. Ook hoor ik nog veel te vaak de misvatting uitgesproken worden dat volgens Scrum iedereen in het team alles moet kunnen, en omdat dat niet zo is heeft ieder recht op zijn/haar eigen silo. Neen. Het team moet alle kennis en ervaring hebben om alles te kunnen wat nodig is om de DoD te realiseren. En er wordt wel verwacht dat ieder teamlid daar helpt waar nodig is om het teamsucces te realiseren. Dit gedachtegoed in het team krijgen en houden vergt continue aandacht.
• Onderken het belang van een goede Product Owner rolinvulling – Dit is volgens mij het meest onderschatte aspect binnen Scrum. Het zo maar even het enige aanspreekpunt zijn voor een ontwikkelteam om alle functionele eisen (in de Backlog’s) en niet-functionele eisen (in de DoD) te snappen, kunnen uitleggen en beslissingen over te kunnen en mogen nemen…. Ik neem daar mijn petje voor af. En, o ja, ook nog even zorgen dat die vermaledijde Product Backlog continue voldoende is bijgewerkt en gedetailleerd voor iedere Sprint Planning Meeting…
• Denk altijd vanuit het productgebruik – Bestaande applicaties zijn, vaak, ingericht in componenten. Grotere applicaties zelfs in lagen. Hoe map je meerdere Scrum team hier op? Het is verleidelijk om applicatie structuren te volgen, want die zijn zichtbaar. Maar het allerbelangrijkste, niet zo expliciet aangeven, principe van Scrum is dat je alles vanuit het gebruik van het product moet inrichten en uitvoeren. Dit is verkapt in het begrip ‘business value’. Immers, alleen meer of beter gebruik (‘use’) van een systeem levert revenu!

Welke schieten jou te binnen?

Van ‘Big Bang’ naar ‘Small Bang’, dankzij Scrum

Okay, alles is relatief en elke vergelijking heeft zo zijn manco's. Toch wil ik proberen het vak van software ontwikkeling tegen de volgende twee theorieën te houden.

1. Big Bang

13,7 miljard jaar geleden ontstond het heelal. Tegelijkertijd met de oerknal zouden ruimte en tijd zijn ontstaan. De theorie is onder meer gebaseerd op de waarneming van het voortdurend uitdijende heelal.

2. Evolutie

Maar na die 'Big Bang' bestond de mens nog niet. Zelfs de dinosauriërs nog lang niet. Flora en fauna zijn, na die Big Bang, veranderd in de loop van de generaties als gevolg van genetische variatie, voortplanting en natuurlijke selectie.

Jarenlang hebben we geprobeerd, met wisselend succes, om software op te leveren volgens het ‘Big Bang’ scenario. En om de kans op succes te vergroten hebben we dat proberen te managen met methoden zoals PRINCE2 en technisch te faseren met de waterval methode.

En als dat een paar keer achter elkaar niet helemaal succesvol is verlopen, vergroten we control-factor: meer management en meer bureaucratische voorschriften en verplichte templates.

Daarnaast kennen we de wet van Barry Boehm: fouten zo vroeg mogelijk voorkomen omdat de kosten van later pas vinden en repareren exponentieel stijgen. Dus gaan we (nog) meer de kop van het project aanzetten. Met als gevolg dat projecten nog langere doorlooptijd hebben voor dat ze met een ‘Big Bang’ demonstreren wat ze dachten te moeten opleveren.

Met Scrum gaan we helemaal de andere kant op: niet van te voren alles ontwerpen, maar binnen time-boxen dat opleveren waarvan we weten dat het nodig is en wat we in een dergelijke time-box ook kunnen realiseren. En zo de software laten evalueren tot we de maximale ‘business value’ hebben mogelijk gemaakt.

Is dit het einde van het Bang model in softwareland?

Nee, volgens mij niet. Ook een Scrum team heeft een basis nodig om aan te werken. En die basis heeft een belangrijk kenmerk in zich wat doet pleiten voor een Bang-scenario: vaste requirements.

Maar, we kunnen nu volstaan met een ‘Small Bang’ scenario. En dat kan prima met een praktische invulling van bijvoorbeeld PRINCE2 worden gemanaged, in combinatie met het waterval-model. Als we dan de overhead, bureaucratie en controle-neiging maar weten te beheersen.En daarna met Scrum de software verder evalueren.

Agile en ISO 25010

Er wordt heel wat afgeblogd over het wel of niet kunnen mengen van Agile met alles wat we eerder al hadden. PRINCE2, RUP, MSP, CMMI, je noemt het maar. Gek genoeg een stuk minder over een van de weinige ISO standaarden die ik zelf regelmatig gebruik: ISO 25010 (opvolger van de beruchte ISO 9126 serie).

De ISO/IEC 25010:2011 standaard heet ook wel 'SQuaRE': Systems and Software Quality Requirements and Evaluation. Ook deze ISO standaard is voor velen van ons droge, theoretische kost. Waarom begin ik er dan over?

Het mooie aan deze standaard is, vind ik, dat het een indeling en beschrijving geeft van aspecten aan een systeem waarop je de kwaliteit kunt beoordelen. Requirement engineers en testers gebruiken deze lijst in klassieke software ontwikkelprojecten om zeker te stellen dat alle eisen en wensen vooraf worden bepaald en achteraf worden geverifieerd.

Als we Agile werken willen we geen lijvige documenten vooraf. En met een saaie ISO standaard onder de arm bij een Scrum team binnen lopen is de manier om direct weer weggestuurd te worden.

Er zijn manieren om de handige opsomming van karakteristieken van productkwaliteit wel effectief te gebruiken. In Agile omgevingen moeten we dan wel goed onthouden dat we deze checklist niet moeten invoeren als een verplichte meetlat of template.

Hoe dan wel? Ik zie daarvoor minimaal de volgende twee mogelijkheden:

1. Als een Product Owner toch niet geheel tevreden is over het hoe het systeem is: gebruik de vijf 'Quality in Use' karakteristieken als startpunt voor een root-cause onderzoek.
2. Als het Scrum team (te) veel werk terugkrijgt waarvan ze dacht dat het af was (technical debt): gebruik de acht Product Quality' karakteristieken als startpunt voor een root-cause onderzoek.

Als dit leidt tot inzicht dat er gebruiks- of producteisen zijn die eerst niet voldoende aandacht hebben gehad: voeg ze toe aan de 'Definition of Ready' of aan de 'Definition of Done'.

Waarom Agile en Scrum toch zo populair zijn (geworden)…

Wat wil een gemiddelde programmeur het liefste doen?  Software maken!  Hoe meer hoe beter!

Toch wordt momenteel het Agile software ontwikkelen steeds meer omarmd. Dat lijkt een tegenstelling. Een van de Agile principes is toch om zo min mogelijk code te maken. Weliswaar dan wel die code die het eerst en meest waardevol is voor de klant, maar wel zo min mogelijk

In het onderzoeksrapport “Xebia Agile Survey Nederland 2011” staat dat slecht in 4% van de gevallen het de ‘business’is die de verandering naar Agile hebben geïnitieerd en gedragen. Waarom komen de IT’ers er dan zelf mee.  Waar komt dan die drive om Agile, meestal in de vorm van Scrum, op te pakken?

Volgens mij zijn hier drie oorzaken voor:

1.      We zijn wat doorgeschoten in controle

Projecten gaan vaak mis: ze kostte te veel, leverde te laat op en dan vaak ook nog niet wat de klant eigenlijk echt wilde. De meest voor de hand liggende reactie is: Alles strakker aantrekken; Zet die scope vast; Werk met vastgelegd projectrollen. En, vooral in Nederland, is daarbij PRINCE2 geadopteerd om die controle door te voeren.

Helaas zien we de positieve effecten hiervan in softwareontwikkelland nog niet vaak terug.

Wel negatieve, zoals…

2.      We zijn wat doorgeschoten in bureaucratie

Door alles zo ‘in control’ te willen brengen hebben we ook wat minder handige zaken geïntroduceerd:

• De verschillende rollen (of disciplines) in een project communiceren via documenten en email. Terwijl samen werken, bijvoorbeeld voor een ‘white board’, vele malen effectiever en efficiënter is.
• Daarnaast veegt ieder zijn eigen straatje schoon. Er is vaak weinig binding tussen de projectleden. Geen gemeenschappelijk gevoelde uitdaging. En dat ondanks ‘team building uitjes’, zoals samen eens kanoën of kaasfonduen.
• En daar bovenop wordt en ook nog eens voor de professional bepaald en gepland wat en hoe hij/zij het werk moet uitvoeren.

3.      We willen eigenlijk bovenal gewaardeerd worden

Ja, ook IT’ers zijn net mensen: ze willen waardering. Waardering voor de resultaten die ze hebben gehaald, samen met anderen. En erkenning dat we professionals zijn die zelf hun werk kunnen bepalen en plannen.

En juist dat is waarom, volgens mij, Agile en Scrum zo worden omarmd. En de business krijgt eindelijk wat het wil: resultaten tegen vaste kosten en op tijd!

Brave New Scrum

Vol goede moed start de eerste sprint. Iedereen heeft ‘de kracht van Scrum’ gelezen. De rollen zijn verdeeld. De eerste Product Backlog staat ‘net genoeg’ klaar. Het pokeren vindt in alle hilariteit plaats. En het bouwen begint. Het team ondervindt dat het samenwerken veel leuker werken is als het uitvoeren van taken uitgedeeld door een manager. Niets staat een ‘Brave New World’ in de weg.

En hier geloof ik ook in. Ik doe mijn best om teams te begeleiden om dit te bereiken. En dat lukt zeer vaak. En voelt u nu ook al een ‘maar’ opkomen?

Ja, er is helaas wel een ‘maar’. Het blijkt namelijk best gemakkelijk om te starten. En vaak wordt er ook nog heel goed gestart. De ‘maar’ zit in het doorzetten en vasthouden. De bron van het niet bereiken van die ‘Heerlijke Nieuwe Wereld’ ligt, volgens mij, in ‘velocity’.

‘Velocity’ is in de Scrum, de maat die aangeeft hoeveel product backlog effort in een sprint gerealiseerd kan worden door een specifiek Scrum-team. En daar komt druk op. Als eerste zijn daar de ‘klassieke’ resource managers die streven naar maximalisatie van efficiëntie. En in hun ogen is ‘velocity’ daar de maat voor. Dus die ‘velocity’ moet vooral continu hoger. Liefst nog aangetoond door Functie Punt tellingen achteraf op gerealiseerde componenten. Daarbij gaan zij voorbij aan wat echt belangrijk is: leveren van ‘Business Value’ in een omgeving waarin gewerkt wordt in een ‘Sustainable Pace’.

Maar ook het team zelf wil maar al te vaak verbeteren. En ook zij zien ‘velocity’ als het meest eenvoudig te meten maat. Helaas gaan zij in hun haast om, per sprint, te scoren soms gekke dingen doen. Het vaakst zie ik dat het team, inclusief de ScrumMaster dus, taken gemakkelijk buiten de Sprints plaatsten, onder het mom van ‘dat kan hier nu eenmaal niet in een sprint’.

Het oppakken van de echte Impediments, zoals de omgeving rond Scrum-teams doordringen van het Agile-gedachtengoed, is de enige weg om daadwerkelijk een nieuwe Heerlijke Wereld te bereiken.

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.