Steeds vaker krijgen we bij QSM vragen over de voorspelbaarheid van agile en scrum softwareprojecten. Is het mogelijk om ook daar een uitspraak over te doen? Ja, dat kan. Want de weg naar het einddoel ligt bij agile projecten weliswaar niet vast, maar het einddoel zelf in grote lijnen wel. En dat is bepalend voor het vaststellen van de omvang, de doorlooptijd en de kosten.
Iedereen is het eens over de charme van de agile aanpak en de goede samenwerking met de business die daarmee gepaard gaat. Maar anders dan bij de klassieke watervalmethode komt de oplossing op iteratieve wijze tot stand. Hoe kun je dan nog zinvolle voorspellingen doen? Er wordt vaak eendimensionaal gekeken naar functiepunten. Maar dat is een valkuil. Voor een evenwichtige voorspelling moet een project langs verschillende assen worden bekeken. Wij gebruiken bij QSM altijd vijf kernmetrieken die in samenhang worden gewogen: omvang, doorlooptijd, inspanning, kwaliteit en productiviteit.
Geen verschil in aanpak voor projectplan
In feite maakt het voor de validatie van een softwareproject helemaal niet uit hoe het wordt aangepakt. Er zijn altijd requirements, ook bij agile projecten. Weliswaar niet zo gedetailleerd als bij de watervalmethode maar wel voldoende om zinvolle uitspraken te doen over een aantal metrieken. Je weet immers wat er aan het eind van het project moet staan, anders begin je er niet aan. Er zijn verschillende manieren om een huis te bouwen maar de opdrachtgever weet wel altijd op hoofdlijnen wat hij wil. En daarmee is binnen een bepaalde bandbreedte ook goed aan te geven hoe lang de bouw gaat duren en wat het gaat kosten.
Bij agile of scrum softwareprojecten is dat precies hetzelfde. Alleen de vraagarticulatie is anders. Bij watervalprojecten is de vraag vaak: we hebben hier specificaties voor een bepaalde functionaliteit, wat gaat me dat kosten? Bij agile projecten luidt de vraag steeds vaker: ik heb 3.000 manuur beschikbaar, hoeveel functionaliteit kan ik daarvoor maken?
Vooraf goed inschatten met high-level requirements
Op basis van high-level requirements is dat vooraf verrassend goed in te schatten. We doen dat bij QSM op basis van een korte workshop met de klant van twee tot vier uur. Voorafgaand daaraan doen we eerst een intake bij de klant om al iets meer over het project te weten te komen. Om wat voor software gaat het? Is het bedrijfskritische software voor het primaire proces of eenvoudige programmatuur met weinig risico’s? Wil de klant alleen een schatting voor de realisatie- en testfase of ook voor de ontwerpfase? En waar wordt de uitkomst van onze bevindingen voor gebruikt? Voor interne planning, projectplan of om een offerte te toetsen?
Met de verkregen informatie kunnen we doelgericht een workshop in waarbij van klantzijde vaak de product owner en een informatieanalist aanwezig zijn. Gezamenlijk lopen we de requirements door en vinden we ankerpunten om het project goed te kunnen voorspellen. Welke functionaliteit wordt er gebouwd? Wanneer is de business tevreden? Het is geen uitputtende detailsessie maar echt een op high-level.
Projectvoortgang en prognoses
Om de omvang van een project te bepalen, zijn er verschillende methoden mogelijk. Natuurlijk zijn er de functiepunten. Daar wordt wel eens schamper over gedaan maar het zijn wel objectieve, standaard meeteenheden en bovendien ISO gecertificeerd. Dat schept duidelijkheid. Ook storypoints kunnen goed worden gebruikt, maar zijn vanuit dat perspectief niet objectief. Pas gaandeweg het ontwikkeltraject ontstaat in het scrumteam consensus over wat 1 storypoint nu precies is. Toch willen we weten hoe de klant het project zelf in storypoints inschat. Bij tussentijdse bepaling van de voortgang nemen we namelijk meerdere metrieken mee waarvan we weten hoe de voortgang zou moeten verlopen. Dat kan dus op basis van functiepunten, storypoints of uitgeschreven userstories, maar ook op basis van afgeronde testcases en andere bereikte projectmijlpalen. Aan de hand daarvan maken we nieuwe prognoses. Die zullen uiteenlopen maar geven samen wel een verwachting met een bandbreedte waarbinnen het project waarschijnlijk zal blijven.
Benchmarken met 12.000 projecten
Na de workshop gaan we de analysefase in. De ruim 12.000 projecten in de QSM-database, waarvan we omvang, doorlooptijd en inspanning kennen, zijn al statistisch geanalyseerd. De resultaten hiervan gebruiken we om de benodigde inspanning en doorlooptijd in te schatten en aan te geven met welke bandbreedte de klant rekening moet houden. We kunnen dat ook doen met subsets uit de database, bijvoorbeeld alleen voor projecten ten behoeve van vliegtuigontwikkelingssoftware. We hebben voor uiteenlopende deelverzamelingen trendlijnen gemaakt, ook voor agile projecten. Maar natuurlijk kijken we verder.
Rekening houden met beperkingen bij project planning
Heel belangrijk om te weten zijn ook de beperkingen die de klant heeft in termen van tijd, menskracht of budget. Bij het opstellen van projectscenario’s houden we hier rekening mee. We maken projectscenario’s waarmee het project de deadline haalt of binnen het budget blijft. Of we geven aan, in voorkomende gevallen, waarom bijvoorbeeld een deadline niet haalbaar is. Als de klant op 1 januari ‘live’ moet vanwege nieuwe wetgeving, maar wij komen met onze prognoses uit op 1 maart, dan kijken we gezamenlijk hoe we de deadline toch kunnen halen. Een reflex bij projectmanagers is dan vaak om het team groter te maken. De praktijk wijst helaas uit dat projecten daar vooral veel duurder van worden, omdat mensen elkaar dan in de weg gaan lopen. De efficiëntie loopt terug. Daarom adviseren we klanten bij softwareprojecten waar geen keiharde deadline is vaak juist eens wat extra tijd te nemen. Dat pakt goedkoper uit.
Waterval, scrum of agile, het maakt niet uit welke weg u bewandelt, zolang u maar rationeel blijft handelen. Een objectieve en onderbouwde analyse geeft daarbij voldoende houvast.
door: Bert de Vries