ICT uitdagingen bij agile softwareontwikkeling
5 minuten leestijd | Geschreven door Mark AlbersVoor vorming van de Nationale Politie moest het ICT-landschap van 26 losse korpsen samengevoegd worden tot één samenhangende informatievoorziening. De nieuwe ICT moet ook de straatagenten via hun smartphone optimaal ondersteunen. Een radicale operatie, want hoe vernieuw je de ICT terwijl de winkel open blijft? APM ging de uitdaging aan in Project Agora. Daaruit bleek dat een ICT-verandering niet alleen draait om agile software, maar vooral ook om de werkwijze.
Digitaal samenwerkingsplatform voor de Nationale Politie
Project Agora zette een cloud-ready digitaal samenwerkingsplatform op waarin de diender centraal stond, in plaats van het informatiesysteem. Het is een virtuele plek waar collega’s interactief samenwerken. Het agile/DevOps-team maakte het bovendien mogelijk om nieuwe en gewenste functionaliteit op elk uur van de dag beschikbaar te stellen. Een radicaal ander systeem dan agenten gewend waren. De uitdaging was dan ook om te zorgen dat de dienders het systeem daadwerkelijk gebruiken.
Microsoft SharePoint
Microsoft SharePoint 2013 private cloud is het fundament voor Project Agora. Het team richtte vanaf 2012 deze infrastructuur in. Overtuigd van de kracht van agile werken, maakten zijn daarbij gebruik van scrum. Professionals uit het projectteam vormen een ontwikkelteam dat in de lijn verankerd is. Het project vormde de buffer tussen het agile-team, de ITIL-procedure gedreven IT-omgeving en de dynamische 24/7-wereld van de politie.
De basis: Infrastructuur/Platform/Software as a Service
Het platform was in 2014 productieklaar. Onder de motorkap is het een Iaas/Paas/Saas-platform. Dat maakt het mogelijk om wijzigingen aan te brengen in één van de verschillende lagen, zonder dat die wijziging de gebruikers zelf raakt. Het platform is er gewoon, als water uit de kraan. Wij maken ons tenslotte ook niet druk als het waterbedrijf een verandering aanbrengt in het leidingnetwerk. Die beschikbaarheid van functionaliteit leidt tot interessante verandervraagstukken.
Agile ontwikkelen vereist een andere mindset
Enthousiast ging het ontwikkelteam aan de slag. Na concrete vragen van de eerste gebruikersgroepen kwamen zij na vier weken al met oplossingen. Te snel, zo bleek. De ICT-oplossingen kwamen voor het mobiliseren van de gebruikers; de nieuwe werkwijze was nog niet geland. Kortom: de implementeerfase bestond niet meer. Het verandervraagstuk dat hieruit naar voren kwam, splitsen we op in een aantal deelvragen.
- Hoe krijg je gebruikers uit hun (aangeleerde) manier van vraagformulering aan de IT-afdeling?
- Hoe lever je als IT-afdeling als klanten gewend zijn oplossingen snel te krijgen?
- Hoe zorg je ervoor dat ICT- en organisatieontwikkeling parallel aan elkaar lopen?
Silo versus platform
Agora maakt gebruik van SharePoint als Software as a Service. De gebruikers delen één platform waarop ze zelf (informatie)portalen en samenwerkingsomgevingen creëren. Vooraf is niet precies bekend waarvoor gebruikers het inzetten. Het agile software ontwikkelteam werkt daarom kort-cyclisch aan het leveren van oplossingen waar ter plekke vraag naar ontstaat.
Op zoek naar gebruikers
Dat klinkt allemaal mooi, maar hoe weet je waar vraag naar is? Het is zaak (nieuwe) gebruikersgroepen te vinden. Waar vind je collega’s die een behoefte hebben die andere systemen niet bieden? De verwachtingen waren hooggespannen. Agora is een van de eerste moderne nationale IV-voorzieningen, dat moest een succes worden. Van Aetsveld ging daarom op zoek naar de verbinding tussen veranderende behoeften van dienders, nationale werkwijzen en de mogelijkheden van Agora.
IT to Business of Business to IT alignment?
De eerste stap was om vanuit het project de focus op business value te leggen. Zo werden vragen uit de operatie direct zichtbaar. Vaak waren dat concrete vraagstukken die op korte termijn opgelost konden worden. Vragen varieerden van ‘lever mij een mobiele app waarmee ik foto’s van een centrale locatie kan tonen op een smartphone’ tot ‘bied me inzicht in de woninginbraken in mijn buurt over de afgelopen twee weken’ of ‘welke collega’s zijn er in dienst?’.
De oplossing is nú nodig
De vragen van agenten leidden regelmatig tot gesprekken met andere projecten of beheerders van silo-applicaties. Om samen op te trekken, moeten specifieke procedures doorlopen worden. Daarnaast worden zaken vaak uitgesteld, omdat een andere silo het liefst zelf levert. Dit alles leidt tot verstoring van de kortcyclische wens vanuit het ‘het blauw’. Zij hebben nú de oplossing nodig!
Liever een quick fix
Deze uitdaging werd beslecht door zo snel mogelijk te bouwen op basis van beschikbare componenten. Liever een quick fix die functionaliteit levert, dan een structureel en langdurig ombouwproject. Uiteraard wordt de structurele route wel degelijk uitgelopen. Het gebeurt alleen nu binnenskamers en niet over de rug van de diender.
Standaardisatie versus maatwerk
Werken met een platform gebaseerd op standaard componenten levert een mooi vraagstuk op over nut en noodzaak van zelf bouwen van oplossingen. Maatwerk is complex en kostbaar, maar één (opgelegde) standaard zorgt voor weerstand, gemiste kansen en een slechtere aansluiting. Binnen het korps is vanwege de diversiteit in ontwikkeling nauwelijks sprake van standaard werkprocessen. Elk van de 168 basisteams krijgt te maken met specifieke vraagstukken. Je kunt je voorstellen dat de dynamiek van de Amsterdamse binnenstad anders is dan plattelandsproblematiek op de Veluwe.
Centrale of decentrale verantwoordelijkheid
Werken met een platform is lastig als je gewend bent zelf verantwoordelijk te zijn voor een probleem en de oplossing. Ineens moet je samenwerken en soms zelfs concessies doen om een brede oplossing toch in jouw situatie te kunnen toepassen. De spanning die hierdoor ontstaat, pakten we aan door te zoeken naar coalities. Zij gaan samen aan de bak om draagvlak te creëren en die massa te benutten om nieuwe vragen snel in te vullen.
Bouwstenen hergebruiken voor een snelle oplossing
Basisteams creëren een oplossing, vervolgens kijken districtsrechercheteams hoe deze aansluit op de basisteamomgeving. Voor voetbalbegeleidingsteams bouwden we een alternatief gebruik van de standaard basisomgeving op. Juist door eerder opgebouwde componenten te hergebruiken, speel je snel in op nieuwe vragen. Soms zo snel dat de formele, centrale besluitvorming het niet bijbeent. Waar een pilot start met drie teams, blijkt in andere teams zo’n behoefte te bestaan, dat zij zelf wel gaan bouwen aan een oplossing. En dat geeft weer inzicht in het succes van de oplossing in de operatie.
Ontwikkeling van agile/scrum naar DevOps
Door het succes versnelde de snelheid van leveren en ontstonden duidelijke vragen voor aanpassingen aan het platform: meer capaciteit en betere toegang via de smartphone. We trokken de lijn daarom door naar het rekencentrum. IT-Operations werd onderdeel van het Agile Development-team. Daarmee ontstond een Agile DevOps-team.
Binnen de samenwerkingsvoorziening leidt die ontwikkeling ook weer tot uitdagingen op gebied van teamvorming. Nieuwe spelers toevoegen aan een bestaand team leidt altijd tot dynamiek in teamontwikkeling. Afspraken moeten opnieuw gemeengoed worden en de nieuwe taakstelling zorgt dat de prioritering op een andere manier bekeken moet worden. De Product Owner, die het werk van het DevOps-team prioriteert, wordt met een nieuw spel geconfronteerd. Door het betrekken van het rekencentrum kan functionaliteit daadwerkelijk ieder uur van de dag in productie gezet worden. Het team levert nu echt 7 dagen per week 24 uur beschikbare functionaliteit!
En van DevOps door naar BusOps?
Er blijven zeker nog uitdagingen over. Dat blijkt wel uit de wens om de lijnen naar gebruikersondersteuning nauwer aan te trekken. Daarbij moeten verschillende teams rond de applicaties (DevOps/Agile en conventioneel) aan de slag. Dat gaat (nog) niet zonder slag of stoot. Bijna twee jaar na de start is het de uitdaging om de traditionele functie van informatiemanagement ook te integreren in deze aanpak. Daarmee ontstaat een agile aanpak, van businessvraag tot en met oplossing.
Geen implementatie maar acceptatie
De basisteams zijn gewend om snel te handelen bij (nood)situaties. Daardoor vonden zij snel en veel behoeften. Die pakten ze in eerste instantie zelf op door te bouwen vanuit wat al beschikbaar was. Doordat oplossingen gebouwd zijn door collega’s en voor collega’s sloten ze direct aan op de gebruikerswens. Zo droegen deze werkvormen sterk bij aan de ‘geen implementatie maar acceptatie’ succesfactor.
APM leverde de expertise om een platform te realiseren dat de brug slaat tussen techniek en operatie. Met agile software ontwikkelling verbonden we beide werelden en introduceerden nieuwe samenwerkingsvormen.
Bekijk hier het verslag van de presentatie (video).