Dit e-boek is voorzien van een verborgen, persoonlijk watermerk.
Het verspreiden of openbaar maken van dit e-boek is niet toegestaan.

This e-book contains a hidden and personal watermark. Distribution is prohibited.

Inleiding

Welkom bij De kleine Agile voor Dummies. Agile projectmanagement is een van de snelst groeiende managementtechnieken van dit moment. In dit boek ontsluier ik enkele mythen over wat agile projectmanagement is en wat het niet is. Met de informatie in dit boek zul je erop durven te vertrouwen dat je agile technieken succesvol kunt toepassen.

De kleine Agile voor Dummies is meer dan een inleiding op agile praktijken en methodologieën. Dit boekje beschrijft agile projectmanagementbenaderingen en leert je de stappen waarmee je agile technieken in een project toepast. De stof gaat verder dan theorie en is bedoeld als een veldgids. Het is voor iedereen toegankelijk en biedt je de hulpmiddelen en informatie waarmee je succesvol agile processen binnen de kaders van projectmanagement kunt toepassen.

Afspraken in dit boek

Als je online zoekt, zie je dat het woord agile vaak met een hoofdletter wordt geschreven. Ik vond dit om een paar redenen wat vreemd. Om te beginnen is het geen naam. ‘Agile’ is een adjectief dat een groot aantal onderdelen in projectmanagement beschrijft, zoals agile projecten, agile teams, agile processen. Je zult zien dat ik het woord alleen aan het begin van een zin met een hoofdletter schrijf.

Toch zijn er enkele termen die wel een hoofdletter krijgen. Het Agile Manifest is materiaal waar rechten op zitten. Agile Alliance, Scrum Alliance en Project Management Institute zijn professionele organisaties. Certified ScrumMaster en PMI-Agile Certified Practitioner zijn professionele titels.

De pictogrammen in dit boek

In dit boek kom je de volgende pictogrammen tegen:

Tips zijn punten om je verder te helpen op je reis naar agile projectmanagement. Met de tips bespaar je tijd en begrijp je snel meer over een bepaald onderwerp.

Beschouw dit pictogram maar als een geheugensteuntje voor belangrijke concepten of termen.

Dit pictogram waarschuwt je dat je een bepaalde handeling of bepaald gedrag in de gaten moet houden. Sla deze vooral niet over als je niet in de problemen wilt raken.

Dit pictogram geeft aan dat de min of meer technische informatie interessant is, maar je hoeft het niet te lezen om agile projectmanagement te begrijpen. Het is gewoon extra informatie die je misschien leuk vindt om te lezen.

Hoe gaan we nu verder

Ik heb dit boek zo geschreven, dat je het in vrijwel elke volgorde kunt lezen. Afhankelijk van je rol hebben bepaalde delen in dit boek misschien meer je aandacht. Bijvoorbeeld:

Zijn projectmanagement en agile benaderingen vrij nieuw voor je, begin dan met hoofdstuk 1 en lees gewoon tot het einde van het boek door.

Zit je in een projectteam en wil je weten hoe je in een agile project te werk gaat, dan begin je bijvoorbeeld met de informatie in hoofdstuk 3.

Ben je een projectmanager en wil je weten hoe agile benaderingen je werk beïnvloeden, lees dan hoofdstuk 7 en 8.

Wil je je bedrijf of organisatie laten kennismaken met agile praktijken? Dan vind je in de hoofdstuk 9 nuttige informatie.

IN DIT HOOFDSTUK:

Agile projectmanagement ontdekken

Het Agile Manifest en de agile principes leren kennen

De platina principes toevoegen

Hoofdstuk 1:
Agile begrijpen

Projectmanagement is traditioneel een flinke uitdaging, met helaas maar al te vaak beperkt succes. Ik laat je de verschillende benaderingen voor projectmanagement zien en leg uit wat hun problemen zijn. Bovendien geef ik een introductie in de basis van agile projectmanagement: het Agile Manifest en de twaalf agile principes.

Projectmanagement moderniseren

Agile projectmanagement is een stijl van projectmanagement waarin de focus ligt op het vroeg realiseren van toegevoegde waarde, voortdurende verbeteringen van producten en processen van het project, flexibiliteit, teaminput en het afleveren van solide producten die aansluiten op de behoeften van de klant.

In deze paragrafen lees je waarom agile benaderingen midden jaren negentig van de vorige eeuw opkwamen als benadering voor projectmanagement in de softwareontwikkeling. Ik leg ook uit wat de voordelen van agile methodologieën zijn boven traditionele projectmanagementbenaderingen.

Projectmanagement was aan vernieuwing toe

Een project is een gepland werkprogramma waarvoor een afgebakende hoeveelheid tijd, moeite en planning nodig zijn om het te voltooien. Projecten hebben doelen en doelstellingen en moeten meestal binnen een vaste tijd en binnen een bepaald budget worden afgerond.

Als formeel vakgebied bestaat projectmanagement zoals we dat nu kennen echter pas sinds het midden van de twintigste eeuw. Tijdens de Tweede Wereldoorlog boekten onderzoekers grote vooruitgang in het ontwikkelen en programmeren van computers, meestal voor het Amerikaanse leger. Het productieproces dat in de jaren veertig voor deze eerste computers werd gebruikt, vormt de basis voor de zogeheten watervalmethode in projectmanagement.

In 1970 schreef de computerwetenschapper Winston Royce een artikel waarin hij de fasen van de watervalmethode beschreef. Hoewel de term waterval pas later werd gebruikt en de fasen soms anders worden genoemd, zijn ze in principe gelijk aan de fasen die Royce oorspronkelijk beschreef:

1.    Vereisten.

2.    Ontwerp.

3.    Ontwikkeling.

4.    Integratie.

5.    Testen.

6.    Implementatie.

In watervalprojecten ga je pas verder met de volgende fase als de voorgaande voltooid is, vandaar de naam waterval. Totdat rond 2008 de agile technieken aan populariteit wonnen, was de watervalmethodiek een van de gebruikelijkste benaderingen voor projectmanagement in softwareontwikkeling.

Te veel van het goede

Traditionele projecten die succesvol worden afgerond, hebben vaak last van hetzelfde probleem: een voortdurende en vaak onnodige uitdijing van de functionaliteit van het product, wat in het Engels bekendstaat als scope bloat. Projectmanagers en belanghebbenden zijn zich ervan bewust dat veranderingen in een lopend project niet welkom zijn, dus dat ze bij de start van een project de beste kans hebben op de gewenste functies. Daarom vragen ze om:

alles wat ze nodig hebben;

alles wat ze denken dat ze misschien nodig hebben;

alles wat ze willen;

alles wat ze denken dat ze misschien willen.

Onderschat deze problemen van achterhaalde management- en ontwikkelbenaderingen niet. Deze problemen verspillen miljarden euro’s per jaar. De afgelopen decennia hebben mensen die dagelijks te maken hebben met projecten, de toenemende problemen met traditioneel projectmanagement onderkend en zijn gaan werken aan een beter model: agile projectmanagement.

Agile projectmanagement

In 1986 publiceerden Hirotaka Takeuchi en Ikujiro Nonaka een artikel met de titel ‘New New Product Development Game’ in het tijdschrift Harvard Business Review. Takeuchi en Nonaka’s artikel beschreef een snelle en flexibele ontwikkelstrategie die tegemoetkwam aan de behoeften van snelle productontwikkeling. Dit artikel gebruikte als eerste de term scrum in combinatie met productontwikkeling, analoog aan scrums in de sport rugby. Scrum wist zich uiteindelijk tot een van de populairste agile projectmanagementbenaderingen te ontwikkelen.

In 2001 kwam een groep software- en projectexperts samen om de gemeenschappelijke kenmerken van hun succesvolle projecten te bespreken. Ze creëerden het Agile Manifest, een verklaring van de waarden voor succesvolle softwareontwikkeling. Deze experts creëerden ook de twaalf agile principes die deze waarden in het Agile Manifest ondersteunen (zie verderop in dit hoofdstuk).

In termen van productontwikkeling is agile een beschrijving van projectmanagementmethodologieën die zich richten op mensen, communicatie, het product en flexibiliteit. Er zijn verschillende agile methodologieën, waaronder scrum, extreme programmering en lean, maar wat ze allemaal gemeen hebben is dat ze zich richten naar het Agile Manifest en de agile principes.

Hoe agile projecten werken

Agile benaderingen zijn gebaseerd op een empirisch controlemodel. Een model waarbij beslissingen worden genomen op basis van de waargenomen realiteit in het daadwerkelijke project. De regelmatige en directe controle van de uitgevoerde werkzaamheden maakt direct ingrijpen en bijsturen mogelijk. Empirische controle vereist:

Transparantie. Iedereen die betrokken is bij een agile project weet wat er gebeurt en wat de voortgang van het project is.

Regelmatige inspectie. De belangrijkste betrokkenen moeten het product en het proces regelmatig inspecteren.

Aanpassing. Voer aanpassingen snel uit om problemen te minimaliseren. Blijkt uit een inspectie dat aanpassingen nodig zijn, voer die dan onmiddellijk door.

Agile projecten integreren deze regelmatige inspecties en aanpassingen door het project in iteraties uit te voeren, in kleinere segmenten van het complete project. Je test het product, corrigeert problemen en implementeert het voor gebruik. Maar in plaats van deze stappen in één keer voor alle productfuncties uit te voeren, hak je het project op in iteraties of sprints.

Waarom agile projecten beter werken

In dit boek zul je regelmatig zien hoe agile projecten beter werken dan traditionele projecten. Agile projectmanagementmethodologieën zijn erin geslaagd meer succesvolle projecten af te leveren. Dit zijn de belangrijkste redenen waarom agile benaderingen superieur zijn aan traditionele projectmanagementmethoden:

Succespercentage projecten. De agile benaderingen waarbij toegevoegde waarde en risicomanagement voorrang krijgen, garanderen vroeg zicht op succes of mislukking. De agile gewoonte om gedurende het hele project te testen en te inspecteren, zorgt ervoor dat problemen vroegtijdig kunnen worden opgespoord.

Uitdijing functionaliteit (scope creep). In agile projecten kun je bij elke nieuwe sprint nieuwe vereisten specificeren, zonder het complete ontwikkelproces te verstoren. Door de belangrijkste functies eerst te ontwikkelen, voorkom je dat secundaire functies de kernfunctionaliteit kunnen bedreigen.

Inspectie en aanpassing. Agile projectteams kunnen dankzij de inzichten verkregen uit afgeronde ontwikkelcycli, hun processen en producten met elke sprint verbeteren.

Het Agile Manifest en de agile principes

In de rest van dit hoofdstuk beschrijf ik de basis van agile: het Agile Manifest met zijn vier kernwaarden en de twaalf agile principes. Ik bouw deze beginselen uit met drie aanvullende platina principes, die mijn onderneming Platinum Edge ontwikkelde op basis van jarenlange ervaring in het begeleiden van organisaties die op agile overstapten.

Het Agile Manifest begrijpen

Midden jaren negentig veranderde de wereld recht voor onze ogen door internet. De mensen in de bloeiende dotcom-industrie stonden onder grote druk om zo snel mogelijk nieuwe technologieën op de markt de brengen. Gezien de snelheid van de veranderingen was het geen wonder dat traditioneel projectmanagement op zijn grenzen stuitte.

In februari 2001 kwamen zeventien pioniers bijeen in de stad Snowbird in de staat Utah in de Verenigde Staten om hun ervaringen, ideeën en benaderingen te delen. De eenvoud en duidelijkheid van hun manifest en de aanvullende principes transformeerde de IT-wereld en revolutioneert nog steeds projectmanagement in andere industrieën.

In de loop van verschillende maanden, stelden deze leiders de volgende items op:

het Agile Manifest: een intentioneel beknopte uitdrukking van de centrale ontwikkelwaarden;

de agile principes: een set van de twaalf richtinggevende concepten die agile projectteams ondersteunen bij het implementeren van en werken met agile;

de Agile Alliance: een organisatie van ontwikkelaars die individuen en organisaties ondersteunt die agile principes en praktijken toepassen.

Manifest voor Agile Software Ontwikkeling *

Wij laten zien dat er betere manieren zijn om software te ontwikkelen door in de praktijk aan te tonen dat dit werkt en door anderen ermee te helpen. Daarom verkiezen we:

Mensen en hun onderlinge interactie boven processen en hulpmiddelen
Werkende software boven allesomvattende documentatie
Samenwerking met de klant boven contractonderhandelingen
Inspelen op verandering boven het volgen van een plan

Hoewel wij waardering hebben voor al hetgeen aan de rechterkant staat vermeld, hechten wij méér waarde aan wat aan de linkerzijde wordt genoemd.

* Agile Manifesto Copyright 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas. Dit manifest mag vrijelijk gekopieerd worden, maar enkel in zijn geheel met verwijzing naar het origineel.

FIGUUR 1: Het Agile Manifest is een krachtig, zorgvuldig samengesteld en compact statement.

Het Agile Manifest en de agile principes verwijzen direct naar software. Ik laat al deze verwijzingen hier en verder in dit boek ongewijzigd. Werk je aan producten anders dan software, vervang dan telkens software door jouw eigen product.

De vier waarden van het Agile Manifest

Het Agile Manifest is het resultaat van ervaring, niet van theorie. Probeer je bij de volgende beschreven waarden telkens af te vragen wat het betekent als je ze in de praktijk omzet. Hoe helpen deze waarden bij introductietijden, veranderingen en innovaties?

Waarde 1: Mensen en hun onderlinge interactie boven processen en hulpmiddelen

Wanneer je ervoor zorgt dat elke interactie zich concentreert op het oplossen van problemen, dan kan een gemeenschappelijk doel ontstaan. Zo kunnen in een eenvoudig gesprek in weinig tijd veel verschillende problemen worden opgelost. De kracht van een direct gesprek is met e-mails, spreadsheets en documenten nauwelijks te benaderen.

Als processen en hulpmiddelen gezien worden als de manier om productontwikkeling te managen, dan zijn de mensen en hoe zij werken ondergeschikt aan deze processen en hulpmiddelen. En dat maakt het moeilijk om nieuwe ideeën, vereisten of nieuw denken te integreren.

Waarde 2: Werkende software boven allesomvattende documentatie

De focus van een ontwikkelteam moet liggen op het produceren van werkende producten. Voor software betekent een werkend resultaat dat de software aan de definitie van voltooid voldoet: de software is ten minste ontwikkeld, getest, geïntegreerd en gedocumenteerd. Het werkende product is immers de hele reden voor het project.

Alle projecten hebben een bepaalde mate aan documentatie nodig. In agile projecten is documentatie echter alleen zinvol als het net voldoende is om het ontwerp, de oplevering en de implementatie van een werkend product te dienen, dus direct en zonder poespas is.

In agile projectmanagement is de term net voldoende een positieve beschrijving die aangeeft dat een taak, document, bespreking of een ander onderdeel van het project alleen datgene omvat wat nodig is om de projectdoelen te verwezenlijken. Net voldoende is praktisch en efficiënt. Het tegendeel van net voldoende is vergulden: het toevoegen van overbodige frivoliteiten en inspanning aan een functie, taak, document, bespreking of iets anders.

Waarde 3: Samenwerking met de klant boven contractonderhandelingen

In agile methodologieën is de klant constant onderdeel van het project. In de praktijk betekent dit een samenwerking tussen de klant en het ontwikkelteam waarin het routine en gewenst is om tijdens een project te ontdekken, te vragen, te leren en bij te stellen.

Waarde 4: Inspelen op verandering boven het volgen van een plan

Verandering is een waardevol hulpmiddel voor het creëren van fantastische producten. Projectteams die snel kunnen reageren op klanten, gebruikers en de markt, zijn in staat relevante producten te ontwikkelen die mensen graag willen gebruiken. In traditionele projectteams volgen de leden vaak blind het plan en missen zo de kans nog waardevollere producten te creëren.

Nieuwe gebeurtenissen worden door het projectteam in het lopende project geïntegreerd. De veranderingen kunnen zo waarde aan het project toevoegen, vergroten de kans op slagen en zijn niet langer een te vermijden hindernis.

De twaalf agile principes gedefinieerd

In de maanden na de publicatie van het Agile Manifest bleven de originele ondertekenaars met elkaar in contact. Ze vulden de vier waarden van het Agile Manifest aan met twaalf agile principes om teams zo te helpen bij de overstap naar agile.

Dit zijn de originele twaalf agile principes zoals die in 2001 door de Agile Alliance werden gepubliceerd:

1.    Onze hoogste prioriteit is het tevredenstellen van de klant door het vroegtijdig en voortdurend opleveren van waardevolle software.

2.    Verwelkom veranderende behoeften, zelfs laat in het ontwikkelproces. Agile processen benutten verandering tot concurrentievoordeel van de klant.

3.    Lever regelmatig werkende software op. Liefst iedere paar weken, hooguit iedere paar maanden.

4.    Mensen uit de business en ontwikkelaars moeten dagelijks samenwerken gedurende het gehele project.

5.    Bouw projecten rond gemotiveerde individuen. Geef hun de omgeving en ondersteuning die ze nodig hebben en vertrouw erop dat ze de klus klaren.

6.    De efficiëntste en effectiefste manier om informatie te delen in en met een ontwikkelteam is door met elkaar te praten.

7.    Werkende software is de belangrijkste maat voor voortgang.

8.    Agile processen bevorderen constante ontwikkeling. De opdrachtgevers, ontwikkelaars en gebruikers moeten een constant tempo eeuwig kunnen volhouden.

9.    Voortdurende aandacht voor een hoge technische kwaliteit en voor een goed ontwerp versterken agility.

10. Eenvoud, de kunst van het maximaliseren van het werk dat niet gedaan wordt, is essentieel.

11. De beste architecturen, eisen en ontwerpen komen voort uit zelfsturende teams.

12. Op vaste tijden onderzoekt het team hoe het effectiever kan worden en past vervolgens zijn gedrag daarop aan.

Maar je kunt deze twaalf agile principes ook anders bekijken, namelijk vanuit het oogpunt van klanttevredenheid, kwaliteit, teamwerk en projectmanagement.

Agile principes voor klanttevredenheid

Agile focust zich op klanttevredenheid, wat logisch is. De klant is immers de hele reden waarom je het product in de eerste plaats ontwikkelt. Hoe zet je deze principes om? Doe eenvoudig het volgende:

Agile projectteams bevatten altijd een producteigenaar, een persoon die verantwoordelijk is voor de vertaling van de wensen van de klant naar productvereisten.

De producteigenaar kent op basis van de marktwaarde of het risico prioriteiten toe aan productfuncties en communiceert deze prioriteiten naar het ontwikkelteam. Het ontwikkelteam levert de waardevolste functies op de lijst in korte ontwikkelcycli, bekend als iteraties of sprints, op.

De producteigenaar is elke dag intensief bij de ontwikkeling betrokken.

Regelmatig opleveren van werkende functionaliteit geeft de producteigenaar en de klant een goed idee van de ontwikkeling van het product.

De waarde en functionaliteit van het complete product groeit met de complete en toonbare functies die het ontwikkelteam elke maximaal acht weken (optimaal elke vier weken) oplevert.

De klant ontvangt regelmatig rendement op zijn investering, in de vorm van een voortdurende stroom nieuwe functies, zonder dat hij tot het einde van een mogelijk zeer langdurend project moet wachten, voordat hij de eerste resultaten kan terugverwachten.

Agile biedt verschillende strategieën voor het vergroten van de klanttevredenheid:

Produceer bij elke iteratie allereerst de functies met de hoogste prioriteit.

Indien mogelijk, zet dan de producteigenaar en de andere teamleden op dezelfde plek samen.

Splits de gewenste functionaliteit op in blokken die in maximaal acht weken (ideaal is vier weken) opgeleverd kunnen worden.

Houd geschreven vereisten beperkt en zorg voor robuuste en effectieve persoonlijke communicatie.

Verkrijg de goedkeuring van de producteigenaar voor elke afgeleverde functie.

Neem de lijst met de gewenste functionaliteit regelmatig door, om ervoor te zorgen dat de belangrijkste functies de hoogste prioriteit hebben.

Agile principes voor kwaliteit

Een agile projectteam streeft naar kwaliteit in elk product dat het maakt, van ontwikkeling via documentatie tot testresultaten, en dat elke dag. In de dagelijkse praktijk kun je deze principes als volgt uitleggen:

De leden van het ontwikkelteam moeten volledig eigenaar zijn en de zeggenschap hebben om problemen op te lossen.

Agile softwareontwikkeling vergt agile structuren die het programmeren modulair, flexibel en uitbreidbaar maken. Het ontwerp moet aansluiten op de actuele problemen en tegelijkertijd toekomstige veranderingen zo eenvoudig mogelijk maken.

Elke voltooide functie kan aan de producteigenaar getoond worden, zodat deze zelf kan beoordelen of de nieuwe functie aan zijn wensen voldoet.

Aan het einde van elke maximaal acht weken (vier weken is optimaal), wordt een werkend product aan de klant gedemonstreerd.

Testen is een integraal onderdeel van de ontwikkeling en vindt dagelijks plaats, niet alleen aan het einde van een iteratie.

Nieuwe code wordt regelmatig of zelfs meerdere keren per dag gecontroleerd op compatibiliteit met eerdere versies, fouten en juiste functionaliteit. Dit proces van continue integratie (CI) garandeert dat de hele toepassing blijft werken terwijl nieuwe code aan de bestaande basis wordt toegevoegd.

In softwareprojecten omvat technische excellentie het vastleggen van standaarden, een goed onderhoudbare architectuur, geautomatiseerd testen en ontwikkelen voor toekomstige veranderingen.

Agile benaderingen bieden de volgende strategieën voor kwaliteitsmanagement:

Definieer aan het begin van het project wat ‘voltooid’ betekent en gebruik deze definitie als toetssteen voor kwaliteit.

Test agressief en dagelijks met geautomatiseerde hulpmiddelen.

Ontwikkel alleen de functies die nodig zijn en wanneer ze nodig zijn.

Herzie en optimaliseer de programmacode (‘refactoren’).

Demonstreer alleen werkende code die door de producteigenaar is geaccepteerd.

Richt gedurende de dag, iteratie en het project meerdere feedbackmomenten in.

Agile principes voor teamwerk

Het maken van goede producten vereist dat alle leden van het projectteam samenwerken, inclusief de klanten en belanghebbenden. Agile benaderingen ondersteunen teamwerk en leggen de nadruk op vertrouwen in zelfsturende ontwikkelteams. Hier zijn enkele manieren waarop je deze visie van teamwerk kunt verwezenlijken:

Agile benaderingen vereisen vaardige, goed opgeleide en gemotiveerde teamleden.

Geef training die aansluit op de uit te voeren taak.

Ondersteun de zelfsturing van het ontwikkelteam, in plaats van managers te laten vertellen wat het team moet doen.

Stel het ontwikkelteam als geheel verantwoordelijk voor het resultaat, niet afzonderlijke individuen.

Gebruik persoonlijke gesprekken om informatie snel en efficiënt over te dragen.

Hoe dichter de teamleden bij elkaar in de buurt werken, des te duidelijker en efficiënter de communicatie zal zijn.

Na elke iteratie is het tijd voor een terugblik, ook wel ‘retrospectief’ genoemd, waarin reflectie en aanpassing het team verder helpen op weg naar nog meer efficiëntie.

De volgende strategieën ondersteunen effectief teamwerk:

Huisvest het hele ontwikkelteam op dezelfde plek, dit is ook bekend als colocatie.

Zorg voor een fysieke werkomgeving die bijdraagt aan de samenwerking: een teamruimte met whiteboard, gekleurde pennen en andere fysieke hulpmiddelen voor het uitwerken en communiceren van ideeën.

Zorg voor een omgeving waarin teamleden aangemoedigd worden eerlijk en open te spreken.

Probeer elkaar zo veel mogelijk persoonlijk te spreken.

Zorg onmiddellijk voor duidelijkheid.

Moedig het ontwikkelteam aan zelf problemen op te lossen, in plaats van managers de problemen voor het ontwikkelteam op te laten lossen.

Agile principes voor projectmanagement

Een agile benadering richt zich op het plannen en uitvoeren van het werk dat nodig is om het best mogelijke product op te leveren. Dit wordt ondersteund door open te communiceren, afleidingen te vermijden en door ervoor te zorgen dat de voortgang van het project voor iedereen duidelijk is. Dit zijn enkele van de voordelen van agile voor projectmanagement:

Agile projectteams kunnen producten sneller naar de markt brengen, tegen een lager bedrag. Er kan veel vroeger met de feitelijke ontwikkeling worden begonnen, omdat in een agile benadering de omvangrijke voorafgaande plannings- en documentatiefasen van traditionele projecten geminimaliseerd worden.

Agile ontwikkelteams zijn zelfsturend en managen zichzelf. De managementenergie kan besteed worden aan het verwijderen van hindernissen en afleidingen.

Agile ontwikkelteams bepalen hoeveel werk ze in een iteratie kunnen afronden en leggen zich vast op deze doelen.

Een agile benadering stelt steeds de vraag wat minimaal nodig is om het doel te bereiken, in plaats van alle mogelijke functies tegelijkertijd proberen te ontwikkelen.

Door de ontwikkeling in korte sprints van bij voorkeur vier weken op te delen, kun je je blijven concentreren op de huidige iteratie, terwijl veranderingen een plek in volgende iteraties kunnen vinden.

Het plannen, uitwerken van vereisten, ontwikkelen, testen en demonstreren gebeurt steeds binnen de grenzen van een iteratie, wat het risico verkleint dat de ontwikkeling de verkeerde weg inslaat of er iets wordt ontwikkeld waar de klant niet om vroeg.

Prioriteiten, ervaringen uit eerdere projecten en de verwachte ontwikkelsnelheid helpen een goede inschatting te maken van wat bereikt kan worden in een bepaalde periode.

De volgende factoren dragen bij aan het projectmanagement:

het produceren van net voldoende documentatie;

levering van altijd actuele statusinformatie aan het ontwikkelteam;

het minimaliseren van taken die niet aan de eigenlijke productontwikkeling bijdragen;

het creëren van een omgeving waarin verandering normaal en goed is;

het werken met just-in-timevereisten om zo verstoringen en verspilling door veranderingen te minimaliseren;

het samenwerken met het ontwikkelteam voor realistische tijdsplanningen en doelen;

het beschermen van het ontwikkelteam tegen verstoringen uit de organisatie die met ongerelateerd werk de projectdoelen zouden kunnen ondermijnen;

begrijpen dat een goede balans tussen werk en leven een ingrediënt voor efficiënte ontwikkeling is.

De aanvullende platina principes

Op basis van mijn praktijkervaring in het werken met teams die overstappen op agile en de dagelijkse agile inspanningen van grote, middelgrote en kleinere organisaties, heb ik drie aanvullende principes voor agile softwareontwikkeling opgesteld die ik de platina principes noem. Deze zijn: het minimaliseren van formaliteit, denken en handelen als team en het visualiseren in plaats van schrijven.

Minimaliseren formaliteit

Zelfs het beste agile team kan geleidelijk in formaliteit verzanden. Dit zijn enkele strategieën die helpen formaliteit te voorkomen:

Reduceer hiërarchie in de organisatie door functietitels in het projectteam te vermijden.

Voorkom esthetische investeringen in omvangrijke powerpointpresentaties of uitgebreide notulen en leer en instrueer belanghebbenden over de kosten die dergelijke gecompliceerde esthetische vertoningen met zich meebrengen.

Denken en werken als team

In een agile omgeving moet het hele team op één lijn staan. Dit zijn enkele strategieën die helpen als team te denken en te werken:

Ontwikkel in paren en wissel vaak van partner.

Vervang individuele functietitels door een algemene titel ‘productontwikkelaar’.

Rapporteer uitsluitend op het niveau van het complete projectteam, zonder het team onder te verdelen.

Vervang individuele prestatiecijfers door prestatiecijfers van het complete team.

Visualiseren in plaats van schrijven

Een team moet zoveel mogelijk proberen te visualiseren, of dat nu met eenvoudige diagrammen of met modelleringsprogramma’s is. Afbeeldingen zijn krachtiger dan woorden. Met een diagram of schets in plaats van een tekstdocument kan je klant zich beter inleven in een concept en de inhoud. Dit zijn enkele strategieën voor visualisatie:

Zorg voor ruim voldoende whiteboards, schetsblokken, stiften en pennen, zodat alle gereedschappen altijd bij de hand zijn.

Gebruik modellen in plaats van tekst om concepten te communiceren.

Rapporteer de projectstatus met schema’s, diagrammen en dashboards.