De Rechtspraak werkt Agile. De enige manier om hét grote strategische programma Kwaliteit en Innovatie (KEI) succesvol te kunnen realiseren. Met een groep ontwerpers, bouwers en testers die in multidisciplinaire teams samenwerken aan één doelstelling: de digitalisering van de rechtspraak.
De rechtspraak in Nederland verandert ingrijpend de komende jaren. Het veelomvattende verander- en moderniseringsprogramma KEI moet de rechtspraak toegankelijker en begrijpelijker maken door middel van innovatie en digitalisering. Hiertoe dient de ICT van de rechtspraak volledig te worden vernieuwd.
De rechtspraak heeft de afgelopen twee jaar een transitie van een traditionele waterval-softwareontwikkeling naar agile/scrum gemaakt. In dit artikel nemen wij u mee in deze transitie vanuit een bestuurlijke invalshoek waarbij vragen spelen als: ‘Wanneer start je met een agile manier van werken, hoe schaal je op, hoe doe je een agile transitie en behaal je ondertussen ook resultaten in je project/programma.’ Ook de vraag: ‘Hoe houd je de opdrachtgever tevreden als er op bestuurlijk niveau op de ‘oude’ manier verwachtingen leven en beloftes zijn gedaan wat betreft resultaat, doorlooptijd en kosten’, komt daarbij aan de orde.
‘Er zijn geen shortcuts, je moet alles meemaken’
De belangrijkste ervaring die wij u mee willen geven is dat er geen manier is om zonder fouten een grootschalige transitie naar agile werken te maken. Fouten maken én daarvan leren is een belangrijk principe van agile. Van fouten fouten kun je leren. Wij behandelen vijf fouten die u moet maken om succesvol te zijn. Probeer daarom deze fouten tijdens uw transitietraject niet te voorkomen maar herken ze tijdig en omarm deze in het licht van de agile principes als een noodzakelijke stap naar agile volwassenheid.
De vernieuwing van de rechtspraak
Rechtspreken in Nederland is momenteel een proces waarbij dossiers op papier worden opgebouwd en daarna wordt bepaalde informatie in digitale systemen vastgelegd. Eind 2012 werd het programma Kwaliteit en Innovatie (KEI) geïnitieerd binnen de rechtspraak, waarmee wordt gewerkt aan modernisering van de rechtsgang. Het zal de rechtspraak toegankelijker maken voor de rechtzoekenden en de rechtspraak bij de tijd houden.
Dit betekent ook dat er een landelijke uniformering gaat plaatsvinden in de werkprocessen, terwijl rechtbanken en rechters een grote mate van autonomie kennen met als gevolg een grote diversiteit aan processen. Dat maakt de rol van de product owner (degene die vanuit de opdrachtgever het mandaat heeft om de scope, functionaliteit en prioriteiten te bepalen) binnen de rechtspraak cruciaal en uitdagend.
Spir-it en KEI
Spir-it is de ICT service provider voor de Rechtspraak in Nederland en realiseert ICT-oplossingen voor de gehele Rechtspraak in Nederland: het beheer, onderhoud en support van alle netwerken en applicaties van de rechtspraak. Dit zijn bijna 12.000 werkplekken en meer dan 400 applicaties. Samen met zo’n 500 collega’s zorgen wij ervoor dat medewerkers van de rechtspraak hun dagelijkse werk kunnen doen.
In 2012 werd het programma Kwaliteit en Innovatie (KEI) geïnitieerd binnen de rechtspraak. KEI is het verander- en moderniseringsprogramma van de rechtspraak. Hiermee wil de rechtspraak voldoen aan zijn speerpunten om snelle, toegankelijke en deskundige rechtspraak te leveren. Om aan deze doelstelling te kunnen voldoen wordt ingezet op verregaande digitalisering. Een logische stap, niet alleen voor gebruikers van de rechtspraak zoals advocaten en deurwaarders, maar ook voor de medewerkers en de ketenpartners (bijvoorbeeld het Openbaar Ministerie of de advocatuur) van de rechtspraak. KEI is echter niet alleen een digitaliserings- en automatiseringsproject. Processen worden binnen de rechtspraak vereenvoudigd en geüniformeerd. Ook is er is een wetgevingstraject nodig om de verplichte digitale procesgang voor professionele procespartijen mogelijk te maken, moeten medewerkers opgeleid worden en, last but not least, betekent dit ook een reorganisatie binnen de rechtspraak. Over een aantal jaar (met uitzondering voor burgers die niet digitaal willen procederen) zijn er geen nieuwe papieren dossiers meer te zien, worden processen digitaal gestart, zijn de dossiers (inclusief archivering) digitaal, wordt er digitaal gecommuniceerd en zittingen gepland en dat alles met inachtneming van alle eisen op gebied van security en privacy.
Waarom agile en waar beginnen?
Bij de initiatie van KEI hebben we gekeken naar een haalbare aanpak voor de realisatie van de ICT. We streefden ernaar om te komen tot één integraal rechtspraakinformatiesysteem dat voor verschillende rechtsgebieden inzetbaar zou zijn. De processen voor Civiel- en Bestuursrecht zijn meer op elkaar afgestemd, waardoor dit voor deze rechtsgebieden haalbaar werd. Vanuit spir-it is het voorstel gedaan om het nieuwe ICT-landschap op te zetten op basis van een servicegeoriënteerde architectuur (SOA) en er is een keuze gemaakt om dit te realiseren met tooling van leverancier Oracle, in combinatie met Microsoft voor de portalen (de zogenoemde buitenkant).
Voor KEI dienen nieuwe proceswetten te worden opgesteld en het was vooraf nog niet duidelijk hoe de nieuwe digitale processen eruit zou gaan zien. Voor de rechtspraakmedewerkers is een digitale werkwijze met zaaksturing een grote stap en het is moeilijk om functionele wensen te beschrijven als ze nog niet goed weten hoe ze later moeten werken. Volledige functionele specificaties opstellen is dus niet mogelijk. Daarmee is een traditionele watervalaanpak ongeschikt. We hebben dit inzicht samen met de programmadirectie van KEI ontwikkeld. En ook voor hen werd duidelijk dat een agile aanpak een goed alternatief was. Ondanks het feit dat zij er nog geen ervaring mee hadden.
We zijn samen met hen op zoek gegaan naar een geschikt proces om als eerste te gaan digitaliseren met als gedachte de scope stukje voor stukje te gaan realiseren en te implementeren. Deze implementatie zou er dan toe leiden dat we een deel van een proces vernieuwen, maar dat een ander deel bijvoorbeeld nog via een oud systeem loopt, of eventueel (nog) handmatig wordt gedaan. We hebben gemerkt dat dit ‘omdenken’ in de praktijk erg lastig is. Er is weerstand om met iets kleins live te gaan. Er zijn immers altijd wel argumenten te vinden om dit niet te doen.
Het belangrijkste argument om het wél te doen, is het ontwikkelen van een feedbackloop: door het (deel)systeem te gebruiken, ontwikkelen gebruikers inzicht in de mogelijkheden en zijn zij beter in staat om mee te denken. Elke twee weken worden kleine stukjes functionaliteit opgeleverd, die aan de gebruikers worden getoond en hun feedback wordt verwerkt in een volgende oplevering. Deze manier van werken geeft ook de ICT-organisatie de mogelijkheid om ervaring op te doen met het gebruik van bepaalde (vaak nieuwe) technologie en werkwijzen. De ervaringen worden omgezet in verbeterpunten voor de rest van het traject. Door dit continue toe te passen, kan het proces en het product telkens verbeteren.
Bestuurlijk gezien even wennen, want we willen toch graag vooraf precies weten wat we krijgen voor ons geld.
Fouten maken moet!
De essentie die in de vorige alinea wordt beschreven is ‘learning by doing’. Er zullen ‘agile-puristen’ in uw organisatie rondlopen die alle best practices op zak hebben, weten hoe het moet en u willen behoeden voor fouten. Onze ervaring is dat u deze puristen dient af te remmen omdat u er echt zelf doorheen moet. U herkent de valkuilen en de best practices niet.
Denk in kleine stapjes, ga aan de slag, leer van de fouten, evalueer ze en maak afspraken over structurele verbeteringen om ze in het vervolg te voorkomen. Op deze manier creëert u ook echte business- en gebruikersbetrokkenheid. Als dat lukt, dan bent u weer een stapje verder in de ontwikkeling van uw organisatie.
Dory Reiling, rechter en product owner voor KEI:
‘Fout is goed!’
Binnen een agile aanpak is er ruimte voorzien voor het evalueren en leren. De neiging bestaat, vooral bij management en bestuurders, om de tijd die hieraan wordt besteed als ‘veel en duur’ te zien. En dan slaan we dat maar eens een keer over. Doe dit niet: sta de organisatie toe om fouten te maken en ervan te leren. Zie er wel op toe dat de gemaakte verbeterafspraken focus krijgen en daadwerkelijk worden toegepast.
Schaalbaarheid vanaf de start
Als er in uw organisatie met meer dan tien (multidisciplinaire) ontwikkelteams aan dezelfde producten wordt gewerkt, dan gaat u te maken krijgen met schalingsvraagstukken. Aan de ene kant dient u op te schalen omdat dit nodig is om de doelen te bereiken, maar de kans is groot dat er ‘een afnemende meeropbrengst’ ontstaat. Dit komt omdat kennis, ervaring, processen en hulpmiddelen ontbreken. Het kost tijd om uw agile organisatie te ontwikkelen maar die tijd heeft/krijgt u eigenlijk businesswise niet. Hierdoor heeft u bijvoorbeeld nog geen werkwijze en tooling geïmplementeerd voor geautomatiseerd testen en/of voor het op een geautomatiseerde wijze in productie brengen van software. Dit betekent dat er voorlopig handmatige handelingen nodig zijn. Hoe meer teams er dan zijn, hoe complexer dit wordt en hoe groter de kans op fouten.
Wij vergelijken, als metafoor, onze agile-transitie regelmatig met een reis. Rechter Guus en zijn vrouw Dory (ook rechter) gaan als cadeau voor hun oudste dochter Iris drie weken met haar op vakantie. Ze willen voor het eerst buiten Nederland op vakantie. Hun doel is een zonnige vakantie, maar ze weten nog niet precies waar ze zullen uitkomen. Ze plannen samen met Iris de eerste delen van de route. Waar ze precies uitkomen, laten zij afhangen van een aantal omstandigheden.
Op de dag van vertrek blijkt er een wegafsluiting op onze geplande route, met grote files. We besluiten deels een andere route te nemen. Op onze route in Frankrijk vindt onze dochter de omgeving zo mooi, dat zij aangeeft via de Route National te willen reizen. Door deze keuze gaat het minder snel, maar de wijze van reizen is voor haar belangrijker dan de snelheid. Halverwege de route plannen we het volgende traject meer concreet. Zij wilde graag naar de kust van Zuid-Frankrijk, maar daar blijkt het slecht weer. Aangezien ons doel is om een reis naar de zon te maken, herplannen we de route en buigen af naar Italië. Zij geeft aan weer via de snelweg te willen reizen, om op die manier verder naar het zuiden uit te komen en meer zeker te zijn van zonnig weer. Bij Milaan besluit ze dat we naar Toscane gaan en niet naar Venetië, omdat het weer daar beter is. Na enkele dagen reizen bereiken we ons doel: een zonnige vakantie. Niet in Zuid Frankrijk, maar in Italië.
Er zijn diverse scaling frameworks in de markt (SAFe, LeSS, Spotify model van Kniberg, 5+1, etc.). Laat u voorlichten over de essentie van de verschillende frameworks en maak een keuze uit één ervan, of haal elementen uit enkele ervan. Als uw organisatie aan de geschetste typering voldoet, begin hier dan al direct mee, ook al onderkent u misschien op dit moment nog niet het belang ervan.
Samen aan het stuur
Wanneer de druk oploopt, veelal omdat mijlpalen dichterbij komen, moet er gestuurd worden op tijd, geld en scope. Opdrachtgevers zijn geneigd om alle variabelen vast te zetten en dan is er geen ruimte meer om te sturen. Het enige waar je dan eigenlijk nog aan kunt tornen, is aan de kwaliteit van het opgeleverde product, maar dat wil natuurlijk niemand. Dit krijg je immers in beheer als een boemerang terug, door grote hoeveelheden incidenten en ontevreden gebruikers.
Ons advies luidt: neem de business mee, kijk samen vooruit en maak samen een planning. Dit bestaat dan vooral uit de beoogde businessdoelen, business value, de oplossingsrichting, het budget en de planning. Stuur vervolgens gezamenlijk op de resultaten van de korte termijn (werk bijvoorbeeld zes sprints vooruit de werkvoorraad goed uit in een geprioriteerde backlog; dit ligt vooral bij de product owners en de ontwikkelteams). Blijf uw doelen bewaken, maak keuzes in het licht van die doelen, en gaandeweg bent u steeds beter in staat om gezamenlijk te besturen. Ontwikkel hiervoor ook relevante stuurinformatie om daarbij te ondersteunen.
Waardeer de rol van product owner in uw organisatie
De rechters die binnen KEI de rol van product owner op zich hebben genomen, zijn al vaker betrokken geweest bij vernieuwingstrajecten met een grote ICT-component. Een deel van hun tijd werken zij op de vloer samen met de ontwikkelteams, maar ze spreken ook nog enkele dagen per week recht. Het is een pittige rol om je collega-professionals te vertegenwoordigen. Zeker in een organisatie als de rechtspraak waar autonomie van de rechter een grondbeginsel is en waar per rechtbank en per team veel lokale zeggenschap is. Zij hebben een duidelijke visie op waar het naartoe moet binnen KEI en hoe er meer uniformiteit bereikt kan worden. Het is belangrijk dat zij nog wel steeds door hun collega’s gezien worden als collega’s die hen kunnen vertegenwoordigen en niet volledig opgaan in het project. Het organiseren van een goede achterban is noodzakelijk, bestaande uit verschillende gebruikerstypen en organisatieonderdelen. Houd regelmatig demo’s, ook voor bredere gebruikersgroepen en zorg dat op deze manier de verwachtingen worden gemanaged.
Het blijft een uitdaging om goede product owners (PO’s) uit de organisatie te krijgen. Het is een cruciale rol in dit soort verandertrajecten. Wat doet u eraan om de rol van PO ook vanuit uw bestuurdersrol serieus te nemen? Hoe stimuleert u mensen uit uw organisatie om deze cruciale taak op zich te nemen? Eén van de opties is om er een carrièrepad van te maken in uw organisatie.
Verantwoording en control
De voordelen van agile werken waren voor de ontwikkelteam en betrokken gebruikers direct duidelijk. Maar de wereld buiten het programma moet nog wel even wennen. In een traditionele omgeving met projectplannen, jaarplannen en jaarbudgetten, change procedure en strakke verantwoordingslijnen over tijd, geld en vooral scope ziet de agile-wereld er soms uit als een stel hippies die roepen: ‘Geloof ons nou gewoon. Geef geld en het komt goed’. Ook agile kent een verantwoordingsplicht.
Vrijheid en discipline
Een belangrijk aspect in grootschalige omgeving is de balans tussen vrijheid en discipline. Aan de ene kant heeft een agile-aanpak het in zich om te experimenteren en te beginnen. We zien wel waar we uitkomen. Met zelfsturing laag in de teams belegd. Aan de andere kant gaat het (zeker in een grootschalige omgeving) over discipline en centrale aansturing. Er dienen immers producten opgeleverd te worden waarin een bepaalde mate van herkenbaarheid en uniformiteit zit voor de gebruikers en uw beheerorganisatie heeft ook haar eisen.
In grootschalige omgevingen zullen er meer centrale afspraken gemaakt moeten worden. Faciliteer dit proces om met betrokkenheid van de mensen zelf tot afspraken te komen. Ook over hoe zij daarbij de kwaliteitsborging willen inrichten.
Geniet van uw tocht naar de zon!
Wij hebben de afgelopen twee jaar bij vlagen vergeleken met een rit richting de zon. De eerste etappe was spannend en eng. Hoe vaker we etappes aflegden (een nieuwe sprint of een nieuw project), hoe beter het ging, hoe eerder we de files en omleidingen aan zagen komen, tijdig konden bijsturen, keuzes konden maken en succesvol waren. We hebben ook vooral erg genoten van deze reis en het heeft spir-it en de rechtspraak veel goeds gebracht. Onze organisatie heeft in twee jaar tijd een grote ontwikkeling doorgemaakt. De samenwerking tussen business en ICT is verbeterd en er is veel wederzijds inzicht en begrip ontstaan. De medewerkers hebben de agile aanpak omarmd en willen niet meer terug naar de traditionele aanpak. Mensen die onze organisatie bezoeken, valt op hoe gedreven en trots onze medewerkers zijn over hun werk en de organisatie. Met als belangrijkste resultaat dat wij op dit moment op weg zijn om het ambitieuze KEI-programma op een agile manier te ontwikkelen en de mijlpalen te behalen!
Het kan zijn dat u toch nog denkt: moet ik hier wel aan beginnen? In een aantal gevallen is de huidige/oude aanpak gewoon niet geschikt. De zekerheden die in deze aanpak lijken te zitten, blijken vaak geen zekerheden. Het rapport van de commissie-Elias heeft dat ook wel duidelijk gemaakt. Dan is het een goed alternatief om voor een flexibele en dynamische agile aanpak te kiezen. Als u nog twijfelt, dan nodigen wij u graag uit om eens een kijkje bij ons te komen nemen.
Irene Tiepel is als directielid van spir-it verantwoordelijk voor demand management en software development en ook verantwoordelijk voor de agile transitie die binnen spir-it wordt uitgevoerd.
Frank Kist is (agile) manager en transitiecoach binnen Axis into Management. De afgelopen 3 jaar heeft hij binnen spir-it op interim basis een lijnmanagementrol vervuld. Hij was één van de initiatiefnemers voor de agile aanpak en maakte deel uit van het agile transitieteam.
Henri Peters is partner bij Aresz. Henri vervult is binnen spir-it agile projectmanager van grote strategische projecten binnen de rechtspraak. Samen met Frank was hij één van de initiatiefnemers voor de agile werkwijze en hij vervulde een belangrijke rol tijdens de agile transitie.
