Scrum en deadlines; vriend of vijand?

Een deadline? Dat kan niet! Scrum doet niet aan deadlines. Zonder precieze scope krijg je geen kant-en-klaar eindproduct op een bepaalde datum. Zo werkt dat gewoon niet. Scrum gaat niet om het leveren van features. Het gaat om het bereiken van een doel, een uitkomst, waarde leveren en een korte time to market. Te stellig? Ja, waarschijnlijk wel…

Zo werkt Scrum nu eenmaal

Wij bepalen wat de meeste waarde heeft uit de waarschijnlijk lange lijst van noodzakelijke en gewenste features voor een nieuwe applicatie. We beginnen met de ontwikkeling van de basis en werken in kleine stappen naar het (eind)doel toe. De enige deadlines die wij hanteren is het einde van een sprint. Dat kan niet anders, want software ontwikkeling is complex, het is lastig te voorspellen. Hoe groter het project hoe complexer de ontwikkeling. Daarbij, als we van te voren alles gaan bedenken, dan zijn we aan het watervallen. 

Het is wel waar, maar het klopt niet

Wat mij betreft is bovenstaande allemaal waar. Echter in de praktijk is het niet zo simpel. Bedrijven hebben altijd budgetten. Je kunt niet meer uitgeven dan je hebt en het is logisch dat je dan wel wilt weten wat je krijgt. Daarnaast zijn er misschien zelfs al beloftes of toezeggingen gedaan. Aan het MT of aan jouw klanten. Er is al beslist wanneer bepaalde zaken geleverd moeten worden. Reclamecampagnes zijn al ingekocht en ingepland, etcetera. Er is dus wel degelijk een deadline, en dus niet alleen die van één of meerdere sprints.

Developer vs. Klant

Ben je developer? Dan hoor ik je denken. “Maar het kan niet! Scrum en deadlines? Nee dat gaat echt niet.” Hoe goed de club van developers ook is, the devil is in the details. Bij het ontwikkelen van software en zeker maatwerk software kun je niet alle scenario’s voorspellen.

Ben je een potentiële klant? Dan hoor ik je ook. “Ik heb een budget gekregen, een deadline en een pakket aan voorwaarden” Je hebt zekerheid nodig, het vertrouwen dat je op datum x een product hebt dat je kunt lanceren zonder diep in de rode cijfers te zitten.

Dus wat nu? Het is niet voor niets een veel besproken onderwerp waarbij de meningen flink uiteenlopen. Er is helaas ook geen eenduidig antwoord. Maar in de praktijk heb je nu eenmaal te maken met budgetten en deadlines, het is niet anders. Je zult per project een manier moeten vinden om daar goed mee om te gaan. Zonder dat je ‘succesvol’ de deadline haalt, maar de klant toch niet helemaal tevreden is… 

Deadline gehaald! ‘Precies’ gedaan wat de klant vroeg, binnen de tijd en binnen budget. Dit is het beste paard van stal, toch?

Duivelse dilemma’s

Iedereen kent de zogenaamde duivelsdriehoek wel (The Triple Constraint: The Project Management Triangle of Scope, Time, and Cost)

In een project met een deadline staat twee van de drie hoeken al vast; tijd en geld. 

Scope blijft over en die kan dan dus niet vast staan. De scope moet flexibel zijn. Maar wat betekent dat dan? Klanten worden daar (terecht!) zenuwachtig van. “Heb ik dan straks een product dat niet aan al mijn eisen voldoet?” Helaas in de praktijk vaak wel, omdat dit niet goed aangepakt wordt. Maar dat kan echt anders!

Het begint met het benoemen van het doel dat je wilt bereiken. Waarom is die deadline zo belangrijk en welk doel dient het? Het is belangrijke informatie, omdat het ontwikkelteam met die informatie met je kan meedenken en je kan helpen besluiten te nemen rondom het bepalen van delen van de scope. 

Dit is onze aanpak

Is het doel duidelijk, dan gaan we hoog-over de scope bepalen van de features die voor de deadline af moeten zijn om dat doel te bereiken. Mensen vragen mij wel eens wat ik bedoel met hoog-over. Een goed voorbeeld is het toepassen van een zoekfunctionaliteit in een applicatie. 

Stel dat een zoekfunctionaliteit een vereiste is om het beoogde doel te bereiken. Dat dit een feature is die voor de deadline af moet zijn. Dan is Zoeken dus onderdeel van de Scope. Je bepaalt alleen nog niet wat deze feature precies inhoudt. Nog niet.

Feitelijk bepaal je zo je MVP (Minimal Viable Product), nog zo’n veelbesproken onderwerp, maar daar gaan we een andere keer dieper op in. 

Als je de lijst met features compleet hebt ga je deze prioriteren. Het is in dit stadium nog geen gegeven dat de ontwikkeling van al deze features allemaal haalbaar is voor de deadline. Of dat deze in het budget gaat passen. Software ontwikkelen is immers complex en lastig te voorspellen. 

De volgende stap is de meest belangrijke. We gaan andersom redeneren. In plaats van alle features in detail uit te werken, gaan we vanuit beschikbare tijd – of beter gezegd vanuit het budget – kijken wat past. Budgetgestuurd werken noemen wij dat. Je gaat aan de verschillende onderdelen een deel van het budget toewijzen. Daarmee krijg je een eerste inzicht in de haalbaarheid van de hoog-over onderdelen.

Van hoog-over naar de details

Nu gaan we elke feature in detail uitwerken. Niet gebaseerd op alle wensen die er zijn, maar op basis van het budget dat er voor beschikbaar is. We houden hierbij rekening met het doel dat het moet dienen.

Op deze manier krijg je meer inzicht in de haalbaarheid. We kunnen bepalen of sommige zaken simpeler moeten. Zijn er nice to haves te identificeren die we ook na de deadline kunnen doorontwikkelen. 

Denk hierbij weer even aan het voorbeeld van de zoekfunctionaliteit. Extra zaken als autocomplete-functionaliteit, filtering of uitgebreide zoekopties zouden ook na de deadline kunnen. Als een zoekfunctionaliteit in beginsel maar goed werkt en gebruiksvriendelijk is.

Het kan ook zo zijn dat er ruimte over is om extra features op te pakken, maar eerlijkheidshalve is dat in de praktijk vaak niet het geval. Meestal zijn de features en wensen al meer dan ambitieuze wensen om voor de gestelde deadline te realiseren.

Stabiel in zwart-wit

Wat we dus feitelijk proberen te doen is een eerste volledige versie van het product ontwikkelen, maar dan zonder alle ‘toeters en bellen’. Geen half paard dus, maar een volledig exemplaar waarmee je wel direct je gestelde doelen kunt bereiken. Een beetje zoals onderstaand plaatje, de eerste versie is stabiel zwart-wit. De kleur tekenen we later in. De kleuren zijn de fijne extra features die het geheel ‘smoel’ geven, maar die geen invloed hebben op de levensvatbaarheid van jouw applicatie.

Klinkt als toch watervallen?

Is deze manier dan niet toch watervallen? Wat mij betreft niet. Waterval is van te voren alles bedenken en exact zo uitvoeren als bedacht. Er kan niet meer van afgeweken worden en aan het eind wordt het gehele product in een keer opgeleverd. Maak je de jasjes van de ruiters rood of toch blauw? Je hebt door het eerste gebruik van je applicatie misschien ontdekt dat blauw misschien wel beter zal werken…

Stip op de horizon

Conclusie: Scrum is dus niet gewoon een zak geld op tafel zetten, beginnen en maar zien waar we uitkomen. Ook bij Scrum denk je van te voren na wat je gaat ontwikkelen, wat dat gaat kosten en wanneer het af moet zijn. Je hebt dus wel degelijk een stip op de horizon, een deadline. Het voordeel zit hem hierbij in de flexibiliteit, snel waarde leveren, feedback vergaren, eventueel aanpassingen doen, maar wel altijd rekening houdende met het beschikbare budget en de deadlines.

En ja, natuurlijk is dat lastig en natuurlijk loop je tijdens het traject tegen onvoorziene zaken. Maar dat is altijd zo, bij elk project, met elke methodiek. Het gaat erom dat je er vooraf goed over nadenkt en zorgt dat iedereen hetzelfde doel nastreeft!

Verder praten over onze aanpak? Leuk, we staan altijd open voor andere ervaringen en visies. Neem hier contact met ons op!