Snel, snel, snel… ?
In de Agile wereld lijkt het wel eens alleen belangrijk zo snel mogelijk nieuwe features en producten op te leveren. Het lijkt of daarbij wordt vergeten dat de waarde van het product pas ontstaat nadat het is opgeleverd.
- Kan het gebruikt worden?
- Kan het beheerd worden?
- Kunnen fouten makkelijk hersteld worden?
- Is het aan te passen als dat nodig blijkt?
Dit soort zaken noemen we bruikbaarheid en beheerbaarheid van het product en dat komt niet vanzelf – daar moet iemand zich hard voor maken.
In eerdere blogs hebben we gezien dat functioneel beheer met verschillende petten in het scrumteam kan zitten. De rol als lid van het ontwikkelteam hebben we al nader bekeken.
In deze blog willen we het hebben over de tweede rol – die van bewaker van de bruikbaarheid en beheerbaarheid.
Vernieuwing is de drijvende kracht van Agile. Aandacht voor documentatie, onderhoud en gebruik is er wel, maar staat niet bovenaan het prioriteitenlijstje. Daar kan functioneel beheer zijn kracht bewijzen. Door ervoor te zorgen dat deze onderwerpen wél de aandacht krijgen die ze verdienen.
Hoe je dat doet? We hebben een paar tips.
Documentatie, zo saai…
Het gebrek aan aandacht voor deze onderwerpen is van alle tijden. In de tijd dat ik zelf nog programmeerde was documenteren ook niet onze favoriete bezigheid en werd het vaak uitgesteld (of afgesteld) tot na de uitrol. Datzelfde gold voor onderhoud als het achteraf structureren van (te) snel gemaakte code. En je kwam zelfs wel eens tegen dat er pas een ontwerp van een systeem werd gemaakt als het al lang in gebruik was en degenen die het hadden gemaakt niet meer in het bedrijf werkten. Daar was zelfs een term voor: reverse engineering.
Zorg voor de beheerbaarheid is niet sexy en wordt om die reden makkelijk op de lange termijn geschoven. En van uitstel komt niet zelden afstel.
Zoals gezegd is dit risico in een Agile omgeving bepaald niet kleiner. De focus op snelheid en vernieuwing maakt dat er nóg minder focus op onderhoudbaarheid en beheerbaarheid ligt.
Gelukkig heeft functioneel beheer wel een aantal handvatten om deze zaken toch onder de aandacht te krijgen. Die handvatten zijn zelfs soms onderdelen van de Agile werkwijze zelf.
Tip 1 – gebruik de Definition of Done
Het eerste wat je kunt doen is de eisen die vanuit beheer aan een oplevering gesteld worden onderdeel maken van de Definition of Done (Dod) – de voorwaarden waaraan voldaan moet zijn om de sprint af te ronden.
Voldoende documentatie, een voldoende doorlopen gebruikersacceptatietest of zelfs opgeleide gebruikers kunnen prima in een DoD worden opgenomen.
Tip 2 – houd rekening met Technical debt
Een begrip wat de laatste tijd in dit verband steeds meer aandacht krijgt is technical debt. En hoewel bedenker Ward Cunningham het vooral heeft over de risico’s van snel bouwen is het begrip ook toepasbaar op andere vormen van uitstel van noodzakelijk werk.
Cunningham ziet technical debt (TD) als een soort hypotheek op je systeem. Kern van de zaak is dat alle inspanningen van het scrum-team in het teken staan van het creëren van businesswaarde en dat kwaliteit een prijs heeft. Gestructureerd programmeren kost meer tijd dan snel iets bouwen. Een ontwerp maken kost nog meer tijd en dus ook geld. Tijd besteed aan onderhoud aan een systeem kun je niet besteden aan vernieuwing of nieuwbouw en dus maak je kosten zonder dat er zichtbare businesswaarde tegenover staat.
Je kunt ervoor kiezen om die prijs niet te betalen, maar dan neem je een hypotheek. Die moet uiteindelijk ook worden afbetaald (want de handleiding gaat er toch een keer komen), maar tot die tijd betaal je ook rente (want het kost de gebruikers meer moeite om het systeem te gebruiken en dus wordt niet de maximale business waarde gegenereerd).
Tip 3 – zorg dat de Product owner een afgewogen risico kan nemen
Technical debt kan een bruikbaar handvat geven aan de functioneel beheerder in zijn rol van hoeder van de beheerbaarheid. De functioneel beheerder in het scrumteam is (in die rol) de hypotheek adviseur, die zijn klant (de product owner) wijst op de voor- en nadelen van wel of niet afbetalen.
Zodat de product owner een weloverwogen afweging maakt of er tijd vrijgemaakt moet worden voor onderhoud of niet.
