Home ongecategoriseerd Voorkom teleurstelling bij het veranderen van werkmethoden!

Voorkom teleurstelling bij het veranderen van werkmethoden!

151

Veel organisaties stappen momenteel over op andere werkmethoden. De verwachtingen zijn dan vaak hooggespannen. Een artikel in AutomatiseringGids schrijft bijvoorbeeld: “DevOps blijft nog een worsteling”.[i]

Rini van Solingen en Henk Jan Huizer wijzen – ook in AutomateringGids[ii] – op de meest gemaakte fouten bij agile transformaties. Bijzonder is het advies om agile goed te borgen via een apart veranderingsproces en te beginnen met strategie, planvorming en een business case. Dit lijkt op het gebruiken van een (waterval)methode die je juist wil vervangen!
Toch is dit minder vreemd dan het lijkt. Wil je weten of nieuwe werkmethoden daadwerkelijk een oplossing is voor bestaande problemen, dan zal je daar toch eerst over na moeten denken. Sommige problemen in (software-ontwikkel) projecten komen algemeen voor en staan los van werkmethoden. Een aantal problemen bestaat al relatief lang en is hardnekkig. De volgende voorbeelden komen direct uit de praktijk:

  1. Gebrek aan functiescheiding

Het team dat de software heeft ontwikkeld voert ook het testwerk uit. Uit oogpunt van kwaliteitsborging is dat een groot risico. Softwareontwikkelaars zijn meestal geen bekwame testers en doen dit werk niet graag. Testen wordt dan een soort sluitpost. Testen laten uitvoeren door een apart en onafhankelijk (gebruikers)testteam heeft een positieve invloed op de kwaliteit van de software. Het belang van principes als functiescheiding wordt (nog te vaak) onderschat.

  1. Integratieproblematiek

Wanneer in een omgeving veel kleine (agile) teams werkzaam zijn die elk hun eigen deelbijdrage leveren ontstaat een gebrek aan samenhang. Dit leidt tot integratieproblematiek. Hard- en softwarecomponenten (zelf ontwikkeld en/of gekocht) worden regelmatig pas vlak voor oplevering geassembleerd, geïntegreerd en geconfigureerd tot een werkend (deel)product. Gebrek aan integratierichtlijnen of architectuur, maar ook gebrek aan samenwerking leveren dan taaie problemen op waardoor de voordelen die bijvoorbeeld agile biedt (= snelheid) teniet worden gedaan. Voorwaarden of richtlijnen voor integratie van componenten dienen vooraf duidelijk te zijn. Dit principe noemt men ‘voorwaarts integreren’.

  1. Niet-functionele eisen

Vaak richt men zich vooral op het ontwikkelen en bouwen van functionaliteit. Het toevoegen van bijvoorbeeld beveiligingssoftware wordt dan pas tijdens de integratiefase gedaan. Deze beveiligingssoftware kan een grote impact hebben op de juiste werking van functionaliteit. Zeker als software voor meerdere apparaten (laptop, desktop, tablet, smartphone) wordt ontwikkeld kan het goed werkend krijgen van alle functionaliteit én beveiliging behoorlijk moeizaam verlopen.

  1. Gebrek aan resources

Capaciteitsproblemen zijn aan de orde van de dag, ook bij agile projecten. In de meeste omgevingen lopen meerdere projecten tegelijk en prioriteitstelling van projecten en beschikbaar stellen van resources is dan een hele uitdaging. Zeker wanneer verschillende producten voor commerciële doeleinden worden gebouwd voor meerdere externe klanten tegelijkertijd. Wanneer geen prioriteiten worden gesteld krijgen alle projecten hier last van.

  1. Overdracht naar beheer

Nog steeds krijgen projectleiders het voor elkaar, dat wanneer ze buiten tijdplanning of budget raken dat hun project status ‘in beheer genomen’ krijgt zonder dat er overdracht en toetsing op basis van eenduidige criteria heeft plaatsgevonden. Elke projectleider is ook verantwoordelijk voor de goede borging van het projectresultaat in beheer. Dit is een impliciet onderdeel van goed vakmanschap.

  1. Commerciële open eindjes

Het werken met standaardcomponenten en deze zoveel mogelijk hergebruiken is een bekend en gewenst principe. Echter, in het verkoopproces organiseren verkopers regelmatig demo’s voor commerciële klanten. Op basis van een demo besluit een klant dan het (software)product te kopen. Klanten stellen tijdens het verkoopproces vragen of specifieke aanpassingen mogelijk zijn. Verkopers zeggen dan dat dit mogelijk is, waardoor klanten tijdens de start en bouwfase van een project hierop teruggrijpen en kleinere, specifieke aanpassingen willen doorvoeren in de vorm van maatwerk. Dit kan uiterst risicovol zijn en grote gevolgen hebben omdat specifieke aanpassingen vaak ook weer tot specifieke integratieproblemen kunnen leiden. Eigen onderzoek laat zien dat doorlooptijden met een factor 4 kunnen toenemen.

Bovenstaande opsomming is niet uitputtend en een aantal problemen is ook niet nieuw. De boodschap is dat organisaties goed moeten nadenken of een andere werkmethode helpt om problemen in bestaande werkmethoden of sturing ervan op te lossen. De toegevoegde waarde van het naleven van algemene principes zoals functiescheiding, integratierichtlijnen en sluitende klantafspraken zijn voor elke methode belangrijk. Als deze principes niet goed zijn geregeld in de bestaande werkmethode worden ze niet vanzelf opgelost met een andere werkmethode. En dat is een gemiste kans! Andere werkmethoden zoals agile kunnen, mits goed toegepast, tot exponentiele versnelling leiden.[iii]

Leon Dohmen is principal managementconsultant CGI

[i] http://www.automatiseringgids.nl/nieuws/2016/02/devops-blijft-nog-worsteling

[ii] http://www.automatiseringgids.nl/achtergrond/2016/03/de-7-meest-gemaakte-fouten

[iii] https://www.hmr.nl/archief/exponentiele-projecten

LAAT EEN REACTIE ACHTER

Please enter your comment!
Please enter your name here