CGI: Juiste dosis agile verbetert projectmanagement

07 januari 2014 Consultancy.nl

De beste ontwikkelaanpak kiezen is niet eenvoudig. Waar voorheen projectmanagers standaard kozen voor waterval, kiezen ze nu steeds vaker voor agile. De verschillen tussen waterval en agile lijken groot en fundamenteel. Watervallers en agilisten bediscussiëren elkaar hevig op diverse gebieden als: houding, aanpak, cultuur, principes, architectuur en practices. In dit artikel gaan Raymond Binnendijk en Michiel Nijhof, beide adviseurs bij CGI, dieper in op de agile software-ontwikkelaanpak. Is elke situatie geschikt voor agile? Welke dosis agility is de juiste?

Om antwoord te geven op deze vragen bespreken wij onderstaande stellingen waarmee we in de praktijk vaak geconfronteerd worden:

1. Alleen een pure waterval is geschikt voor projecten met een fixed price/fixed date/fixed scope.
2. Agile kan alleen als we met zijn allen in één ruimte zitten.
3. Agile kijkt alleen naar de korte termijn; is dus niet geschikt voor initiatieven met een lange looptijd.

Agile Project Management

Stelling 1:
Alleen een pure waterval is geschikt voor projecten met een fixed- price/-date/-scope.

Sales managers vertellen ons regelmatig dat de pure-waterval aanpak past bij een fixed price/fixed date/fixed scope contractvorm. 'Repel change', en niet 'Embrace change', een belangrijk fundament van agile, is hier de passende strategie. Daarnaast is ook de kwaliteit (non-functional requirements) fixed, wat weer goed aansluit bij de keuze zorgvuldig en uitgebreid te ontwerpen in de beginfase van het project (big-up-front-design, BUFD).

De praktijk leert ons echter dat de functionele en niet functionele eisen en wensen doorgaans veel minder fixed zijn dan verwacht. Er zijn namelijk vaak voortschrijvende inzichten die een aanpassing van de scope noodzakelijk maken.

Schat in of de kans op voortschrijdende inzichten groot is. Dit is traditioneel het geval bij maatwerksystemen met een hoge mate van gebruikersinteractie. Daarnaast geven ervaringen opgedaan uit soortgelijke projecten doorgaans een goede indicatie van de toekomst. Is de kans op voortschrijdende inzichten groot, bied dan de optie om in te spelen op veranderingen door een hoge mate van agility. Werk daarnaast een duidelijke Request For Change (RFC) procedure uit. Een change betekent namelijk een uitbreiding van de project scope met een zeer waarschijnlijke impact op prijs en planning. De klant en projectmanager komen daarom in actie, bijvoorbeeld door lage prioriteit functionaliteit te laten vervallen (uitruilen) of meer budget en tijd (verruimen op basis van een kosten/baten analyse).

CGI - Experiance the commitment

Stelling 2:
Agile kan alleen als we met zijn allen in één ruimte zitten.

Communicatie en samenwerking zijn zeer belangrijk voor softwareontwikkeling binnen teams. Zeker bij agile, gezien het dynamische karakter en het acteren als team in plaats van als individu. Communicatie en samenwerking verlopen veel makkelijker als je met elkaar in één ruimte werkt.

Een decentrale setting vraagt daarom aanvullende maatregelen. Zorg er bijvoorbeeld voor dat je met het hele team op alle teamlocaties bent geweest en dat je elkaar persoonlijk kent. Communiceer tijdens meetings niet alleen via de telefoon, maar ook via middelen als chat, webcam, wiki en video conference. Zorg dat je (ontwerp)afspraken vastlegt en inzichtelijk maakt op alle locaties.

Ten slotte: Pas bij decentrale teams korte iteraties toe. Korte iteraties bieden de mogelijkheid om met het team alle stappen in het voortbrengingsproces, en daarmee dus alle communicatiemomenten, te doorlopen, te meten en te bespreken, aanpassingen aan te brengen en vervolgens opnieuw in de praktijk te ondervinden wat het effect is. Vooral in een decentrale setting helpt dit bij het kiezen en trainen van manieren van communicatie en samenwerking.

CGI - IT Development

Stelling 3:
Agile kijkt alleen naar de korte termijn en is dus niet geschikt voor projecten of producten met een lange looptijd.

Agile staat bekend om de focus op één onderdeel van het product (user story) gedurende een beperkte tijd (sprint). Aan het eind van de sprint zijn de user-stories af en legt het team de focus op een volgende user-story. Dit hoeft niet te betekenen dat de user -stories die af zijn niet meer kunnen veranderen. De presentatie aan het einde van de sprint (sprint-demo) toont de gerealiseerde software aan de eindgebruiker (product owner). Hier ontstaan vaak nieuwe ideeën: zowel toevoegingen als aanpassingen op de reeds gebouwde functionaliteit. Nieuwe user-stories leggen deze aanpassingen vast, inclusief een globale impact analyse (kosten, risico’s en tijd).

Deze manier van werken, één sprint vooruitkijken, lijkt zeer op de korte termijn gericht. Toch wordt er wel degelijk aandacht besteed aan de lange termijn visie. De product backlog maakt dit mogelijk. Op deze backlog nemen we alle gewenste user stories op, inclusief status, impact indicatie en prioriteit. De product owner onderhoudt, ondersteund door het bouwteam, de werkvoorraad continu (backlog refinement). Dit stelt ons in staat om continu inzicht te hebben in de richting van het project, maar niet te vergeten ook in de progressie (backlog burndown). De consequentie is een beter product op langere termijn. Je bouwt niet meer wat de klant vraagt. Je bouwt wat de klant nodig heeft, gebaseerd op de meest actuele inzichten.

Naast functionaliteit en planning is een niet te onderschatten onderdeel van de lange termijn de kwaliteit (non-functional requirements). We zijn in staat user stories te veranderen of toe te voegen, maar zijn we ook in staat om de architectuur en de technical debt onder controle te houden? Hiervoor zijn onzichtbare productverbeteringen nodig. RCDA’s architectuur roadmapping en technical debt control [RCDA] bieden toepassingen die hier uitkomst bieden.

Raymond Binnendijk - Michiel Nijhof

In sommige situaties is één sprint vooruitkijken geen goede keuze, ondanks de aanvullende maatregelen zoals hierboven beschreven. De voordelen zijn alleen zichtbaar als er sprake is van deelbare en behapbare functionaliteit (incrementen). Gaat het om een beperkt aantal features die ook nog eens zeer complex zijn, dan is een hoger waterval gehalte (fasering met BUFD) een betere keuze.

Conclusie

De vraag is niet of een project agile of waterval moet zijn. Agile en waterval vertegenwoordigen de twee uitersten van een spectrum. Meer of minder agile is hier niet vanzelfsprekend beter of slechter. Zonder rekening te houden met de context is hier geen zinnige uitspraak over te doen. Wie goed kijkt naar succesvolle projecten ziet vaak een pragmatische mix van waterval en agile invloeden. De context bepaalt de optimale mix, los van de contractvorm, locatie spreiding of looptijd.

Een artikel van Raymond Binnendijk, principal solutions architect bij ICT-adviesbedrijf CGI, en Michiel Nijhof, Microsoft.NET software engineer bij CGI.

Nieuws