Voor u gelezen: Becoming Agile

Voor U gelezen: Becoming Agile: … in an imperfect world
Greg Smith, Ahmed Sidky
Manning Publications, 2009
Print ISBN: 978-1-933988-25-2
Web ISBN: 1-933988-25-8

Gelezen: de online versie

Hieronder een korte samenvatting per hoofdstuk. Als je het hele boek wilt lezen: de bibliotheek heeft nog geen exemplaar, maar we kunnen er natuurlijk eentje bestellen.

 1. Wat is Agile en waarom zou je dat willen worden?
De ervaring leert dat projecten waarin software (websites, apps) gemaakt wordt vaak langer duren dan gedacht en dat ze aan het eind niet leveren wat de klant in gedachten had. Ook komt het vaak voor dat een klant pas in de loop van het project weet wat hij echt wil en dat er dan van alles aangepast moet worden.
Agile is een manier om hiermee om te gaan.

De basisideeën van Agile zijn:

•   lever iets op waar de klant iets aan heeft
•   betrek de klant bij het hele proces
•   lever regelmatig een werkend product
•   accepteer dat dingen veranderen
•   doe precies genoeg
•   leg de nadruk op samenwerking
•   het hele team doet mee

2. Inleiding over de casus die ze in de loop van het boek gaan uitwerken
De casus betreft een bestaande organisatie die niet tevreden is over hoe hun projecten nu lopen (te laat af, ontevreden klanten).

3. Hoe begin je?
Het idee is dat Agile worden ook kan als iteratief proces. Je begint met een paar mensen en kleinere projecten en breidt dat langzaamaan uit. Voor bestaande organisaties is dat meestal een betere manier dan van de ene dag op de andere alles Agile te gaan doen.

4. Een assessment tool
Om te zien welke aspecten van je organisatie wel of juist niet kunnen bijdragen om Agile te worden, kun je een methode gebruiken die de auteurs van het boek uitgevonden hebben. Dit kijkt naar zaken als organisatiecultuur, managementstijl en hoe open de communicatie is. Het zou interessant zijn die tool eens los te laten op de bibliotheek, als er een paar mensen zijn die daar tijd (en zin) voor hebben.

5. Het belang om het management mee te krijgen
De eerste paar Agile projecten kosten evenveel of zelfs meer tijd dan projecten op de oude manier, omdat iedereen nog moet wennen. Management moet daarom overtuigd zijn van het nut, anders zullen ze al gauw zeggen dat Agile niet deugt. Bovendien moeten ze bereid zijn hun medewerkers tijdens een project een groot deel van hun tijd “uit te lenen”. Dit laatste speelt vooral bij afdelingen waar mensen het project moeten uitvoeren naast hun reguliere werk.

6. Core team: begin met een groepje enthousiaste mensen
Zorg dat een paar mensen uit diverse afdelingen kennis verwerven over Agile. Zij kunnen die kennis en hun enthousiasme overdragen op hun collega’s.

7. Wat Agile betekent voor je manier van leidinggeven
Een Agile projectleider maakt dingen mogelijk, maar neemt zo min mogelijk beslissingen. Die beslissingen moet namelijk uit het projectteam komen. Dat betekent natuurlijk ook dat het team beslissingen moet durven nemen.

8. Hoe maak je je huidige manier van werken meer Agile
Besef dat je niet in één keer helemaal Agile kan worden. Alles gaat in stapjes. Probeer ook niet een kant-en-klare methode (zoals Scrum) te gebruiken zonder enige aanpassing. Je moet altijd kijken wat mogelijk en nuttig is in je eigen organisatie.

9. Kies een pilot project
Een pilot project moet redelijk kort zijn. Het boek noemt 8 weken als grens, maar voor de bibliotheek is dat waarschijnlijk niet realistisch voor een pilot. Dus het kunnen ook een paar weken meer zijn. Als er maar een harde deadline wordt gesteld. Ook moet het project redelijk belangrijk zijn, anders heb je kans dat je projectleden er niet genoeg tijd voor krijgen.

10. Haalbaarheidsonderzoek voor je project
In de eerste paar dagen van je project onderzoek je de haalbaarheid. Op basis daarvan beslis je of het zin heeft om door te gaan. Als die beslissing al eerder is genomen, bijvoorbeeld door het management, dan kun je deze fase gebruiken om risico’s in kaart te brengen en eventueel de scope van het project aan te passen.

11. Stel je pilot-projectteam samen en betrek ze bij het project
Het projectteam voor je pilot zal deels bestaan uit leden van het core team (dus mensen die al wat van Agile weten) en deels uit mensen voor wie Agile nieuw is. Zorg in ieder geval dat er mensen uit verschillende afdelingen in zitten.

Roep het hele team bij elkaar en bespreek samen het project. De nadruk ligt op “samen”. Schrijf bijvoorbeeld met zijn allen een “elevator pitch” voor het project. De bedoeling is dat iedereen zich verantwoordelijk gaat voelen voor het project.

12. Feature cards
Een “feature card” bevat een globale beschrijving van een stukje functionaliteit van je product. Hierbij schrijf je een globale schatting van hoeveel werk het is (veel, weinig, gemiddeld) en welke afhankelijkheden en onzekerheden er zijn. In een later stadium gebruik je diezelfde kaarten om per “feature” vast te leggen welke werkzaamheden er voor nodig zijn. Het maken van deze kaarten doe je bij voorkeur met het hele projectteam en in ieder geval met de klant erbij.

13. Prioritering
Plaats je feature cards in de volgorde waarin ze uitgevoerd moeten worden. Het makkelijkst gaat dat met fysieke kaarten en groot prikbord, maar als het moet kan het ook elektronisch. De klant heeft hier natuurlijk een belangrijke stem in (hij weet immers wat voor hem het belangrijkst is), maar ook de rest van het team kan meebeslissen. Bijvoorbeeld als ze zien dat een onderdeel pas gemaakt kan worden als er een nieuwe versie van een onmisbaar pakket is, of als ze weten dat de mensen voor een onderdeel alleen in een bepaalde periode beschikbaar zijn.

14. Tijdschattingen
Opdrachtgevers willen altijd weten hoeveel (ontwikkel)tijd iets gaat kosten en ontwikkelaars zeggen altijd dat ze dat nog niet kunnen inschatten. Het boek beschrijft een iteratieve methode. Maak een urenschatting voor de features die je als eerste gaat maken. Die urenschatting zit er misschien ver naast, maar doe je best. Aan het eind van je eerste iteratie vergelijk je de daadwerkelijk gemaakte uren met je schatting. Op basis daarvan pas je de schattingen voor de volgende iteratie aan. Hoe vaker je dat doet, hoe beter je wordt in urenschattingen.

15. Projectplanning op hoofdlijnen
Bepaal de lengte van je iteratie. Het boek raadt 2-4 weken aan, waarbij testen niet in de iteratie zelf gebeurt. Tussen twee iteraties plan je dan een week voor testen, terugkijken en het plannen van je volgende iteratie.

Verdeel nu je features over je iteraties, op basis van prioriteiten en urenschattingen.
Als voor een feature meer uren geschat zijn dan er in een iteratie beschikbaar zijn, probeer de feature dan in stukken te verdelen (bijvoorbeeld “in de eerste iteratie moet de achterkant klaar zijn, in de tweede iteratie de publiekskant”). Bedenk dat niet-software werk zoals “maak een schermindeling” en “maak testvragen” ook een taak is, waarvoor dus ook tijd moet zijn in de iteratie.

16. Plan een iteratie
Begin met het vastleggen van de acceptatiecriteria van elk feature dat je in deze iteratie gaat maken: waaraan moet het feature voldoen om “klaar” te zijn.

Bepaal dan het werk dat gedaan moet worden. Soms is één zin genoeg (“gebruiker moet federatief kunnen inloggen”), soms zul je eerst een globaal ontwerp moeten maken. Doe wat nodig is om het werk duidelijk te krijgen.

Het kan heel goed zijn dat blijkt dat iets toch ingewikkelder is dan je eerst dacht, dus pas waar nodig je urenschatting aan en controleer of het nog steeds allemaal zou moeten kunnen in deze iteratie. Zo niet: pas je planning aan.

17. Iteratie 0: de voorbereiding voor je eerste iteratie
Terwijl je je eerste iteratie plant, moet je er ook voor zorgen dat je straks aan het werk kunt. Dat betekent dat de technische infrastructuur er moet zijn (misschien moet ICT eerst iets installeren) en dat er afspraken worden gemaakt over zaken als “hoe regelen we overleg” en “hoe melden we bugs aan”.

18. Lever werkende software
Spreek af dat ontwikkelaars regelmatig (liefst elke dag) hun nieuwe code op de testsite zetten, waar de klant het kan zien. Zo kan de klant gelijk feedback geven.
Laat de projectleden, in ieder geval de ontwikkelaars, alleen aan dit project werken, zodat ze er alle tijd voor hebben.

In principe mag iedereen in het project met de ontwikkelaars praten, maar maak daar afspraken over. De ene ontwikkelaar heeft minder last van zulke onderbrekingen dan de ander. Dus accepteer dat een ontwikkelaar kan zeggen “nee, nu niet” als je hem iets wil vragen.

19. Testen
De ontwikkelaars hebben hun eigen tests (liefst geautomatiseerd), die ze gebruiken tijdens een iteratie. Na afloop van een iteratie voeren de testers de acceptatietests uit voor de features die in die iteratie gemaakt zijn. Dit gaat op basis van de criteria die je bij het plannen van de iteratie hebt vastgelegd.

Het is ook een goed idee om ook mensen van buiten het project eens naar het product te laten kijken. Dat kan ook voordat het helemaal af is. Een frisse blik levert altijd nieuwe inzichten op.

20. Aanpassingen
Het is onvermijdelijk dat er in de loop van het project dingen aangepast moeten worden. Het komt bijvoorbeeld vaak voor dat een klant de eerste versie van iets ziet en dan beseft dat dit toch niet is wat hij wil. Dan moet je de requirements aanpassen, wat natuurlijk ook gevolgen heeft voor je planning. Bij Agile werken is dat geen probleem, omdat je planning niet lang van te voren vastligt. Je moet daarbij natuurlijk wel in de gaten houden binnen welke grenzen je moet blijven. Als een project voor een bepaalde datum af moet zijn, kan het nodig zijn om features te laten vervallen.

Het beste moment om aanpassingen te doen is in de week tussen twee iteraties. Organiseer aan het begin van die week demo’s voor je klant, zodat die gelijk feedback kan geven. Ook als een feature nog maar half af is, kun je een manier verzinnen om hem te demonstreren (bijvoorbeeld door te laten zien dat de juiste gegevens worden opgehaald, ook al is de lay-out van het resultatenscherm nog niet af).

21. Naar productie
In principe moet er aan het eind van elke iteratie een werkende versie zijn, die in theorie naar productie kan. In praktijk zal je product pas na een paar iteraties voldoende features bevatten om bruikbaar te zijn voor het publiek. Spreek aan het begin van het project af welke features minimaal nodig zijn om in productie te gaan (al kan dat in de loop van het project natuurlijk ook weer aangepast worden).

Vier een feestje zodra er een versie in productie is (dus niet pas weken later, als iedereen al weer met iets anders bezig is).

22. Terugkijken
Aan het eind van het project, en het liefst ook na elke iteratie, kijk je terug. Wat ging er goed? Wat kan beter? Zorg er voor dat deze terugblik leidt tot actiepunten. En kijk bij de volgende terugblik (in hetzelfde of een volgend project) of er ook iets met die actiepunten gedaan is.

Een praktische tip voor de terugblik: organiseer een bijeenkomst met alle projectleden en vraag iedereen om één of twee dagen daarvoor hun punten in te leveren. Dan kun je je op de bijeenkomst zelf concentreren op “hoe zorgen we dat het de volgende keer (nog) beter gaat”.

23. En hoe verder? Agile voor de hele organisatie
Hoera, je eerste pilot is een succes. Helaas wil dat niet zeggen dat de hele bibliotheek nu in één keer Agile zal worden. Dat zal in stapjes moeten gaan. Kijk bij de komende projecten welke geschikt lijken voor Agile (niet te lang of te kort, mogelijkheden om de klant er bij te betrekken). Bespreek met de projectleider en de opdrachtgever of een project Agile aangepakt kan worden. Zo zal Agile op den duur een gewoonte worden.

Het boek merkt op dat sommige aspecten van Agile ook kunnen worden toegepast bij werk dat niet binnen een Agile project valt. De auteurs geven een voorbeeld van hoe je die aspecten beetje bij beetje in je organisatie kunt introduceren, als het management dat wil.