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.