Agile staat als software ontwikkel aanpak behoorlijk in de belangstelling en is bijna niet meer weg te denken. De voordelen worden door velen gezien en omarmd. Maar agile kent ook uitdagingen en roept soms vragen op. Afgelopen week werd ik met zo’n vraag geconfronteerd, te weten “hoe koop je nu eigenlijk agile projecten in”. De vraag kwam uit een instelling die alles volgens de Europese aanbestedingsregels moet inkopen.
De kerngedachte achter de Europese aanbesteding is dat door het aanhouden van objectieve criteria iedereen een eerlijke kans maakt op de opdracht. Geen vriendjespolitiek of achterkamergekonkel maar eerlijke en open aanbiedingen en gunning volgens objectieve criteria. De werkwijze van huidige aanbestedingstrajecten botsen op twee belangrijke punten met een Agile aanpak. Ten eerste probeert men contractueel de volledige scope dicht te timmeren, terwijl men bij een Agile aanpak kiest voor een timebox aanpak waarbij, rekening houdend met voortschrijdend inzicht, in de vastgestelde tijd zoveel mogelijk business waarde wordt gerealiseerd.Ten tweede vergt de Agile aanpak commitment van de opdrachtgever om deel te nemen aan het ontwikkelproces en daarin verantwoordelijkheid te nemen.
Laten we ervan uitgaan dat de opdrachtgever hiervan doordrongen is en bewust een keuze wil maken voor een partner die de oplossing volgens een agile aanpak wil realiseren, op basis van welke criteria moet deze keuze dan gemaakt worden? Het uurtarief als criterium valt al snel af. Hoe lager het uurtarief, hoe meer uren er weliswaar gewerkt kan worden aan het creëren van business waarde, maar er bestaan. enorme verschillen in productiviteit tussen teams. En dan praat ik niet over een paar procenten, maar eerder over factoren verschil.
Nou heb ik het verleden nog wel eens op basis van de Rapid Application Development methode aanbiedingen gemaakt. Hierbij werd dit probleem van objectiviteit omzeild door een objectieve functiepunten telling en een prijs per functiepunt af te spreken.Hier waren immers industrie standaarden voor en onafhankelijke partijen zouden de uitkomsten kunnen verifiëren. Bij agile wordt er gebruik gemaakt van story points. Dat lijkt wellicht in eerste instantie behoorlijk op functiepunten, maar dat is maar uiterlijke schijn. Story points worden niet door de aanbesteder bepaald maar door een bouwteam. Ze zijn een inschatting van de hoeveelheid werk relatief ten opzichte van een team specifieke maat. Ze zijn dus niet overdraagbaar en kunnen door een onafhankelijke partij dan ook niet getoetst worden.
Rest volgens mij niets anders dan de aloude intake maar weer van stal te halen. In dit geval niet de intake van individuen, maar een intake van het team. De opdrachtgever zal dan een keus moeten maken uit teams van diverse aanbieders en op basis van met name subjectieve criteria zoals gevoel een inschatting en een keus moeten maken welk team het beste resultaat gaat opleveren.
Binnen agile is het verstandig om na ongeveer 20% van het totaal budget een oplevering te plannen. Dit geeft de organisatie de kans om het opgeleverde in gebruik te nemen en de voordelen te verzilveren. Voor inkoop is dat een ideale mogelijkheid om de kwaliteit van dienstverlening te evalueren om te bepalen of alles binnen de grenzen van redelijk vakmanschap verloopt. Zo niet is er nog alle kans om de gemaakte keuze te herzien en zonder al teveel schade het project een doorstart te geven. Hiermee krijgt inkoop een rol die moeilijker meetbaar is, maar waarschijnlijk meer waarde oplevert. Het inkoopproces helemaal objectief maken is een utopie die gezien de vele rechtszaken van ontevreden verliezers op dit moment ook niet gehaald wordt.
De grootste uitdaging ligt voor opdrachtgevers echter in het omarmen van agile, en daarmee verantwoordelijkheid nemen in de realisatie. De voordelen zijn duidelijk, maar je moet er wel wat voor doen. De wendbaarheid van de opdrachtgever zou wel eens de grootste succesfactor kunnen zijn, waarbij ook inkoop zijn wendbaarheid zal moeten tonen.
