In 2001 hebben 17 mannen in de vorm van 4 waarden en 12 principes beschreven hoe softwareontwikkeling volgens hen beter kan. Zij hadden veel frustraties opgebouwd met de toen gangbare manieren van softwareontwikkeling. Tot begin jaren negentig leefde men nog in de veronderstelling dat bedrijfsapplicaties niet zo vaak veranderd hoefden te worden en moesten ze dus zo goedkoop mogelijk en in één keer “goed” worden gebouwd. Een gecertificeerd kwaliteitssysteem met beproefde methoden moest dit borgen. In 1992 heb ik tijdens mijn afstudeerstage voor de studie Bestuurlijke Informatiekunde bij Ordina zo’n kwaliteitssysteem voor softwareontwikkeling geïntroduceerd. Websites en mobiele apps waren er toen nog niet. Het werd efficiënt en effectief geacht om software eerst te laten ontwerpen door ontwerpers. Zodra de ontwerpers klaar waren gingen zij aan een nieuw project werken en konden de programmeurs gaan bouwen. De testers controleerden vervolgens of de software voldeed aan het ontwerp, waarna de bouwers de gevonden afwijkingen aanpasten. Daarna was de software gebouwd conform specificaties en moest iedere (kleine) wijziging het hele proces opnieuw door. Naast de bouw van software werd evenveel of soms zelfs meer documentatie geproduceerd. Destijds heetten de betreffende methoden onder andere System Development Method (SDM). Tegenwoordig noemen we het voor het gemak Waterval (omdat de documenten en de software steeds een fase naar beneden vallen, mits je het zo visualiseert natuurlijk). Toen kwamen daar vanaf 1995 plotseling de websites en vanaf 2007 ook de mobiele apps en kwam ICT op ieders bureau en schoot en in ieders broekzak en ging ICT pas echt zijn C van Communicatie waarmaken. ICT heeft inmiddels al een hoofdrol in veel sectoren van banken tot scholen en bedrijfsprocessen van verkoop tot logistiek en niet alleen de websites en apps maar ook de achterliggende bedrijfsapplicaties en koppelingen (API’s) moeten steeds vaker worden aangepast.
Dit intensieve ICT-gebruik door alle consumenten en medewerkers zorgt voor snel veranderende gebruikerswensen. Markten ontwikkelen zich razendsnel (Facebook, WhatsApp, Instagram, Google, Apple, LinkedIn, Amazon, Microsoft, Alibaba) en ook de technologische vooruitgang (cloud, software as a service, scheiding van frontend en backend, kunstmatige data-gedreven intelligentie, innovatieve apparaten zoals horloges en binnenkort ook implantaten) versnelt nog altijd. Om van dit alles chocola te maken vergt steeds meer kennis, toewijding en multidisciplinair teamwork. Logisch dus die toenemende frustraties waaruit in 2001 het Agile manifesto is ontsproten. Maar dit is nog niet alles. Er was ook het probleem van projecten.
Het probleem van projecten
Een project is een tijdelijke organisatievorm om een doel te bereiken. Het wordt ingezet als daarmee het doel efficiënter of effectiever bereikt kan worden dan wanneer de activiteiten door de vaste organisatievorm worden uitgevoerd. Een project levert dus per definitie resultaten op die vervolgens door de vaste organisatie gebruikt gaan worden. Voor veel doelen en resultaten werkt dit prima, bijvoorbeeld een nieuwe spoorbrug of een nieuw huis of groot onderhoud aan die spoorbrug of een verbouwing aan dat huis.
De ontwikkeling en het (groot) onderhoud van software vond en vindt ook projectmatig plaats; Mensen en middelen worden tijdelijk samengebracht, er ontstaat een team met een hoog niveau van kennis van de toekomstige gebruikers, de marktcontext en de relevante technologieën en er worden hoogwaardige producten (website, mobiele app, API-koppelingen) gerealiseerd. Iedereen blij, teamleden keren terug naar hun afdelingen om aan nieuwe projecten te worden toegewezen en de software wordt voor onderhoud en doorontwikkeling overgedragen aan de beheerafdeling.
De beheerafdeling echter beheert meerdere applicaties, heeft het project in het meest gunstige geval zijdelings meebeleefd maar kan nooit het kennisniveau en de handelingssnelheid van het projectteam evenaren. Deze kennis en snelheid zijn nodig om in markten waar serieuze concurrentie of schaarste heerst gebruikers met steeds hoogwaardigere functionaliteiten en gebruikersgemak te blijven verleiden tot interactie en loyaliteit. Positieve business cases worden veelal gecompleteerd met besparingen aan kosten van bijvoorbeeld personeel (aantal telefoongesprekken en een overeenkomstig aantal call center agents), gebouwen en andere niet digitale bedrijfsmiddelen. Een vast team dat er bevlogen bovenop zit levert en pivot nu eenmaal een stuk sneller en beter dan een shared service center dat beheer-tickets afhandelt.
Ook de kwaliteitssystemen en beproefde methoden voor projectmanagement lossen dit niet op. PRINCE2 bijvoorbeeld biedt praktische handvatten voor PRojects IN Controlled Environments. Het was jarenlang dé belofte om projecten beheersbaar te houden en alle betrokkenen werden dan ook gecertificeerd. Maar ook deze procedures met stuurgroepen, faseringen, management van risico’s, issue’s en wijzigingen en bijbehorende documentatie worden snel minder relevant; Je hoort er eigenlijk al niemand meer over. Naar mate steeds meer organisaties Agile methoden gebruiken zoals Scrum (voor eens en voor altijd en voor iedereen: lees dé Scrumgids hier!) en Kanban, wordt bedrijfskritische software niet langer door projectteams maar door vaste Agile teams ontwikkeld en beheerd.
Agile werken lost dus zowel het probleem van Waterval als het probleem van projecten op. Daarbij blijven de kennishoudende specialisten in vaste teams werken, worden zowel de ontwikkel- als de beheertaken door het team uitgevoerd (“DevOps” is Development en Operations bij elkaar) en keren deze specialisten niet meer terug naar hun functionele afdeling om vervolgens aan nieuwe projecten te worden toegewezen. De praktijk is echter in alle organisaties weerbarstig en combinaties van methoden, technieken en werkvormen komen in allerlei verschijningsvormen voor.
Regelmatige diagnose, analyse en dialoog met alle betrokkenen over de achtergronden, definities en toepassingsmogelijkheden voorkomt onnodige frustratie en verspilling van tijd, geld en energie en genereert positieve energie voor de organisatie, de medewerkers en klanten.
De 4 waarden en 12 principes van het Agile manifesto luiden:
4 waarden
- Individuen en interacties boven processen en tools;
- Werkende software boven uitgebreide documentatie;
- Samenwerking met klant boven contractonderhandelingen;
- Reageren op veranderingen boven het volgen van het plan.
Dat wil zeggen, ondanks dat de laatstgenoemden ook waardevol zijn, vinden ze de eerstgenoemden waardevoller.
12 principes
- De klant blij maken door het vroeg en continu leveren van waardevolle software;
- Veranderende eisen en wensen zijn welkom zelfs laat in de ontwikkeling, om de klant zijn concurrentievoordeel te kunnen geven;
- Lever regelmatig werkende software op, liever iedere paar weken dan iedere paar maanden;
- Business mensen en ontwikkelaars moeten dagelijks samenwerken;
- Zet gemotiveerde individuen centraal, faciliteer en ondersteun ze en vertrouw erop dat ze de klus geklaard krijgen;
- De meest efficiënte en effectieve manier voor het uitwisselen van informatie met en binnen het ontwikkelteam is via face-to-face gesprekken;
- Werkende software is de belangrijkste graadmeter van voortgang;
- Alle betrokkenen blijven in een constante cadans samenwerken;
- Continue aandacht voor technische kwaliteit en goed ontwerp bevordert de wendbaarheid;
- Eenvoud, de kunst om zoveel mogelijk werk níet te doen, is essentieel;
- Zelf-organiserende teams maken de beste architecturen, ontwerpen en eisen en wensen;
- Op vaste momenten onderzoekt het team hoe ze effectiever kunnen werken en ze voeren verbeteringen door.
In mijn artikel over Lean en het opschalen van Lean en Agile softwareontwikkeling leg ik uit wat Lean is, waar het vandaan komt en hoe het samen met Agile aan de wieg heeft gestaan van organisatiebrede toepassingen waaronder het Scaled Agile Framework (SAFe).
Heb je interesse in mijn kennis en ervaring, een presentatie, training of begeleiding van management of medewerkers, bel of mail me dan.