Dimensionaal Plannen in Agile

De afgelopen jaren heb ik gemerkt dat ik steeds vaker over "Dimensional Planning" praat. Ik heb over Dimensional Planning gehoord via Koen van Exem, een van de vroege Belgische agilisten. Het stamt uit de begintijd van de (Belgische) Agile-beweging en is helaas een beetje in de vergetelheid geraakt.

Gisteren had ik een gesprek met JB (Rainsberger) en Alistair (Cockburn) en realiseerde ik me dat ik daar nog een leuk verhaal over heb.

Voordat ik het je vertel, leg ik eerst kort de basis van Dimensional Planning uit. Het idee erachter is dat we onze Stories opsplitsen in verschillende implementatiedimensies. Dat doen we omdat veel van onze klanten aan het eind van de week een Lexus willen hebben. Dat lukt ons misschien niet. Maar we kunnen ze morgen al een Toyota aanbieden. De meeste klanten vinden dat een geweldig aanbod en kunnen wachten tot we de Lexus kunnen leveren (ook wel: snel behaalde ROI).

De manier waarop Koen Dimensional Planning uitlegt, bevalt me erg goed

Stel je voor dat je klant een snelweg wil hebben tussen Amsterdam en Heusden. Je bent behoorlijk goed in het bouwen van snelwegen, dus je begint meteen. Na een paar maanden ben je klaar en laat je je klant vol trots voor het eerst de snelweg gebruiken. Hij komt aan in Heusden, maar ziet er niet bijzonder blij uit. Je vraagt dus of de tankstations, de rustplaatsen en de afritten om de paar kilometer in orde zijn. Hoewel de klant alles bevestigt, lijken je vragen hem alleen maar meer te frustreren. Uiteindelijk gooit hij het eruit: „Dit is niet de plek waar ik naartoe wilde!"

Je kijkt naar het plaatsnaambord: Heusden. Wilde hij niet naar Heusden? Jawel, dat wilde hij.

Maar het blijkt dat er nog een andere plaats is met de naam „Heusden".

Jouw advocaten en die van de klant voeren nu lange discussies over wiens fout dit is en wie voor de verkeerde snelweg moet betalen. (Als je een goede advocaat hebt, zal je klant betalen en nooit meer terugkomen…)

In dit geval zou je goed met Dimensional Planning kunnen werken. Je zou dan eerst een grindweg aanleggen tussen Amsterdam en Heusden.

Na nog geen week zou je al klaar zijn en hebben ontdekt dat je de verkeerde plaats te pakken hebt. Voor jou is dat geen probleem, want je wist dat er het een en ander aan misverstanden zou zijn. Je gaat op onderzoek uit, vindt het andere Heusden en legt een nieuwe grindweg aan. Na nog een week is ook deze weg klaar en stel je samen met je klant vast dat het eigenlijk nog steeds het verkeerde Heusden is. Er zijn namelijk twee plaatsen met die naam in België en nog een in Nederland. Wie had dat kunnen vermoeden?

Na nog een week is je klant blij dat hij eindelijk een grindweg heeft tussen Amsterdam en het juiste Heusden. (En dat veel sneller dan oorspronkelijk gepland in meerdere maanden.)

Hoewel nog niet alle features aanwezig zijn, is er toch al een bepaalde winst te boeken, omdat de klant nu kan pendelen tussen de twee vestigingen van zijn bedrijf. Het is geen geweldige weg en je kunt er niet bijzonder hard rijden, maar het is aanzienlijk sneller dan met de vorige weg en een omweg van 100 km.

De dag na de oplevering van de grindweg begin je te werken aan een kasseienversie van de weg, die je na drie weken ook hebt afgerond. Je kunt ook werken aan een asfalt-, teer- of snelwegversie. In de meeste gevallen willen klanten de snelweg echter helemaal niet meer, zodra ze nut hebben van de eerdere versies.

We weten allemaal dat een klant altijd „Ja" zal zeggen als we vragen of hij een snelweg wil, en dat ontwikkelaars het heerlijk vinden om aan alle features van een snelweg te werken.

In ons autovoorbeeld zouden de meeste mensen ook de Lexus verkiezen boven de Toyota – totdat het op betalen aankomt, want dan volstaat een Toyota ineens ook. En net zo wil ook niet elke ontwikkelaar voortdurend aan alle details moeten denken die de Lexus vereist.

Is het dan niet duur om drie grindwegen, een klinkerweg, een asfaltweg en een snelweg te bouwen?

Natuurlijk is het duurder dan alleen maar een snelweg aanleggen. Maar we weten allemaal dat fouten nu eenmaal voorkomen, en dat het nog altijd goedkoper is dan drie snelwegen moeten aanleggen, zoals vaak gebeurt bij productontwikkeling.  

Bij mijn methode bereiden we ons echter zo goed voor dat we nooit fouten maken…

Als je er zeker van bent en het risico wilt nemen, kun je dat natuurlijk gerust doen. En ook al krijg je gelijk (ik betwijfel of dat altijd het geval zal zijn), ben ik er vrij zeker van dat de meeste klanten al van gedachten veranderd zijn tegen de tijd dat je begint met de aanleg van de snelweg. En maanden voordat je ook maar begonnen bent met bouwen, leveren onze grindwegen dan al Return on Investment op.

Dat klinkt in theorie allemaal heel mooi. Maar werkt het in de praktijk ook echt?

Goeie vraag! Ik was het bijna vergeten; ik wilde in dit artikel een mooi voorbeeld uit het echte leven geven:

Ik heb een paar details van het verhaal aangepast om de klant te beschermen.

Het gaat om de website van een bedrijf. Deze bevond zich echter in een volledig gedemilitariseerde zone van het bedrijfsnetwerk. Daar had men een klein product gecreëerd dat via internet verkocht zou worden. De Chief Financial Officer (financieel directeur) was een groot voorstander van dit product en wilde de verkoopcijfers regelmatig voorgelegd krijgen. Daarvoor hadden echter beveiligingszones doorbroken moeten worden en hadden de verkoopgegevens in het SAP-systeem ingevoerd moeten worden.

In een groot bedrijf is dat een behoorlijk groot project, dat zeker zes maanden ontwikkelwerk kost. De voorbereidingen begonnen met meetings met minstens 20 personen (beveiligingsexperts, SAP-experts, webontwikkelaars en een heleboel managers tot aan de positie net onder de CFO).

Tijdens een daaropvolgende meeting klaagde de CFO over het slechte zicht op de verkoopontwikkeling van het product binnen de belangrijke eerste zes maanden. Ik adviseerde daarom tijdelijke nevenprojecten met behulp van Dimensional Planning (zoals bij het snelweg-voorbeeld).

De onverharde weg-versie:

Elke dag genereerden we een PDF-rapport op de webserver en sloegen dat op op een floppydisk. (We herinneren ons dat een groot deel van het netwerk niet verbonden was met de server.) Elke dag printten we dit rapport uit en brachten een kopie van de verkoopcijfers naar het kantoor van de CFO, waar een stagiair alle gegevens in ons SAP-systeem invoerde. Het PDF-rapport was door een van onze ontwikkelaars gemaakt op dezelfde dag dat het product live ging. Aan het eind van de dag hadden we de gegevens voor de CFO al binnen.

Het eerste probleem: de CFO wilde iets extra's; iets waar de klant op de website naar gevraagd moest worden. De ontwikkelaar had het rapport trots aan de CFO laten zien en ging nu terug naar zijn werkplek. Een half uur later werd op de website de aanvullende informatie opgevraagd en het nieuwe rapport aangemaakt (zonder de gegevens van de eerste dag). Al de volgende dag verscheen er een krantenartikel en kochten veel klanten het product. De dag daarna kwamen de eerste cijfers al binnen en onze stagiair probeerde de gegevens in het SAP-systeem over te zetten. Hier ontdekten we ons tweede Heusden. Het bleek namelijk dat we de verkeerde SAP-tabel gebruikten. Het duurde een paar dagen om deze fout te verhelpen. De CFO kreeg nog steeds zijn rapport, maar in de eerste week kon dat nog niet via SAP gebeuren. Op vrijdag van de eerste week was de stagiair in staat om de gegevens te uploaden. Dat was echter behoorlijk saai werk, dat absoluut niet schaalbaar was. (We hadden enkele duizenden verkopen in de eerste week.) Nu was het tijd voor onze:

Kinderkopjesversie:

Dit keer maakten we het rapport in een CVS-formaat. (Bedenk dat dit vóór XML was.) Elke ochtend ging de ontwikkelaar die als eerste op kantoor aankwam dus naar de webserver, genereerde het rapport en kopieerde het naar een floppydisk. Daarna nam hij de disk mee en uploadde de gegevens naar ons SAP-systeem. Deze versie was beter schaalbaar; ongeacht hoeveel we de dag ervoor hadden verkocht, het werk voor onze ontwikkelaar bleef hetzelfde. Maar ook in deze versie hadden we een klein probleem. Een van de velden was opgemaakt als tekst in plaats van als getal. (Een heel gewone bug.)

Het werk moest elke dag persoonlijk door iemand worden uitgevoerd. Het was niet geautomatiseerd en er werd ook maar één keer per dag een update uitgevoerd (voor de vorige dag).

Toen begonnen de meetings voor de snelwegversie. Aan het eind van zo'n meeting vroeg ik een medewerker van de CFO hoe ze de gegevens gebruikten en of ze tevreden waren met de cijfers. Puur toevallig viel me daarbij op dat de CFO alleen op vrijdag naar de gegevens keek. (Dus niet dagelijks.) Het maakte hem niet eens iets uit dat hij niet op de hoogte was van de volledige verkoopcijfers van de dag of de week.

De snelwegversie:

Gelukkig had ik de volgende dag sowieso een meeting met de CFO en zijn medewerker. We spraken over de voortgang van het snelwegproject en over het feit dat het mensen er eigenlijk van weerhield om aan een ander belangrijk project te werken. Ik stelde beleefd voor om bij de kinderkopjesversie te blijven en het snelwegproject voorlopig op ijs te zetten. Veel mensen in het bedrijf waren daar niet echt blij mee, want ze wilden zo graag aan dat supercoole project werken. De Security Officer was er echter heel tevreden mee, want zo kon de webserver in het beveiligde gebied blijven. Uiteindelijk bespaarde het bedrijf zich zes maanden ontwikkelwerk voor een snelweg die het netwerk in gevaar zou hebben gebracht en niet echt nodig was geweest.

Na enkele jaren kwam ik de CFO weer tegen. Hij gaf toe dat het snelwegproject waarschijnlijk iets te veel van het goede was geweest, want het product had nooit ook maar in de buurt zoveel geld opgebracht als ze voor het snelwegproject hadden moeten uitgeven. Dankzij het grindwegproject konden ze al vrij vroeg ontdekken dat de e-mailadressen van de klanten nog ontbraken, en dat was het beste wat hun kon overkomen. Met die e-maillijst konden ze in de jaren daarna namelijk nog diverse andere services aan de klanten verkopen, en dat behoedde het bedrijf voor een faillissement.

De volgende tekst is afkomstig van de blog van Yves Hanoulle en is door ons naar het Nederlands vertaald.