Software Development is moeilijk

Succesverhalen van de mooiste softwareprojecten, ook wij zijn er niet vies van. Daarom leek het ons goed om ook eens een ander geluid te laten horen. Want software-ontwikkeling is niet makkelijk, er gaat ook echt weleens wat fout. Het goede nieuws is dat je daarvan leert en beter wordt. Persoonlijk, als team en zelfs als klant. In dit artikel geven we praktische adviezen bij de veelvoorkomende problematiek van een agile development-project.

Watervalletjes in een agile landschap

Agile als ontwikkelmethode en Scrum als framework is goed, leuk en praktisch, maar je ontkomt er niet aan om in een vroeg stadium, nog voordat je begint, al helderheid te hebben over zoveel mogelijk onderdelen van het project. Een beetje waterval is soms nodig om de agile aanpak te laten slagen. Je hoeft stories niet in detail al te weten, maar wel zaken als Wat is het stipje op de horizon waar we naartoe werken? Wie is de lead en wie mag beslissingen nemen, op welk vlak en wie is waar verantwoordelijk voor? Een valkuil daarbij is dat er schuttingen ontstaan tussen de verschillende expertisegebieden. In dit geval is communicatie de sleutel, de verschillende expertisegebieden moeten wel met elkaar blijven praten. Een keuze door de designer kan een grotere impact hebben dan alleen de designer kan overzien. Iedereen moet betrokken worden bij het project, maar het moet duidelijk zijn wie de uiteindelijke beslissingen mag maken.

Het is niet zo dat je door Scrum toe te passen ontkomt aan het concept van ‘deadlines’. Het is zelfs zo dat je er meer creëert. Elke sprint heeft namelijk zijn deadline, het einde van de sprint, met software die af moet zijn, volgens de sprintbacklog. Het voelt bijna als vloeken in de kerk, maar Scrum is eigenlijk een serie van kleine watervalletjes. Net zoals de kleine watervalletjes bij vistrappen naast dammen of sluizen.

Transparantie met mate

Openheid is de sleutel tot vertrouwen, toch? Goedlopende, succesvolle projecten slagen dankzij transparantie. Tenminste, transparantie is vaak een mantra in een agile project. En dat is extra als je werkt in een zelfsturende organisatie. Transparantie betekent alleen niet dat iedereen alle details moet weten. Op de hoogte zijn van wat er speelt, is voldoende transparantie.

Als je bijvoorbeeld alle details geeft over een retrospective, dan heeft de klant daar ook een mening over en kun je in een discussie belanden, terwijl de verbeterpunten bedoeld zijn voor het Scrumteam zelf. Het is wel fijn dat de klant op de hoogte is van retrospectives en erbij betrokken wordt zodra een verbeterpunt ook impact heeft op zijn rol als klant. Transparantie is goed, maar met zekere mate.

Niemand is goed in inschatten

We hebben geleerd dat inschatten altijd moeilijk is. In 2018 maakte we onze eigen planning poker deck om inschattingen te doen in Enrise-stijl. Op het doosje hebben we de volgende quote staan.

De achterliggende boodschap: Accepteer dat inschattingen inschattingen zijn. Het worden binnen de agile methodiek niet voor niets story points genoemd; inschattingen horen niet in tijd gedaan te worden, want een story bestaat ook uit complexiteit, onzekerheid en moeite. Story points zijn relatief. Een story met 2 punten is niet 2x zo groot als een story met 1 punt. Vergelijk het met t-shirt maten, een maat L is niet twee keer zo groot als een maat M, slechts groter dan een M. Zo bezien kun je van een inschatting een minder beladen planning maken, met ruimte om flexibel te zijn in de taken die je doet en de tijd die je nodig hebt.

Eerst een stukje fietsen

Met alleen een inschatting op story points ben je er nog niet. Je moet ook weten hoeveel werk het team aankan. Alleen; je weet pas hoe hard je gaat nadat je een stukje hebt gefietst. Wij gebruiken de velocity van het team om te bepalen hoeveel werk er opgepakt kan worden. Velocity moet je bijstellen aan de hand van de voorgaande sprints, want geen enkele sprint is hetzelfde. De velocity per sprint verschilt per samenstelling van je Scrumteam en de beschikbaarheid van de teamleden. Na enkele sprints heb je een gemiddelde velocity en weet je hoeveel werk je met elkaar aankan. Met een gemiddelde velocity kun je de doorlooptijd en eventuele mijlpalen beter bepalen.

Anticipeer op verandering

De glazen bol is een hoax. We hebben ook nog niemand gevonden die de toekomst kan voorspellen. Niemand kan de totale omvang (scope) van een project voorspellen of vertellen hoe het project zich zal ontwikkelen. Precies daarom werken wij volgens de agile ontwikkelmethodiek, zodat je altijd rekening houdt met veranderingen. Aan het begin van een project maken we een magic estimation, een globale inschatting van de scope met de kennis die we nu hebben. Als er iets wijzigt in de scope, geloof ons; dat gaat gebeuren, werk dan met een burn-up-chart, zodat je inzichtelijk kunt maken wat gedaan is volgens afspraak, wat nog moet én wat je extra hebt gedaan in ruil voor de zaken die je had moeten doen. Daarbij is het belangrijk dat het hele team overzicht houdt op scope, zodat je met elkaar de meeste waarde toevoegt aan een project en de juiste (technische) afwegingen kunnen maken.

Aan de hand van een praktijkvoorbeeld laten we zien hoe dat werkt.

Hou vast aan je sprint

Sprints zijn miniprojectjes met een kop en staart. Het is de minimale omvang van een projectdeel om aan te werken en op te leveren. Een belangrijke vuistregel daarbij: verander nooit de inhoud van de sprint nadat deze gestart is. Zodra je binnen een sprint veranderingen aanbrengt of zelfs de scope van die sprint wijzigt, heeft dat direct negatieve gevolgen voor je velocity (zie boven). Dat klinkt natuurlijk logisch, maar als je twee weken bezig bent, dan komt er soms wat om de hoek kijken dat verleidelijk is om op te pakken. Doe het niet! Laat de wijziging voor wat het is. Je team kan ongestoord verder werken en de gevraagde wijziging kan goed voorbereid worden voor opname in de volgende sprint.

Je hebt ook te maken met gebeurtenissen en verzoeken die de voortgang van je sprint verstoren, zogeheten impediments. Impediments zijn verleidelijk om in een sprint op te nemen, maar ze heten niet voor niets impediments. Een impediment blokkeert de voortgang, want je kunt dan niet aan een geplande story werken. Laat de impediments voor wat ze zijn, stuur erop aan dat deze voor de volgende sprint zijn weggewerkt en begin dan aan een sprint zonder impediments.

Kennisdeling met team én je klant

Tijdens een project heb je niet alleen gesprekken in teamverband. Je hebt ze ook 1 op 1, als developers onder elkaar of als developer met een designer of als product owner met een engineer aan klantzijde. Door de sprint 0, de voorbereiding van het scrumproject, met een delegatie te doen zijn de kosten hiervan voor de klant te drukken. Maar als de overdracht naar de rest van het ontwikkelteam niet soepel verloopt ontstaat er een kennisgat dat te kostbaar is om gedurende het project te moeten vullen. Deel wat je besproken hebt met je team. Zo voorkom je dat één persoon afweet van afspraken, die voor de anderen niet bestaan.

Kennisdeling houdt ook in dat je de klant meeneemt in je werkwijze en proces. Agile is relatief nieuw en het gaat in tegen de natuurlijke klantverwachting. Een klant wil vaak zoveel mogelijk waarde voor zo min mogelijk geld. Daar is Agile ook voor bedoeld, maar keuzes maken in scope is niet altijd makkelijk. Het is aan een agile werkend ontwikkelteam om de klant hierin te begeleiden en te helpen.

Conclusie

Software-ontwikkeling wordt door bovengenoemde adviezen niet minder ingewikkeld, het blijft moeilijk. Maar je zult sneller inspelen op problemen en vaker sturen op oplossingen. Er zijn veel factoren waar je mee te maken krijgt en rekening mee moet houden: Communicatie, verwachtingen, veranderingen, nieuwe inzichten en samenwerking. Allemaal belangrijke facetten die de aandacht verdienen bij een digitaal project. Het positieve ervan is dat je razendsnel leert, verbetert en er voor jezelf veel voldoening en plezier uit haalt.