Artikel

Piet Hein Eek werkt ook Agile

In een eerder artikel "Rol van architectuur in een agile aanpak" heb ik geschreven over de verhouding tussen softwarearchitectuur en een agile ontwikkelproces en het succes hiervan. Agile is hot en de term wordt daarom overal opgeplakt. Het is ook moeilijk om de essentie van agile te vatten als je het niet hebt meegemaakt. Agile heeft voor een belangrijk deel te maken met een mindset, een manier van omgang, een cultuur. In dit artikel wordt aan de hand van een project van Piet Hein Eek duidelijk gemaakt wat de essenties zijn van agile werken.

Wie is Piet Hein Eek?

Piet Hein Eek behoort tot één van de, zowel nationaal als internationaal, bekendste ontwerpers van Nederland. Hij is bekend geworden met zijn meubels van sloophout. Intussen maken hij en zijn team naast meubels ook lampen, kachels, servies, kantoor- en winkelinrichtingen, keukens en interieurs.

Persoonlijk vind ik het leuk om woonbladen te lezen. In het blad 'Eigen Huis & Tuin' heeft dit jaar een aantal maanden een column van Piet Hein Eek gestaan. Hierin vertelt hij over zijn ervaringen met de verbouwing van zijn nieuwe bedrijfspand. Dit verhaal lezende kwam ik tot de ontdekking dat dit een sprekend voorbeeld is van een agile aanpak, maar dan in een heel andere discipline.

In dit artikel probeer ik aan de hand van wat voorbeelden uit deze columns duidelijk te maken wat nu zo typerend is voor een agile denk- en werkwijze. Hier en daar heb ik ook letterlijke quotes opgenomen, omdat deze zo sprekend zijn voor de manier van denken en ook vrijwel letterlijk het agile gedachtegoed verwoorden.

Wat is Agile?

Uit onvrede over het onvoldoende behalen van de gewenste resultaten bij systeemontwikkeling zijn 14 software goeroes in 2001 om de tafel gaan zitten om te bedenken hoe het anders moet. Dit heeft geresulteerd in het Agile Manifesto. Het Agile Manifesto beschrijft 4 kernwaarden en 12 principes die tot betere resultaten zouden moeten leiden. 

 

De 4 kernwaarden (values) zijn:

  • Individuen en interactie boven processen en tools
  • Werkende software boven uitgebreide documentatie
  • Samenwerking met de klant boven contractonderhandelingen
  • Reageren op verandering boven het strikt volgen van een plan

Deze waarden betekenen niet dat processen, documentatie, plannen en dergelijke niet belangrijk zijn. Echter werkende software, interactie en meegaan met veranderingen zijn gewoonweg belangrijker. Naast de kernwaarden kent het Agile Manifesto ook nog de volgende principes [1]:

  1. De hoogste prioriteit is de klant tevreden te stellen door het vroegtijdig en frequent opleveren van bruikbare software.
  2. Werkende software frequent opleveren, liefst iedere paar weken, hooguit iedere paar maanden.
  3. Werkende software is de belangrijkste maat voor vooruitgaan.
  4. Sta open voor veranderende eisen, zelfs laat tijdens de bouw. Agile processen benutten verandering en leveren zo een concurrentievoordeel voor de business.
  5. Vertegenwoordigers van de business en ontwikkelaar werken dagelijks samen gedurende het gehele project.
  6. Bouw projecten rond gemotiveerde individuen. Geef hun de omgeving en de ondersteuning die ze nodig hebben en vertrouw erop dat ze de klus klaren.
  7. De meest efficiënte en effectieve manier om informatie te delen in een ontwikkelteam is met elkaar te praten.
  8. De beste architecturen, eisen en ontwerpen komen voort uit zelfsturende teams.
  9. Voortdurende aandacht voor een hoge technische kwaliteit en voor een goed ontwerp versterken agility.
  10. Agile processen maken continue ontwikkeling mogelijk. Opdrachtgever, ontwikkelaars en gebruikers moeten een constant tempo eindeloos kunnen volhouden.
  11. Eenvoud - de kunst van het maximaliseren van het werk dat niet gedaan wordt - is essentieel.
  12. Regelmatig onderzoekt het team hoe het effectiever kan worden en past vervolgens zijn gedrag daarop aan.

Het hoogste goed bij agile is het continu leveren van een werkend eindproduct, in dit geval software, met toegevoegde waarde voor de klant (gebruiker). Daarbij wordt ervan uitgegaan dat de wereld continu verandert en dat de gebruiker niet precies weet of kan weten wat hij nodig heeft, maar dat dit gaandeweg duidelijk wordt.

 

Agile kan op verschillende manieren toegepast worden en er zijn meerdere methoden beschikbaar. Eén van de bekendste agile ontwikkelmethoden is SCRUM. Lees meer over deze methode in het kader 'Wat is Scrum?' onderaan het artikel.

 

[1] AgileHolland.com

Het project is een groot avontuur

Onderwerp van de column is de verbouwing van de voormalige keramiekfabriek van Philips in Eindhoven tot een totaalconcept bestaande uit werkplaats, ateliers, kantoren, restaurant, expositieruimte, en nog veel meer. Het project heeft een harde deadline van 23 oktober, want dan is de 'Dutch Design Week'. Het project is ambitieus en gewaagd. Er zijn ook flinke belangen mee gemoeid en dat midden in een crisistijd.

Een aantal wetenswaardigheden; er moet meer dan 3000 meter glas vervangen worden, 5000 meter vloer moet worden schoongemaakt en behandeld, verwarmingsinstallaties moeten hersteld worden, er is sprake van vervuilde grond … alles behalve een standaard project dus.

Wat zijn de kenmerken van het project? Het is een groot en complex project. Er is een harde deadline, waardoor de beschikbare tijd slechts 9 à 10 maanden is. Er zijn veel - eigen en ingehuurde - mensen bij betrokken, met veel verschillende disciplines en veel partijen. Er is sprake van externe regelgeving en het resultaat moet passen in de bestaande omgeving.

Kortom, het is te vergelijken met een groot en complex IT project in een grote organisatie, met diverse - deels externe - uitvoerders, waarbij het systeem moet voldoen aan tal van regels en moet worden ingepast in een bestaande omgeving.

De aanloop heeft meer tijd gekost dan de uitvoering

De hele voorbereiding tot het moment waarop daadwerkelijk met de verbouwing gestart kon worden heeft meer dan anderhalf jaar geduurd. Eén van de te nemen hordes hierin was het verkrijgen van de benodigde vergunningen. De aanvragen hiervoor waren ergens maanden op de plank blijven liggen. Na een vergadering met alle betrokken partijen (o.a. de verantwoordelijk wethouder) was het binnen een week geregeld.

Hoeveel IT projecten worden niet gestagneerd doordat ze in afwachting zijn van goedgekeurde (start)architecturen, bouwvergunningen etc. Ik zeg niet dat dit niet belangrijk is, maar het voorbeeld onderstreept maar weer eens het belang van directe communicatie om het proces efficiënt te laten verlopen. Directe communicatie is één van de belangrijkste elementen in een agile aanpak. De eerste value in het agile manifest is ook "Individuen en interactie boven processen en tools."

Het vertrouwen van de stakeholders

Net als bij elk project heeft ook dit project stakeholders. De belangrijkste stakeholders zijn hier de gemeente en wethouders, de (project)ontwikkelaar en de bank. "Wij krijgen enorm veel vertrouwen van de ontwikkelaar, de gemeente en de bank. Gebruikelijk is het niet. Conservatisme viert hoogtij zodra de risico’s toenemen. En wij doen zo ongeveer alles anders, alternatief en op onze eigen manier."

Hoe vergelijkbaar is dit met IT projecten. Hoe groter en risicovoller een project, hoe meer controle we willen door nog gedetailleerdere planningen, een strakke monitoring, veel rapportages, dicht- getimmerde contracten etc. We doen er alles aan om de risico’s te beheersen. Hoe groter het project, hoe meer tijd dit kost, tijd die niet direct besteed wordt aan het eindproduct. En het gevoel bij agile is inderdaad dat alles anders gaat, alternatief en op een eigen manier. Agile betekent zeker niet dat er geen sprake zou zijn van risicobeheersing. Monitoring maakt integraal onderdeel uit van de aanpak (het storyboard bijvoorbeeld laat continu zien hoe de voortgang is, de backlog is altijd inzichtelijk), risico’s worden op het moment dat ze valide worden echt aangepakt (indien nodig met spikes), zo worden ook test en deployment continu uitgevoerd en niet uitgesteld tot het laatste moment.

Het gaat dus wel om een andere manier van risicobeheersing en dat geeft stakeholders zoals opdrachtgevers en managers een wat ongemakkelijk gevoel. Net als bij Piet Hein Eek betekent dit dat een agile aanpak vraagt om het vertrouwen van de stakeholders.

De aanpak

De aanpak kenmerkt zich door pragmatisme en flexibiliteit. "Wij werken eigenlijk altijd op organische wijze, waarbij mensen op hun kwaliteiten worden ingezet. Als iedereen hard en efficiënt werkt en je zorgt dat er altijd iets te doen is, kan het haast niet anders dan dat er per saldo rendabel wordt gewerkt. Maar andere bedrijven hebben veel meer regelgeving rond hun werkzaamheden, met betrekking tot werkvolgorde, controle, afstemming op elkaar en allerlei andere organisatorische zaken, waardoor ze veel meer volgens een vooropgesteld plan werken. Wij beginnen gewoon te buffelen."

Zie hier ook één van de verschillen tussen een meer klassieke aanpak en een agile aanpak. Besteed niet onnodig veel tijd aan van tevoren alles proberen te bedenken, plannen, analyseren, ontwerpen, want de praktijk zal altijd anders zijn. Doe wat nodig is om te kunnen starten en begin dan. Ook bij dit project zullen ze in zekere mate nagedacht moeten hebben over de aanpak en het beoogde eindresultaat, want dat is nodig voor financiering, vergunningen en aantrekken van andere partijen. Maar de rest kan gaandeweg wel duidelijk worden.

"Denken aan wat we eerst af moeten hebben, wat we niet per se af moeten hebben, wat we wel kunnen betalen en wat we niet kunnen betalen. Denken over de werkvolgorde. … Het is ook nodig al dat gedenk, want het wordt aan de hand van de almaar verschuivende planning steeds duidelijker dat ideeën die we hebben wel erg ambitieus zijn. Plan A is nog niet mislukt of plan B en C worden alweer bedacht. Plannen die houvast bieden om door te gaan."

Feitelijk zie je hier een productbacklog waarbij de prioritering continu wordt bijgesteld op basis van wat af moet zijn, waar wijselijk het geld aan besteed moet worden en wijzigende inzichten. Het is een proces van continu bijstellen van welk werk op dat moment het belangrijkste is, geheel conform de value "Reageren op verandering boven het strikt volgen van een plan."

Het verloopt altijd anders

Ik zou haast zeggen; natuurlijk verloopt het anders dan verwacht. Er zijn allerlei tegenvallers zoals het eerste proefraam dat verkeerd blijkt te zijn, de nieuwe pui die niet past, het gaat niet snel genoeg, er zijn meer mensen nodig dan verwacht, er zijn onduidelijkheden over vergunningen, onduidelijke afspraken met externe partijen over wat bijvoorbeeld wel en niet gesloopt wordt. "De controle ontbreekt, het geld raakt op, er wordt van alles vergeten, de onzekerheid groeit. Het is maar de vraag of we dit project wel aankunnen."

Je kunt natuurlijk zeggen dat hij zijn projectmanagement beter op orde had moeten hebben. Afspraken die klip en klaar zijn, een goede inschatting van benodigde capaciteit en geld, een gedetailleerd overzicht van te verrichten activiteiten etc. Maar hoe haalbaar is dat bij een niet-standaard project? Hoe vaak gebeurt niet hetzelfde bij een IT project al was het nog zo goed van tevoren ingeschat? In de IT streven we naar de ultieme schijn zekerheid van het in control zijn, maar de werkelijkheid is altijd anders.

Wat Piet Hein Eek vervolgens hierover zegt is agile vanuit het hart. "Je moet kunnen omgaan met onzekerheden en het nemen van verlies. Je moet vertrouwen op de mensen met wie je werkt. Zorg ervoor dat je onzekerheid niet laat omslaan in wantrouwen!"

Zie hier het agile principe “Bouw projecten rond gemotiveerde individuen. Geef hen de omgeving en ondersteuning die ze nodig hebben en vertrouw erop dat ze de klus klaren.”

Een typerend voorbeeld

Men had het plan om een vloer van 2e hands betonplaten te maken. Echter volgens berekeningen door de gemeente zouden deze niet sterk genoeg zijn hiervoor, met als gevolg dat er kostbare ingrepen gedaan moesten worden. Hierop werd voorgesteld om een test te doen en dit voorstel werd door de gemeente aanvaard. Zo gezegd, zo gedaan. Er werd een real life test uitgevoerd met de betonplaten met als conclusie dat het makkelijk kon. "Al met al is zo’n life test veel goedkoper dan rekenen en de daaruit voortkomende oplossingen direct maar doorvoeren. En bovendien heeft iedereen er bijzonder veel lol in. Lol hebben is belangrijk."

Hier zie je dus een zeer pragmatische aanpak van een mogelijk risico. In termen van agile kun je zeggen dat er een spike is uitgevoerd. Het uitvoerende team komt met een oplossingsvoorstel en dat wordt getest. Dit zegt meer over de haalbaarheid dan een (klinische) berekening. Dit is zoals ook Piet Hein Eek zegt een stuk goedkoper en, ook niet onbelangrijk, veel leuker. Het is namelijk het team dat de oplossing verzint en in de praktijk uitprobeert en niet een door een externe instantie (bijv. een architect buiten het team) opgelegde oplossing. Ofwel het agile principe "De beste architecturen, eisen en ontwerpen komen uit zelfsturende teams."

Conclusie

Mijn persoonlijke mening is dat één van belangrijkste succesfactoren van een agile aanpak het teamgevoel is, het gevoel dat je met zijn allen bezig bent iets moois te maken, op een toch wel bijzondere manier. De kracht zit hem in het geloof, het commitment en het ervoor willen gaan.

Dit is ook de sfeer die je proeft in de column van Piet Hein Eek. Men heeft het gevoel dat men met iets bijzonders bezig is, er wordt vertrouwd op het vakmanschap van de mensen en er wordt flexibel en pragmatisch ingespeeld op de situaties zoals die zich voordoen. Ondanks tegenslagen hebben de betrokkenen geloof in het slagen ervan, ze willen er met zijn allen hard aan werken, er heerst 'positivisme' en men heeft er lol in.

"Het gekke is dat we elke stap nemen met een rotsvast vertrouwen in de toekomst."

Wat is SCRUM?

Agile kan op diverse manieren worden toegepast. Momenteel is SCRUM de meest toegepaste vorm. Bij SCRUM wordt een project opgedeeld in sprints. Een sprint is een tijdsperiode (bij voorkeur 2 tot 4 weken) waarin een werkend product wordt opgeleverd (een potentialy shippable product). De inhoud van een sprint wordt gevormd door de sprint backlog. De sprint backlog is een hoeveelheid werk (meestal in de vorm van user stories) wat een selectie is van de totale hoeveelheid uit te voeren werk wat opgenomen is in de product backlog. Elke sprint wordt beëindigd met een demo van het werkend product.

 

Een werkend product wil zeggen dat het aan alle eisen voldoet om naar productie te kunnen. Daarmee wordt ervoor gezorgd dat alle facetten van het in productie nemen tijdens iedere sprint aan bod komen (testen, documentatie, overzetten etc.) en niet pas in de laatste fase van het project. Hiermee worden een hoop problemen die normaliter pas aan het eind aan bod komen vanaf het begin getackeld. Dit past ook bij de gedachte dat je hetgeen wat moeilijk is en toch gedaan moet worden, maar beter zo snel mogelijk kunt doen in plaats van dit uit te stellen. Naar productie kunnen wil overigens niet zeggen dat je het ook doet. Vaak wordt in (van tevoren geplande) releases naar productie gegaan.

 

De product owner (vertegenwoordiger van alle stakeholders) bepaalt samen met het team wat de inhoud van een sprint is. De product owner bepaalt de prioriteit. Het team bepaalt de oplossing en haalbare hoeveelheid werk en committeert zich aan de sprint. Belangrijk hierbij is dat ‘commitment’ alleen mogelijk is wanneer ook alle uit te voeren werkzaamheden door het team gedaan worden en er dus geen afhankelijkheden zijn met werkzaamheden buiten het team (overigens blijkt dit punt in de praktijk wel eens lastig haalbaar te zijn).

 

De werkvoorraad in de product backlog bestaat uit (grove) brokken gewenste functionaliteit. De werkvoorraad is geprioriteerd, dat wil zeggen dat de functionaliteit met de hoogste prioriteit bovenop ligt. Dit is ook de functionaliteit die als eerste gerealiseerd moet gaan worden. In de vorm van pokersessies met het team wordt de gewenste functionaliteit nader gespecificeerd. Dit gebeurt met name voor de functionaliteit met de hoogste prioriteit. Op deze manier worden de brokken steeds gedetailleerder uitgewerkt naarmate de prioriteit toeneemt, ofwel het punt van realisatie naderbij komt. Dit is ook de manier voor het team om in een aantal iteraties duidelijkheid te krijgen over de gevraagde functionaliteit (van globaal naar gedetailleerd) en te denken over de mogelijke oplossingen. Er is dus geen sprake meer van een ‘big design up front’. Op deze manier wordt ook het moment van keuze zolang mogelijk uitgesteld, oftewel ‘decide as late as possible’. Als het niet helemaal duidelijk is wat de beste oplossing is kan gekozen worden voor een proef, ook wel een spike genoemd.

 

Op deze manier bepaalt de klant (in de vorm van product owner) wat op welk moment voor hem het belangrijkste is, ofwel de meeste toegevoegde waarde levert. Dit levert ook het mechanisme om te kunnen omgaan met wijzigende inzichten. Het kan zijn dat brokken functionaliteit die initieel op de product backlog stonden nooit gerealiseerd gaan worden. Het kan ook zijn dat iets wat in het begin minder belangrijk leek, om wat voor reden dan ook, opeens een hogere prioriteit moet krijgen.

 

In tegenstelling tot een klassieke aanpak zijn bij agile tijd, geld en kwaliteit fixed, en is de inhoud de variabele. Eén ding is daarbij wel zeker: je krijgt altijd datgene wat het belangrijkste is.

Categorie:   
Auteur(s)
afbeelding van marcocoopmans
Marco Coopmans
G*NIE - Informatie Architect

Ik ben ruim 20 jaar werkzaam in de IT, waarvan de laatste 10 jaar als architect. Sinds 2007 ben ik als onafhankelijk Informatie Architect werkzaam bij G*NIE en begeleid ik (middel)grote ondernemingen bij het bepalen en uitvoeren van hun architectuur op diverse vlakken. Mijn werkzaamheden bevinden zich op het raakvlak tussen business en IT, zoals het vertalen van beleid en strategie naar informatiebeleid en (enterprise) architectuur. Ik ben werkzaam geweest op zowel enterprise- als op projectniveau. Specialisaties zijn componenten architectuur, applicatie integratie, en Business Intelligence. Mijn doel is een optimale aansluiting tussen business en IT. IT is een complexe materie, maar wordt af en toe ook onnodig complex gemaakt. De kunst is om het eenvoudig, begrijpbaar en inzichtelijk te maken, voor zowel de klant als voor de IT organisatie. Een aantal opdrachtgevers waren ING Bank / Rabobank International / Pensioenfonds PGGM / ENECO Energie / Havenbedrijf Rotterdam.

Nieuwe reactie inzenden

De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.
Indien het niet lukt om een reactie te plaatsen, stuur dan uw reactie naar redactie@xr-magazine.nl.
Alle inzendingen dienen correct, professioneel en beschaafd te zijn. IP-adressen worden gelogd, maar niet gepubliceerd. De redactie van XR Magazine behoudt zich het recht voor om anonieme reacties (niet op naam) of zonder geldig e-mailadres, te verwijderen zonder kennisgeving. Ook reacties waarin commerciële uitingen worden gedaan en/of commerciële producten en diensten worden aangeboden worden door de redactie verwijderd of ontdaan van commerciële uitingen zonder kennisgeving.