Iteratieve software ontwikkelingsprincipes als ondersteuning voor continu verbeteren op de werkvloer

Deel 1

Of je nu een software ontwikkelaar, veiligheidskundige of operational manager bent, je bent regelmatig op inefficiënte wijze bezig met het verbeteren van je product en/of diensten. Juist in de software industrie zijn in de afgelopen 10 jaar enorm grote sprongen gemaakt in het beheersen van het continue verbeterproces. En hoewel het werken aan software uiteraard andere en veelal kleinere gevaren kent dan het werken met bijvoorbeeld zware machines of gevaarlijke stoffen, is het interessant om deze recente innovaties en best practices uit de kantooromgevingen van de software industrie te vertalen naar de context en realiteit op de werkvloer.

In deze serie blog posts ga ik in op de verschillende facetten van software productontwikkeling en hoe die te toepasbaar kunnen zijn voor het verbeteren van de operatie van bedrijven. Deze serie bestaat uit de volgende delen:

  • Deel 1: Iteratieve software ontwikkelingsprincipes als ondersteuning voor continu verbeteren op de werkvloer
  • Deel 2: Nieuwe software releases en hun effectiviteit: meten is weten
  • Deel 3: Iteratief verbeteren met het SafetyChanger platform

Van sequentieel naar iteratief

Tot enkele jaren geleden — zeker toen software nog door middel van cd-roms werd verspreid — was de voornaamste project methode om software te ontwikkelen de zogenaamde waterval methode. Dit is een sequentieel proces; dit betekent dat iedere fase (concept, analyse, design, ontwikkeling, testen en uitrol) moest zijn doorlopen voordat ontwikkelaars door konden gaan naar de volgende stap.

Door de sequentiële aanpak konden ontwikkelaars niet terug naar een vorige stap zonder het hele project te beïnvloeden en weer opnieuw te beginnen. Er was geen ruimte voor fouten, dus werd er veel tijd geïnvesteerd in planning en designs dat vervolgens nauwgezet gevolgd moest worden. Vaak waren er in de tussentijd reeds nieuwe inzichten opgedaan of bleek tijdens de ontwikkeling, testen of uitrol dat in de voorgaande fases toch niet volledig met alle risico’s en scenario’s rekening gehouden was.

Dit alles leidde vaak tot een niet veerkrachtig ontwikkelteam dat niet kon anticiperen op het hetgeen dat niet vooraf voorzien was. Shortcuts om dit proces te versnellen leidden vaak juist tot vergrote onvoorspelbaarheid. Het resultaat was een toenemende ontevredenheid; zowel bij de opdrachtgever als binnen het team zelf.

Vandaag de dag zijn termen als scrum en agile behoorlijk populair, waar scrum feitelijk een vorm is van de agile methode. Het zogenaamde manifesto voor Agile ontwikkeling luidt als volgt:

  • Individuen en interacties boven processen en gereedschap (Individuals and interactions over processes and tools)
  • Werkende software (lees: verbeterinterventies) boven uitgebreide documentaties (Working software over comprehensive documentation)
  • Samenwerking met de klant boven contractonderhandelingen (Customer collaboration over contract negotiation)
  • Acteren op veranderingen boven het volgen van een plan (Responding to change over following a plan)

Dit betekent niet — dit wordt nog wel eens vergeten — dat de zaken aan de rechterkant (bijv. processen en gereedschap) geen waarde hebben, maar dat de zaken links (individuen en interacties) meer gewaardeerd worden.

Iteratief verbeter proces op basis van agile principes.

Ideeën tot verbeteringen komen vanuit allerlei bronnen zoals gebruikers die feedback geven, klantgesprekken, nieuwe innovaties die weer nieuwe mogelijkheden bieden en natuurlijk ook verbeteringen vanuit de softwareorganisatie zelf. Verbetering worden ruwweg opgedeeld in drie categorieën: features, enhancements en bugs.

Features zijn echt nieuwe opzichzelfstaande toevoegingen aan het product. Je kunt nog niet 100 procent weten wat het succes zal zijn, maar je hebt op basis van hypotheses en onderzoek een zo goed mogelijk beeld kunnen vormen. Deze kun je vergelijken met procesverbeteringen op de werkvloer.

Enhancements zijn verbeteringen op bestaande onderdelen van het product. Je wilt bijvoorbeeld dat een onderdeel meer gebruikt of breder inzetbaar wordt, vergelijkbaar met procesoptimalisaties.

De laatste verbeteringscategorie zijn bugs. Helaas bij de meeste software gebruikers wel bekend: iets werkt niet naar behoren. Mochten deze bugs als kritisch worden geclassificeerd — bijvoorbeeld als gebruikers niet meer het product naar behoren kunnen gebruiken — zal er direct actie ondernomen moeten worden. Dit wordt dan wel een hotfix genoemd, vergelijkbaar met een inperkende maatregel. Bugs komen doorgaans aan het licht als de software al in gebruik is en worden veelal gerapporteerd door gebruikers. Deze zijn vergelijkbaar met geregistreerde afwijkingen in een operationeel proces; neem bijvoorbeeld incidenten, klantklachten, kwaliteitsissues.

Hoe manage je nou die stroom aan verbeteringen? Je kunt ze niet allemaal doen, dat zou te veel kosten. Met andere woorden: je moet kiezen. De kunst bij software productontwikkeling is om alleen verbeteringen door te voeren die voor de meerderheid danwel alle gebruikers van aantoonbaar toegevoegde waarde zijn. bijvoorbeeld 1 nieuwe klant tevreden stellen klinkt misschien heel aantrekkelijk en genereert wellicht extra omzet op de korte termijn, maar dan wordt er voorbij gegaan aan de waarde die alle andere klanten hierdoor mislopen. Het prioriteren van verbeteringen vereist een zorgvuldig classificatieproces, het liefst zoveel mogelijk onderbouwd door betrouwbare data.

Dit leidt uiteindelijk tot een zogenaamde backlog; een buffer van verbeterpotentieel gesorteerd op prioriteit. Binnen een iteratie — een periode van meestal 2 tot 4 weken — worden de verbeteringen met de hoogste prioriteit opgepakt. Eenmaal in de iteratie verandert de scope niet. Dit om het ontwikkelteam gefocust en doelgericht de verbeteringen te kunnen laten realiseren. De prioriteit van verbeteringen op de backlog kunnen echter te allen tijde veranderen: veelal door nieuwe inzichten. Dit resulteert in een voorlopige planning (een product roadmap genoemd), maar biedt daarmee wel de mogelijkheid adequaat te reageren op een nieuwe werkelijkheid.

Het doel is na de iedere iteratie een nieuwe werkende versie van het product op te leveren. Het kan natuurlijk altijd zijn dat een bepaalde verbetering moeilijker was dan gedacht en dus niet afgekomen is. Deze wordt dan uit de release gehouden en voor de volgende iteratie opnieuw ingepland. Het resultaat is altijd een nieuwe versie van het product met de doorgevoerde verbeteringen; zichtbaar voor gebruikers en ook een meetbare teamprestatie. Als Safety Changer releasen wij iedere 3 weken een nieuwe versie van ons platform.

Wat nu met verbeteringen die zo omvangrijk zijn dat ze niet binnen een iteratie te realiseren zijn? Het antwoord is in eerste instantie simpel: knip dit op in kleinere stukken, zodat deze deelverbeteringen wel binnen een iteratie passen. Vaak zijn voor grotere aanpassingen toch wel designs gewenst, zoals we in de tijd van de waterval methode gewend waren. Binnen ons team lossen we dit op door in de eerste sprint als verbetering tot een high level design te komen. Deze dient als framework voor waar we naar toe willen en resulteert tevens in een plan om stapsgewijs de verbetering te realiseren. In opvolgende sprints worden de details verder uitgewerkt en de verbetering daadwerkelijk gerealiseerd. Komen we in de tussentijd tot nieuwe inzichten, dan kunnen we die doorgaans zonder veel moeite meenemen. Dit houdt ons ‘agile’.

Binnen organisaties — of je nu software ontwikkelt, goederen transporteert of voedsel produceert — is het vaak een uitdaging prioriteiten van alle potentiële verbeteringen te bepalen. Vervolgens is het vaak net zo uitdagend om dan de belangrijkste verbeteringen daadwerkelijk op tijd binnen budget gerealiseerd te krijgen met een team die gezamenlijk doelgericht en gefocust dit realiseert. Als software organisatie heb ik met mijn team door het toepassen van de agile principes een voorspelbaarder proces gekregen en krijgen we hierdoor gezamenlijk in korte tijd meer voor elkaar. Daarnaast zijn we wendbaarder voor nieuwe inzichten, van onszelf en van de buitenwereld.

Uiteraard is een verbetering pas daadwerkelijk een verbetering als deze een meetbaar verschil maakt. In het volgende deel ga ik daarom verder in op het meten van de effectiviteit van de doorgevoerde verbeteringen. Coming soon.

Volg Safety Changer op Medium en neem een kijkje op onze website voor meer informatie!

Like what you read? Give Capptions a round of applause.

From a quick cheer to a standing ovation, clap to show how much you enjoyed this story.