Software is uitgegroeid tot een essentieel onderdeel in de strategie van organisaties. Zelfsturing is in de gangbare agile-methode een kardinaal principe, maar zonder feiten en verantwoording van ontwikkelteams is op tijd bijsturen niet mogelijk. Door de verantwoording ver weg te delegeren hebben bestuurders weinig houvast op projecten. Het kan anders door de juiste feiten te verzamelen over het programmeerwerk van ontwikkelteams. Daar is wel een andere cultuur en benadering van softwareontwikkeling voor nodig.

Zelfsturing in agile is functioneel zolang autonomie de productiviteit stimuleert. Bij agile geeft de gebruiker, klant, of opdrachtgever doorlopend feedback, zodat de softwarecomponenten tijdens de bouw van de applicatie aan te passen zijn. In korte sprints wordt door multidisciplinaire teams een applicatie stap voor stap en met feedback van de eindgebruiker doorontwikkeld. Voorbij zijn de tijden dat de eisen en functies van een applicatie helemaal uitgeschreven werden en de applicatie bij oplevering niet voldeed.

Maar ook aan agile softwareontwikkeling zit een keerzijde. Veel projecten kampen met flinke tijd- en kostenoverschrijdingen en de kwaliteit hapert. Bestuurders snakken naar meer grip op softwareontwikkeling, maar krijgen nul op het rekest. Is zelfsturing doorgeschoten?

Verbazingwekkend

Gezien het strategische belang van software is het eigenlijk verbazingwekkend dat het zo veel beter kan. Tijdens het seminar ‘Grip op agile softwareontwikkeling’, begin februari georganiseerd door METRI, specialist in financiële analyse en sourcing, noemde operationeel directeur Paul Cornelisse het ontspoorde digitaliseringsproject Kwaliteit en Innovatie (KEI) van de Raad voor de Rechtspraak.

Omdat deze organisatie in het publieke domein opereert, liggen de aanzienlijke kosten- en tijdoverschrijdingen op straat. Maar dit voorbeeld was voor de aanwezige CIO’s van commerciële organisaties uiterst herkenbaar. Bij applicatieontwikkeling zijn dit soort missers nog steeds meer regel dan uitzondering.

Hoe kun je de vinger aan de pols houden zonder een ontwikkelteam in de weg te zitten? Richard Sweer, senior projectmanager, liet in zijn spreekbeurt overtuigend zien dat een gedeelde werkelijkheid tussen het ontwikkelteam en stakeholders essentieel is. Meetgegevens over de kwantiteit, kwaliteit en de security van softwarecode gebruikt hij om de ontwikkelteams en de stakeholders bij de les te houden en daarmee het project bij te sturen.

De gestandaardiseerde informatie gecombineerd met gedeelde definities zorgt dat er een productieve dialoog ontstaat tussen directie en werkvloer over productiviteit, kwaliteit, releasetempo en medewerker- en klanttevredenheid. Zo ontstaat er een gezamenlijk zicht van management en werkvloer op de voortgang van softwareontwikkeling. Dat biedt onmisbare informatie om projecten tactisch bij te kunnen sturen.

Samenwerking

Met soortgelijke transparantie in de contractering kun je ook in de samenwerking tussen klantorganisaties en leveranciers veel verbeteren, betoogde André Nadorp, director applicatie benchmarking binnen METRI. Bij het afsluiten van contracten voor softwareontwikkeling zijn nu meestal de tariefkaarten voor de verschillende rollen in het ontwikkelteam bepalend, al dan niet gecombineerd met een ureninschatting. Na enige tijd volgen de eerste verrassingen rond planning en budget. Gedetailleerde afspraken over productiviteit, kosten, leversnelheid en kwaliteit versterken de samenwerking.

Door de afspraken op geleverde prestaties te baseren en tussen leverancier en klant transparantie af te spreken, kunnen organisaties uitglijders voorkomen. METRI werkt samen met CAST Software, dat hulpmiddelen heeft om de softwarecode van een release geautomatiseerd en op basis van internationale standaarden door te meten.

Transparantie is dus een belangrijk middel om een of meerdere leveranciers aan te kunnen sturen op hoofdlijnen. Dat kan op een vergelijkbare manier zoals Sweer dat schetste voor de communicatie tussen een intern ontwikkelteam en de stakeholders van die applicatieontwikkeling.

Grip op de softwarestrategie betekent dat er op basis van feiten concrete keuzes gemaakt kunnen worden. Zo kunnen organisaties er bijvoorbeeld bewust voor kiezen om in een sprint genoegen te nemen met een lagere kwaliteit van de softwarecode om sneller op te leveren. Of om juist voor kwaliteit te kiezen, zodat de security van softwarecode bovenaan komt en functionaliteit op een tweede plaats.

Applicaties zijn een onderscheidende factor voor bedrijven. Het is daarom uiterst relevant om softwareontwikkeling op basis van gestandaardiseerde en gedeelde feiten bij te kunnen sturen.