Regelmatig word ik door bedrijven gevraagd een kijkje in de keuken van hun ontspoorde projecten te nemen. Wanneer ik praat met de mensen die bij die projecten zijn betrokken, zoals product owners, architecten, ontwikkelaars en testers, maar met name met projectmanagers, valt op dat de terminologie die wij hanteren in software development gestoeld is op de terminologie uit heel andere sectoren van het bedrijfsleven. Nog altijd.

Zo hebben we het over begrippen als architectuur, het bouwen van software, of het leggen van een fundering, waar we het creëren van software bedoelen. Overduidelijk wordt hier gerefereerd aan civiele techniek of aan het bouwen van huizen. Helaas blijft het niet bij terminologie. We koppelen tegelijkertijd ook de typische eigenschappen van het bouwen van huizen aan het ontwikkelen van software.

Een belangrijk misverstand dat zo helaas is ontstaan, is dat het van fundamenteel belang is van te voren goed na te denken over hoe en wat er precies wordt gebouwd. Immers, wanneer de fundering eenmaal is gestort en de muren van de begane grond zijn opgetrokken, is het niet eenvoudig om alsnog een flinke kelder in te bouwen. Zo’n grote wijziging stuit in de bouw op fikse uitdagingen. En dus worden er eerst uitgebreide bouwtekeningen gemaakt en wordt de constructie nauwgezet doorgerekend.

De metafoor past niet

Bij gebrek aan eigen metaforen voor het software-developmentvakgebied, is de metafoor uit de bouw overgenomen. In de veronderstelling dat wijzigingen later in een project ook bij het bouwen van software fikse uitdagingen opleveren, maakt men eerst een uitgebreide analyse van alle mogelijke wensen en eisen. Ook wordt er een nauwgezet ontwerp gedocumenteerd vooraleer er ook maar één regel code wordt geschreven. En dat is onterecht.

De metafoor van het bouwen van huizen past namelijk niet bij het ontwikkelen van software. Er is een essentieel verschil tussen beide vakgebieden. Waar het realiseren van een kelder vrijwel onmogelijk is als de eerste verdieping van een huis eenmaal staat, is dit in het ontwikkelen van software juist wel mogelijk. En zelfs wenselijk. Ook wanneer er al enige tijd wordt gewerkt aan software, kunnen we met betrekkelijk weinig moeite de scope en architectuur nog ingrijpend wijzigen.

We kunnen met betrekkelijk weinig moeite de scope en architectuur nog ingrijpend wijzigen”

Sterker, waar dit in de bouw als uitermate ongewenst wordt beschouwd, biedt dit bij het ontwikkelen van software juist kansen. We kunnen daardoor veel beter reageren op voortschrijdend inzicht. Doordat de klant voortdurend zicht heeft op wat er is ontwikkeld, ontstaan er nieuwe ideeën. En deze nieuwe ideeën leiden steevast tot een beter product, ook later in een project. Dit is zelfs een van de uitgangspunten van agile softwaredevelopment. Voor de verdere ontwikkeling van ons mooie vakgebied is het dus goed als we de metafoor van het bouwen van huizen loslaten.

Aan de lopende band

Er is een tweede metafoor waar ik afscheid van wil nemen. En dat is de analogie tussen het ontwikkelen van software en fabrieken. Te vaak hoor ik managers zeggen dat er meer geproduceerd moet worden en dat er onvoldoende software van de band rolt. Het creëren van software wordt vergeleken met werk aan een lopende band, waarbij ontwikkelaars en testers vooral een middel lijken om zoveel mogelijk software van de band te laten rollen. Ook de nare term resources komt hier vandaan, waarmee meestal mensen in teams worden aangeduid.

Ook de vergelijking met het werk aan een lopende band gaat mank. Van een lopende band rollen door het in hoog tempo repetitief uitvoeren van vaak eenvoudige handelingen gelijksoortige producten, die hooguit van elkaar verschillen door eenvoudig te configureren eigenschappen als kleur of vorm.

Bij het ontwikkelen van software is iedere nieuwe feature anders dan de vorige; elk product dat we ontwikkelen is anders dan het vorige. Softwareontwikkeling is een complex en creatief proces dat zich niet laat vangen in eenvoudige en repetitieve handelingen. Het ontwikkelen van software is vooral mensenwerk. Iedere nieuwe feature leidt tot een zoektocht naar de best passende oplossing.

Door de enorme diversiteit in architectuur, toegepaste patronen, de mogelijke toegepaste raamwerken en gereedschappen, uitdaging met betrekking tot performance, schaalbaarheid en veiligheid, is dit steeds opnieuw een creatief proces waarvoor hoogopgeleide mensen nodig zijn. Daarbij komt dat de technologie zich zo snel ontwikkelt dat ieder nieuw product gebouwd wordt op nieuwere technologie.

Razendsnelle ontwikkeling

Alhoewel we een jong vakgebied hebben, heeft het zich razendsnel ontwikkeld. In de loop der jaren is het vakgebied steeds volwassener geworden:

  • Agile werkwijzen, zoals extreme programming, Scrum en Kanban, hebben ertoe geleid dat we in kortere iteraties software realiseren, waarbij bij voorkeur iedere iteratie leidt tot een tastbaar resultaat.
  • We zijn sterk gegroeid in het begrijpen van de manier waarop teams het beste samenwerken. Teams zijn zelforganiserend en multidisciplinair geworden en onderhouden voortdurend contact met de klant.
  • We zijn beter geworden in het automatiseren van onze werkprocessen middels continuous delivery en DevOps. Veel van het werk is geautomatiseerd in zogenaamde pipelines waardoor we sneller en effectiever software kunnen opleveren dan ooit tevoren.
  • Ook het testen van software is inmiddels grotendeels geautomatiseerd. Testers klikken niet meer eindeloos door applicaties heen, maar schrijven ook code die de tests uitvoert.
  • Opslag- en rekencapaciteit is nagenoeg onbeperkt beschikbaar in de cloud bij leveranciers als Amazon of Microsoft. Dit maakt het mogelijk om zelfs het inrichten van infrastructuur te automatiseren.

En misschien wel belangrijker dan al die ontwikkelingen bij elkaar: we beseffen dat we veel beter veranderingen in projecten kunnen meenemen en komen zo tot veel betere oplossingen dan wanneer we veranderingen uitbannen in waterdichte plannen. Het is niet alleen mogelijk om rekening te houden met nieuwe wensen en eisen die tijdens een project ontstaan, of met nieuwe wet- en regelgeving, of met voortdurend vernieuwende technologie, het is juist wenselijk gebleken hier gebruik van te maken.

Geen projecten meer

We doen ons werk in dit vakgebied anders in dan in de bouw of in een fabriek. Eigenlijk past het doen van zogenaamde projecten – het tegen een gegeven prijs, met gegeven middelen opleveren van van te voren gedefinieerde functionaliteit – helemaal niet bij software development. Ook in het tijdperk van agile definiëren te veel organisaties hun development nog als projecten, analoog aan het bouwen van een huis.

Maar in software development kunnen en willen we niet lang van te voren plannen en een compleet ontwerp opleveren voor we gaan bouwen. We willen veranderingen toestaan; er juist gebruik van maken. Het op basis van fixed-price, fixed-date een exact gedefinieerde lijst van wensen en eisen opleveren, is in dit vakgebied vragen om moeilijkheden. Daar zijn noch opdrachtgever, noch opdrachtnemer bij gebaat.

Het is dan ook tijd om ook de metafoor van het doen van projecten achter ons te laten. Software development is een vakgebied van trial-and-error, van iets uitproberen, ontwikkelen en evalueren. Gaat het goed, dan kunnen we in dezelfde richting verder. En als iets niet werkt, dan zijn we in staat snel iets anders uit te proberen. We kunnen wel strategisch een richting kiezen waarin we onze software willen ontwikkelen, maar de gedetailleerde invulling van een nieuw product volgt pas tijdens de ontwikkeling.

Hoe anders is dit dan de enorme aanbestedingstrajecten voor grote, traditionele automatiseringsprojecten die bijvoorbeeld door overheden worden uitgeschreven, en waaruit te vaak falende projecten voortkomen.

Een eigen metafoor

Software development is gebaat bij een eigen metafoor. In mijn optiek gaat deze metafoor verder dan waarmee we met Agile al aardig op weg waren:

  • Strategisch kiest een organisatie voor een visie, voor een richting. Mogelijk worden daaruit ook een of meerdere producten op hoofdlijnen gedefinieerd.
  • Er is een lijst met wensen of features die daaruit voortvloeit, ook wel de backlog genoemd. De backlog is dynamisch. Dat wil zeggen dat er voortdurend features bij kunnen komen, maar er ook van kunnen worden verwijderd.
  • Teams zijn multidisciplinaire en zelforganiserende teams die zoveel mogelijk contact met de opdrachtgever hebben.
  • Teams realiseren voortdurend de eerstvolgende, meest belangrijke feature van de backlog, tot deze feature in productie gaat. Het product groeit zo met iedere feature.
  • Features worden derhalve pas uitgewerkt als ze worden opgepakt. Er zijn hierdoor geen iteraties meer zoals in Agile en Scrum, en daarmee verdwijnen ook de typische agile ceremonies, zoals het hebben van iteraties of sprints, en het tijdrovende schatten en inplannen daarvan.

Het voortdurend toevoegen van nieuwe features aan een groeiend product is een veel efficiëntere werkwijze dan het eenmalig aan het einde van een project of zelfs in sprints opleveren van een product. Bij het steeds toevoegen van features is het verschil met de vorige versie van het product immers minimaal. Zeker in vergelijking met software die eens per jaar, eens per kwartaal of zelfs eens per sprint wordt opgeleverd. Hoe kleiner het verschil met de vorige versie is, des te minder er fout kan gaan. De noodzaak van het uitvoeren van een project is daarmee verdwenen. We ontwikkelen áán producten.

Voortdurend verbeteren

Deze werkwijze van het voortdurend toevoegen van kleine features aan een groeiend product is een metafoor die meer en meer wordt toegepast in software development. En met succes. Neem als voorbeeld applicaties op mobiele telefoons waarvan vrijwel dagelijks nieuwe versies verschijnen. Of een product als Office 365, dat zichzelf voortdurend vernieuwt. We stappen af van traditionelere vormen van het opleveren van software die, gebaseerd op verkeerde metaforen uit andere vakgebieden, aantoonbaar inefficiënt zijn. En we gaan inmiddels ook veel verder dan waar Agile ooit, twintig jaar geleden, het goede pad inzette.

Deze nieuwe metafoor wordt overgenomen in andere vakgebieden

Het niet meer uitvoeren van eenmalige projecten, maar het laten evolueren van een product is een goede metafoor voor software development. Sterker nog, deze nieuwe metafoor, waarin we voortdurend volgende stappen zetten op basis van wat er zojuist gerealiseerd is en zo onszelf voortdurend verbeteren, wordt al overgenomen in andere vakgebieden. Dat de wereld verandert onder invloed van software development blijkt inmiddels uit het feit dat andere sectoren – denk bijvoorbeeld human resources of marketing en communicatie, maar ook de gezondheidszorg – profiteren van de nieuwe werkvormen die zijn gegroeid uit agile, lean en continuous delivery.

LAAT EEN REACTIE ACHTER

Laat alsjeblieft een reactie achter!
Laat hier je naam achter