Veel IT-projecten hebben te kampen met deadlines die niet worden gehaald. Dit heeft niet alleen tot gevolg dat de kosten van deze projecten hoger uitvallen dan geraamd, ook de relatie met de opdrachtgever kan op scherp komen te staan. Aan de techniek ligt het niet; iedere nieuwe versie van i5 zit weer boordevol nieuwe mogelijkheden. De belangrijkste oorzaak van deze problemen zijn vastgeroeste opvattingen over de wijze waarop software ontwikkeld wordt. De vlieger ‘Als je doet wat je altijd deed, dan krijg je wat je altijd kreeg’ gaat ook hier op.

door Wim van den Heuvel
Wim.vanden.Heuvel@Capgemini.com

Sequentieel ontwikkelen: hoge kosten en weinig flexibiliteit. Een buitenstaander mag dat niet, maar nu we als Power Business Magazine-lezers ‘onder ons’ zijn durf ik rustig te zeggen dat de i5-wereld behoudend is in de adoptie van nieuwe technologie; liever blijven wij doen wat we altijd deden. Ondanks Rational Application Developer wordt er ontwikkeld met PDM en SEU, en ondanks de System i Navigator tikken we het commando ‘WRKACTJOB’ nog steeds vanaf de commandoregel in. En wat belangrijker is, sequentiële software ontwikkelmethoden als SDM en ISAC blijven onverminderd populair. Kenmerkend voor deze methoden is de volgordelijke aanpak van de ontwikkelfasen, waarbij de volgende fase pas start als de voorgaande is afgerond.

Documentatie
Ontwerpers en analisten beschrijven requirements in documenten en modellen. Binnen een consistente architectuur lijken veel van deze documenten en modellen op elkaar en zijn daarom feitelijk overbodig. Bovendien gaat een deel van deze documentatie rechtstreeks het archief in, omdat de ontwikkelaar het ontwerp alleen raadpleegt als de ontwerper niet persoonlijk aanspreekbaar is. Daarnaast is inspelen op wijzigingen lastig. Wijzigingsverzoeken worden gezien als een inbreuk op het ontwikkelproces. Het ontwikkelteam wordt afgeschermd van de buitenwereld (lees: vervelende klanten), en er worden complexe procedures bedacht om wijzigingsverzoeken te voorkomen. Feitelijk is dit een vreemde verschuiving van prioriteiten waarin het proces centraal staat in plaats van de klant. Dat ook klanten in een dynamische wereld leven en het begrip ‘voortschrijdend inzicht’ kennen wordt daarmee teniet gedaan, en zo gaat een aanzienlijk deel van de investering vanuit de klant gezien in rook op…

Afbeelding 1: Waterval

Lagere kosten, meer flexibiliteit
Agile Software Development belooft een meer effectieve aanpak, gekenmerkt door meer transparantie, hogere productiviteit en betere klanttevredenheid. Opgeteld zijn dit aspecten die leiden tot essentiële kostenbesparingen. De uitgangspunten van agile zijn verwoord in het ‘Agile Manifesto’ (zie afbeelding 2). Verschillende methodieken geven ieder op een eigen wijze invulling aan deze uitgangspunten. Voorbeelden zijn Dynamic Systems Development Method (DSDM), Extreme Programming (XP) en Scrum. Het Rational Unified Process (RUP) is eveneens populair, maar het gevaar van RUP met zijn vele rollen en artefacts is dat alsnog het proces in plaats van de klant centraal staat. Hierop wordt ingesprongen door methodieken als OpenUP, waarin RUP wordt ontdaan van alle optionele componenten. Nog steeds RUP, maar meer agile!

Afbeelding 2: Agile Manifesto

In de praktijk
Sleutelwoorden in agile projecten zijn veranderbereidheid, samenwerking, gedeelde verantwoordelijkheid en eenvoud. Met name dat laatste punt wordt nog wel eens uitgelegd als ‘vrijheid blijheid’, maar zoals altijd kan vrijheid pas blijheid worden als iedereen zich aan de regels houdt. Kenmerkend voor agile-projecten is dat het project in meerdere iteraties (sprints) wordt uitgevoerd. Op basis van de requirements wordt een schatting gemaakt van de hoeveelheid werk en wordt de prioriteit van de onderdelen bepaald. Bij het toekennen van prioriteiten wordt rekening gehouden met verschillende invalshoeken. Zo is het vanuit de klant gezien logisch dat de requirements met de hoogste business value de hoogste prioriteit krijgen, maar vanuit het ontwikkelteam kunnen argumenten worden aangedragen om eerst mogelijke technische obstakels uit de weg te ruimen. Op basis van deze input kan worden bepaald hoeveel iteraties er gepland worden en hoe de uit te voeren werkzaamheden over de iteraties verdeeld worden. Deze planning wordt niet in beton gegoten; er wordt rekening mee gehouden dat in de loop van het proces om diverse redenen wijzigingen in de planning zullen optreden.

Iteraties
In iedere iteratie vinden de activiteiten Analyse, Ontwerp, Implementatie en Test plaats. Deze activiteiten worden binnen de iteratie zelf uitgevoerd, waarbij het binnen de iteratie geplande werkpakket centraal staat. Na afloop van iedere iteratie wordt wat is ontwikkeld aan de klant gedemonstreerd of daadwerkelijk opgeleverd. Omdat pas aan het begin van een iteratie het werkpakket definitief wordt vastgesteld, zijn wijzigingen in de planning relatief eenvoudig te implementeren. Het team bouwt altijd de componenten met de hoogste prioriteit. Dit brengt de zo gewenste agility (lenigheid) in het project, en verhoogt de business value van de geleverde software. De kans is groot dat zelfs als het project tussentijds wordt afgeblazen de eerder opgeleverde (beperkte) set functionaliteit voor de klant al bruikbaar is.

Multidisciplinaire teams
Agile Development maakt gebruik van multidisciplinaire teams die veel verantwoordelijkheid krijgen. Het team implementeert niet alleen de requirements, maar denkt mee in de vaststelling van de prioriteiten en inschatting van de benodigde ontwikkeltijd. Op basis van deze schatting wordt het werkpakket voor deze iteratie bepaald, waarbij de duur van de iteratie vaststaat. Zeer frequent (liefst iedere dag) is er een kort overleg waarbij ieder teamlid aangeeft wat hij tot dusver heeft gedaan, wat hij tot aan het eerstvolgende overleg denkt te gaan doen en welke obstakels hem daarbij in de weg staan. Voortgang wordt gemeten op basis van opgeleverde software en nog te besteden uren. Deze gedeelde verantwoordelijkheid draagt bij aan de betrokkenheid van het team.

Rolverdeling
Binnen een team zijn drie rollen te onderscheiden:

1. Ontwikkelaar
Alle technische vaardigheden die noodzakelijk zijn om het binnen deze iteratie gewenste resultaat te bereiken zijn binnen het team vertegenwoordigd. Voor een volgende iteratie kan een ander team worden samengesteld, hoewel het streven is de teamsamenstelling niet te vaak te wisselen.

2. Team- of projectleider
In traditioneel uitgevoerde projecten is de projectleider bezig met het vervaardigen van rapporten waarin het verleden wordt weergegeven in de vorm van bestede uren per teamlid. Dit biedt schijnzekerheid; of er al dan niet voortgang wordt gemaakt is niet zichtbaar. In agile projecten maakt de projectleider deel uit van het team. De nadruk van zijn werkzaamheden ligt meer op het ‘dienende’ dan op het ‘sturende’ doordat hij eventuele obstakels in het ontwikkelproces uit de weg ruimt. In zijn rapportages ligt de focus op het heden doordat de gerealiseerde functionaliteit wordt weergegeven, en zichtbaar wordt met welke investering het resterende deel verwezenlijkt kan worden.

3. Klant / Afgevaardigde
In agile projecten staat de klant (de opdrachtgever) centraal. Bij de samenstelling van het team wordt dan ook niet alleen gekeken naar de juiste mix van technische en organisatorische vaardigheden, de belangen van de klant worden gewaarborgd doordat hij (of een afgevaardigde) deel uitmaakt van het team. Deze persoon dient voldoende mandaat te hebben om belangrijke beslissingen te kunnen nemen uit naam van de klant. Dit maakt het mogelijk eventuele wijzigingen tijdens het teamoverleg ter tafel te brengen. Omdat alle belanghebbenden vertegenwoordigd zijn wordt snel zichtbaar welke impact voorgestelde wijzigingen hebben, en ten koste waarvan deze wijzigingen geïmplementeerd kunnen worden. Er kunnen direct spijkers met koppen geslagen worden. Dit garandeert een hoge mate van betrokkenheid en een frequente terugkoppeling, zodat de klant op ieder moment weet hoe de zaken er voor staan.

Naast de drie genoemde rollen zijn er meer belanghebbenden, maar die hebben geen stem in belangrijke beslissingen. In hoeverre een belanghebbende daadwerkelijk betrokken is en een stem heeft, wordt in Scrum ludiek aangegeven door een gesprekje tussen een Pig en een Chicken, waarin de teamleden door de Pigs en de overige betrokkenen door de Chickens worden gerepresenteerd (zie afbeelding 3).

Afbeelding 3: Betrokkenheid

Agile en XP
Methodieken als Srum of DSDM zeggen iets over de ontwikkelprocessen en over de organisatie rondom een project, maar laten de teams vrij in hoe het werk moet worden uitgevoerd. Extreme Programming (XP) vult deze leemtes op. Software Development op basis van eenvoud, korte communicatielijnen en continue feedback. Het blijft bij XP niet bij mooie woorden. Er wordt daadwerkelijk aangegeven hoe deze begrippen invulling te geven. Begrippen als Test Driven Development, Pair Programming, Collective Ownership en Continuous Integration vormen de basis van XP. Na afloop van iedere iteratie wordt teruggeblikt. Wat ging goed, wat kan beter? Dat geldt niet alleen voor het ontwikkelproces maar voor alle aspecten daaromheen, zoals de gemaakte inschattingen en de samenwerking tussen de teamleden. In een volgende iteratie zal het team actief proberen deze obstakels uit te weg te ruimen. Deze aanpak zorgt ervoor dat het team iedere iteratie een uitdaging heeft en kan groeien.

Agile is een mindset
Agile Development is geen rocket science. Tools die dit proces ondersteunen zijn belangrijk, maar veel belangrijker is de mindset van de organisatie en haar medewerkers. De kans op succesvolle projecten is klein als redenen als ‘het werkt dus waarom zouden we veranderen’ worden gebruikt om vernieuwing tegen te houden, en ook het afschermen van het ontwikkelproces voor wijzigingen vanuit de klant getuigt niet van de juiste agile mindset. Veranderbereidheid is cruciaal voor het welslagen van projecten, misschien zelfs wel voor het overleven van de gehele organisatie in deze moeilijke tijden. Alleen met de juiste instelling en het juiste kennisniveau kan agile de gedane beloftes waarmaken! Meer over agile en Scrum kunt u vinden via onderstaande URL’s. Als u echter in één avond van niemand minder dan Jeff Sutherland (de bedenker van Scrum) wilt horen hoe u in uw organisatie agile concepten kunt toepassen kunt u zich ook inschrijven voor het Scrum-seminar van Capgemini BAS, dat plaats vindt op donderdagavond 5 maart. Ik zie u daar graag terug!

Wim van den Heuvel is docent en technical consultant voor Java Business Solutions, een onderdeel van Getronics PinkRoccade. U kunt hem bereiken via Wim.vanden.Heuvel@Capgemini.com.