Op maandag 17 september was er een bijeenkomst van Agile Overheid, een groepje gelijkgezinden die zich bezig houden met, je raadt het al, Agile in de Overheid. Niet per sé beperkt tot Agile ontwikkeling overigens, er zijn er ook die zich met Agile beleid, Agile beheer en Agile architectuur bezig houden om maar iets te noemen.
Op maandag ging de bijeenkomst over “Agile en contracten” en ik was er bij. Na een introductie op wat Agile en Scrum ook al weer is (nog een keer?), waren er twee presentaties. De eerste van Edwin de Vries van Concretor, die heel veel ervaring (aan overheid en aan leverancierskant) heeft met aanbestedingen. Hij beschreef eigenlijk een aantal stadia die veel van zijn klanten meemaakten, die buitengewoon herkenbaar waren:
1. fixed price, fixed date inkopen op basis van vastgesteld functioneel ontwerp: je loopt daar aan tegen het feit dat gebruikers van te voren moeilijk kunnen definiëren wat ze precies willen en dat er vrijwel altijd voortschrijdend inzicht is tijdens de ontwikkelfase. Het blijkt moeilijk om de vraag vooraf zo helder te maken dat de aanbesteding binnen de gestelde voorwaarden tot een succes leidt. Bovendien koop je altijd 1 “ding” in, waarbij de afstemming met de omgeving weer moeilijk wordt
2. Organisaties die veel (ICT) inkopen gaan vaak over naar het inkopen van een proces, in de vorm van mantels of een ontwikkelstraat: daarmee is beter geborgd dat bestaande en nieuwe ontwikkelingen op elkaar kunnen worden afgestemd, maar de grip op een ‘vast resultaat voor een vaste prijs’ valt deels weg. We werken nog steeds waterval en het blijft moeilijk om van te voren goed aan te geven wat je wil; het voortschrijdend inzicht kan nog steeds moeilijk worden verwerkt.
Belangrijk is ook de mentaliteit van de gebruiker bij bovenstaande stadia: die heeft de neiging om alles te vragen, want “misschien hebben we het nog eens nodig en als ik het nu niet vraag krijg ik het nooit”. Maar: inkooptechnisch is het goed te doen, binnen de geldende regels.
Langzamerhand beginnen steeds meer “demand” organisaties en gebruikers te vragen om Agile, omdat ze daar goede verhalen over hebben gehoord. De inkoper vraagt zich dan af: hoe kan ik dit inkopen, waarbij er ook weer stadia volgen:
1. mensen inhuren: via mantels of andere constructies huur je individuele mensen in, of een team. Inkooptechnisch goed mogelijk, maar je moet wel zelf de regie houden over het proces en de randvoorwaarden om dat proces te laten lopen. Bij LRK zitten we eigenlijk in die situatie, waarbij we heel veel grip hebben op het proces, maar tegelijkertijd ook zelf de verantwoordelijkheid overal over houden, tot en met de werkplekken toe.
Kenmerk van Agile is dan dat je veel meer samenwerkt tussen opdrachtgever en project en daardoor in de “co-creatie” samen verantwoordelijk bent. Inkooptechnisch al weer moeilijker.
2. een proces inhuren: dit is waar veel overheidsorganisaties nu mee bezig zijn: hoe kan ik Agile werken, daarbij een groot deel van de verantwoordelijkheid en regie bij de markt neerleggen, maar toch nog enige grip houden op het resultaat.
Hier ontstond (natuurlijk) veel discussie. Want als je van tevoren geen vast functioneel ontwerp vastlegt en je geeft zelfs toe dat dat nog wel eens kan veranderen in het traject; wat kun je dan wel vast leggen?
De antwoorden wisselden; een aantal dingen kun je zeker van tevoren vastleggen:
– een projectstartarchitectuur, waarin in ieder geval de richting van een oplossing duidelijk is
– randvoorwaarden voor het “agile proces” dat je gaat doorlopen met de leverancier
– de kwaliteit van de code (bijvoorbeeld in de aanbesteding van DigiD: minimaal 4 sterren SIG)
– een timebox van tijd en geld
– non-functionele eisen (bijvoorbeeld performance of beveiliging)
– èn: de uitkomst van de sprints. Alhoewel je niet weet wat of hoeveel je precies kan realiseren in een sprint kun je wel garanderen dat je aan het einde van de sprint werkende en geteste software hebt.
De discussie ging nog wat verder maar ik bleef met de vraag zitten: Wat koop ik precies in als ik Agile wil uitbesteden:
– een aantal mensen of zelfs een heel team?
– een ontwikkelproces?
– een aantal functiepunten die nader ingevuld mogen worden?
Het staat of valt met goede mensen en vertrouwen onderling, zie dat maar eens in een contract vast te leggen.
Misschien is “Prestatie-inkoop” daar wel een antwoord op. Collega Anja Smorenburg vertelde daar laatst over en op de Agile Overheid bijeenkomst was daar Sjoerd Posthuma, die het ook ter sprake bracht. Prestatie-inkoop, ook wel best value procurement, is een (aanbestedings-)proces, waarin je in een aantal stappen tot gunning komt. Dat is op zich normaal, maar in dit proces krijgt de leverancier de kans om een groot deel van de aanpak in te vullen en mee te denken over het resultaat. Dat is een hele andere benadering dan een dik Pakket van Eisen maken, waar alle leveranciers dan braaf exact mogen doen wat er staat en niet de kans krijgen hun eigen kennis in te brengen (totdat er voortschrijdend inzicht is of tegenstrijdige functionaliteiten boven komen..). Er is net een boek over verschenen, toepasselijk genaamd “Prestatieinkoop“. Maar eens lezen!
Er was overigens ook een uitstekend verhaal van Rini van Solingen en Paul Weghorst van Prowareness, die op zeer enthousiaste wijze het hoe en waarom van Agile werken nog eens toelichtten en dat zeer deskundig ook afzetten tegen de klassieke waterval-aanbesteding. Dat mocht ook wel trouwens want Rini is deeltijds verbonden aan de TU Delft voor een leerstoel over software-ontwikkeling en Paul Weghorst was jarenlang verantwoordelijk voor aanbestedingen bij Ordina.