IT-projecten uit het verleden hebben, met name bij de overheid, aangetoond dat IV-voortbrenging via de watervalmethode zelden slaagt. Maar lukt het de overheid met agile ontwikkeling wel?
Wie A(gile) zegt moet ook B zeggen”, schreef het Adviescollege ICT-toetsing in december 2023. We vullen de adviezen van AcICT graag aan vanuit een aantal in de praktijk aangetoonde ‘worstelingen’.
1. Werving en beoordeling is niet ingericht op Agile werken
We zien steeds meer Agile teams en rollen ontstaan bij de overheid: Product Owners, Scrum Masters, Release Train Engineers en Business Owners. Maar het wervings- en beoordelingsbeleid, gebaseerd op het Functiegebouw Rijk, is daar onvoldoende op ingericht. Hierdoor sluiten kerncompetenties, die nodig zijn bij Agile softwareontwikkeling, niet aan bij de competenties waarop geworven of beoordeeld wordt. Dit bemoeilijkt de ontwikkeling van medewerkers en hindert daardoor een toename van Agile volwassenheid.
Ons advies: ga pragmatisch om met competenties en kijk vooral naar wat er nodig is in plaats van wat er in de regels staat. Je trekt daarmee de juiste mensen aan die nodig zijn voor een succesvolle uitvoering van het project.
2. Financieringsafspraken en -bronnen sluiten niet aan
Agile softwareontwikkeling vraagt ook om een wendbare financiële structuur. In plaats van vaste (jaar-)budgetten en projectbegrotingen, moet de financiële huishouding vooral rekening kunnen houden met een veranderende omgeving en aanpak. Omdat deze werelden nu vaak niet aansluiten, ontstaat er verwarring en soms zelfs onhandige besluitvorming over financiering van IT-projecten. In sommige gevallen leidt dit tot bezuiniging waar er juist geïnvesteerd moet worden. Of er is nog onvoldoende zicht op de return of investment, waardoor opdrachtfinanciering niet of met veel moeite verkregen kan worden. Tot slot is er vaak sprake van langdurige verbintenissen met leveranciers. In die contracten is niets opgenomen over een Agile projectaanpak en wordt traditioneel strak gestuurd op kosten en doorlooptijd.
Ons advies: ga zo snel als mogelijk in gesprek met opdrachtgevers en leveranciers over de impact van Agile ontwikkeling op de financiële afspraken en stel bestaande afspraken bij als die het toepassen van een Agile projectaanpak belemmeren.
3. Alleen SCRUM is niet genoeg
Veel overheidsinstanties beginnen met een of meerdere SCRUM-teams, met een eigen opdracht. De omvang en complexiteit van overheidsorganisaties zorgt echter voor veel afhankelijkheden tussen teams en afdelingen. Zo zijn veel generieke voorzieningen centraal ondergebracht en/of bij leveranciers belegd. Daardoor is een SCRUM-team zelden in staat om zelfstandig een end-to-end oplossing te realiseren. Daarnaast levert het twee aanvullende problemen op:
- Zolang niet alle IV-teams Agile werken, zullen afhankelijkheden al snel belemmeringen worden. Zo wordt de snelheid van een team geremd door andere, niet Agile teams;
- Om ervoor te zorgen dat alle teams Agile werken, ontkomt de Rijksoverheid er niet aan om scaled Agile te gaan werken met bijvoorbeeld het SAFe model. De uitdaging hierbij is echter dat een volledige Scaled Agile-implementatie jaren kan duren. En er is nog een (flinke) cliffhanger: wat gebeurt er als je een Agile transitie aanpakt als een waterval-project?
Ons advies: ga zo vroeg mogelijk inrichten vanuit een Scaled Agile principe. En zie deze transitie als een kans om direct te ‘oefenen’ met Agile. In plaats van maandenlang vergaderen over hoe een Agile event er precies uit moet zien, is het beter om de standaard op te pakken en hiermee direct te gaan oefenen; een van de belangrijkste uitgangspunten van Agile.
4. Het juiste gereedschap voor de klus
Bij aanbestedingen wordt door veel overheidsinstanties gevraagd om een Agile projectaanpak. In de uitvraag zien we dan toch veel eisen over hoe oplossingen moeten worden aangeboden. In een Agile proces zou de business zich vooral moeten concentreren op de ‘wat’ vraag en de leveranciers op de ‘hoe’ vraag. Overheidsinstanties beschikken vaak ook (nog) niet over een goed CI/CD voortbrengingsproces, terwijl dat wel een voorwaarde is om echt Agile te werken.
Agile projectuitvoering vraagt om Agile gereedschappen. Dat gereedschap bestaat uit twee belangrijke onderdelen: de projectaanpak en de software. In een Agile proces ga je samen met de eindgebruiker om tafel en bepaal je wat het doel is van de applicatie, om vervolgens stap voor stap te ontdekken wat de meest efficiënte weg is naar het einddoel. Aanpassingen tijdens dat proces zijn met de juiste tools, zoals modelleersoftware, eenvoudig te realiseren. Gebruikers zien meteen het resultaat in een echte applicatie en ook in de fase van continu verbeteren (CI/CD) zijn aanpassingen door veranderde wet- en regelgeving of beleid snel en eenvoudig uit te voeren: Show, don’t tell.
Ons advies: Zet bij aanbestedingen in op de manier waarop aanbieders processen ontwikkelen (de aanpak) en de tools die ze daarvoor gebruiken. Kijk vooral naar de mogelijkheden die de tool biedt. De vertaling van die mogelijkheden naar functionaliteit is vooral opdracht voor de Agile teams.
Meer weten?
Over Agile werken of over een goede aanpak van een IT-project bij overheidsinstanties? Neem dan contact op met Hans van Rooij of bel 06 25 26 13 44.
