Aanbesteden kán een beetje agile

BIT-regel nummer 8: ‘Faseer de ontwikkeling van het ICT-project zo efficiënt mogelijk en probeer daarbij per fase direct bruikbare producten op te leveren. De agile methode is een vorm die fasering van projecten kan bewerkstelligen.’ De Commissie Elias schrijft tien regels voor het nieuwe Bureau ICT Toetsing en slechts één ervan gaat – in een bijzin – over agile werken. Terwijl veel bedrijven die aanpak inmiddels vanzelfsprekend vinden.

Succesvol aanbesteden valt niet mee, zeker als het om ICT gaat – de commissie-Elias bevestigde dat weer eens. Projectleiders, inkopers, juristen en aanbieders moeten manoeuvreren tussen regels, argwaan, complexiteit en onbegrip. ‘In kort bestek’ is een verzameling artikelen (gebundeld in iBestuur magazine nr 15 dat eind juni op de mat valt) waarin iBestuur een poging doet die aspecten te duiden, onder redactie van Ruud Leether en Peter van Schelven, beiden juridisch adviseurs met veel aanbestedingservaring. De artikelen gaan in op de ‘juridisering’, inkoopvoorwaarden, integriteit, Best Value Procurement, de nieuwe EU-richtlijnen, de agile aanpak en innovatie als voorwaarde.

Begin jaren negentig van de vorige eeuw werd door een aantal geestverwanten geconcludeerd dat de ontwikkelingen in de IT de verkeerde kant op gingen. Zij beschreven een alternatief in het Agile Manifest (www.agilemanifesto.org). Het bevat vooral een aantal waarden en principes, op basis waarvan methoden voor softwareontwikkeling zijn uitgewerkt. Wat precies wel of niet een agile werkwijze is, is niet eenduidig te bepalen. Scrum wordt, als meest genoemde en toegepaste agile methode, vaak als referentie genomen. Er zijn echter organisaties waar het agile-gedachtegoed zo extreem is toegepast dat velen het niet eens als zodanig zouden herkennen (Google, Valve). Agile werken is niet zozeer een kwestie van een specifieke methode toepassen, maar meer een graduele schaal – meer of minder passend in de geest van de agile waarden.

Feedback

Als we er niet op vertrouwen dat een project goed gaat verlopen, proberen we in de traditionele (niet-agile) aanpak om vóóraf alle risico weg te nemen. Er zullen gedetailleerde ontwerpen, plannen en afspraken worden gemaakt. Tijdens de uitvoering vormen afwijkingen ten opzichte van die plannen per definitie een risico. Afwijkingen worden dus niet geduld. Agile werkwijzen vertrouwen daarentegen vooral op feedback. Men zal al snel vinden dat het onrealistisch en onverstandig is om vooraf alle risico’s weg te analyseren. Er zijn gewoonweg te veel factoren om volledig te kunnen overzien. Gedisciplineerd werken lost dit probleem op. Alles wat belangrijk is, wordt het eerst gerealiseerd, moet direct aantoonbaar (door tests en/of demonstraties) een verbetering opleveren en moet aantoonbaar aan alle kwaliteitsnormen voldoen. Agile methoden gaan ervan uit dat zelfs een klein systeem waarschijnlijk dusdanig complex is dat je het maar beter voorzichtig, stapje voor stapje, kunt aanpakken. Traditionele methoden gaan ervan uit dat geen enkel systeem te groot is om volledig en tot in detail vooraf te kunnen ontwerpen en plannen. Heeft de commissie-Elias niet aangetoond dat die hooghartigheid elke keer weer fataal is?

De kleinst denkbare zinvolle oplossing zou de maat van de aanbesteding moeten bepalen

Bij het ontwikkelen van systemen is het eigenlijk vanzelfsprekend om op een agile manier te werken. Hoe die agile werkwijze er precies uitmoet zien, is afhankelijk van zowel de organisatie als de te bouwen systemen. Voor een transitie naar agile werkwijzen moet wel de tijd genomen worden. Die tijd is niet zozeer nodig om de nieuwe werkwijze aan te leren – die is eenvoudig – maar vooral om de oude werkwijzen, mechanismen en reflexen af te leren.

Hamvraag

Wanneer systemen niet zelf gebouwd, maar aanbesteed worden, is een agile werkwijze veel minder vanzelfsprekend. Aanbesteding is een vorm van feed-forward, van vooraf precies bepalen wat er moet gebeuren. Daarmee wordt de kern van agile werken geraakt. Er kan in een aanbestedingstraject geëist worden dat de leverancier op een agile manier werkt, maar wat is de waarde daarvan als alle details van tevoren al zijn vastgesteld of als ‘voortschrijdend inzicht’ gezien wordt als een gewijzigde opdracht (waardoor de aanbesteding opnieuw moet)? De Commissie Elias stelt: “… dat de rijksoverheid vooral onvoldoende gebruikmaakt van de ruimte en flexibiliteit die de huidige aanbestedingsregels wel degelijk bieden.” Best Value Procurement (BVP) wordt vaak genoemd als werkwijze die dergelijke ruimte – en daarmee agile werken – mogelijk zou maken. Ook bij BVP is het de bedoeling dat er aan het eind van het inkooptraject wel degelijk een plan afgesproken is om de uitvoering van het project te sturen. De inkoop biedt dan wel ruimte en flexibiliteit, de uitvoering verloopt nog steeds volgens een gedetailleerd plan en contract.

Aanbesteden gaat dus zeer lastig samen met specifieke agile methoden als Scrum. Daarmee is het nog steeds zinvol om vanuit de agile-waarden en -principes op zoek te gaan naar de beste manier om een aanbestedingsproject uit te voeren. De volgende regels kunnen daarbij helpen:

• Houd de opdracht zo klein mogelijk. De kleinst denkbare zinvolle oplossing zou de maat van de aanbesteding moeten bepalen.
• Eis vroege en regelmatige demonstraties (en betrek daar zo veel mogelijk mensen bij). Hoewel er waarschijnlijk maar beperkte ruimte is om aanpassingen door te voeren, vergroot dit wel het draagvlak en wederzijds begrip.
• Eis dat het systeem zo vroeg en zo veel mogelijk geautomatiseerd wordt getest en laat de ontwikkelomgeving, de testopstellingen en testscripts onderdeel zijn van de oplevering.
• De simpelste oplossing voor een probleem is altijd de beste oplossing. Dit geldt zowel voor de aanbesteder als voor de leverancier. De aanbesteder moet één helder doel voor ogen hebben met zo min mogelijk randvoorwaarden en architectuur- en technologie-eisen. De leverancier moet de opdracht krijgen om met zo min mogelijk (nieuwe) technologie het probleem op te lossen.