Home » Handboek projectmanagement » Voorwaarden voor agile projectmanagement

Voorwaarden voor agile projectmanagement

Om cyclisch projectmanagement te kunnen toepassen moet aan een aantal voorwaarden voldaan zijn:

1. Actieve betrokkenheid van gebruikers/klanten
Bij cyclisch projectmanagement vindt het opstellen van eisen- en wensen, het ontwerpen, realiseren en testen in elke cyclus plaats. Dat betekent dat er veel beslissingen genomen moeten worden in een cyclus. Om in staat te zijn de wensen van de klant goed te laten uitkomen in de software, moet de klant actief meedoen in het projectteam. Hij moet zo goed mogelijk zijn wensen uitleggen aan de programmeurs en ontwerpers. Men moet denken aan wekelijkse of minimaal tweewekelijkse aanwezigheid in het projectteam.

Klanten houden zich binnen het project bezig met het bepalen van de gewenste functionaliteiten en de planning van de cycli. Ze denken mee over de acceptatietests, ze keuren tussenresultaten goed of af en denken mee over de algemene richting van het project. Overigens geldt ook voor de watervalmethode dat een actieve opstelling van de klant tot betere resultaten leidt.

2. Team mag besluiten nemen
Binnen een cyclus moet het projectteam geautoriseerd zijn om dat te doen wat het denkt dat het beste is. Als het projectteam niet deze macht heeft, werkt het cyclische projectmanagementmodel niet. Wanneer er tijdens een cyclus constant autorisatie nodig is van meerderen, zal dit leiden tot stagnatie. Bovendien weten buitenstaanders vaak niet goed wat er speelt omdat ze niet actief deelnemen in het projectteam, wat het voor hen moeilijk maakt zinnige beslissingen te nemen.

3. Projectresultaat is opdeelbaar in kleinere delen
Bij agile projectmanagement worden delen van het project uitgevoerd in een aantal cycli. Dat kan alleen als het te realiseren projectresultaat opdeelbaar is in een aantal min of meer los van elkaar staande onderdelen, die onafhankelijk van elkaar ook veranderd kunnen worden. Dat kan meestal wel bij software ontwikkelingsprojecten, bij andere projectresultaten (zoals bijvoorbeeld grote infrastructuur projecten) is dat niet altijd het geval

4. Vanuit het management worden voornamelijk globale eisen ten aanzien van de software gesteld en niet direct concrete en specifieke eisen.
Een van de sterke punten van cyclisch projectmanagement is dat de klant, ontwerpers, programmeurs en eventueel testers nauw samenwerken binnen de cycli. Als er bij het project al direct in het begin heel specifieke en concrete eisen zijn gesteld aan de op te leveren software, dan belemmert dat de vrijheid van het projectteam om naar eigen inzicht ontwerpkeuzes te maken. Veel eisen aan een project blijken gaandeweg aangepast te moeten worden en moeten dus niet in het begin (te) vast liggen.

5. De activiteiten zijn voor de klant inzichtelijk
Als er binnen een cyclus veel technisch werk moet gebeuren, dat te moeilijk te begrijpen is voor de klant, bestaat er een risico dat hij niet in staat is goed mee te doen met het team. Hij heeft feitelijk niet veel in te brengen bij de ontwerp-beslissingen die genomen moeten worden.

Een dergelijk risico bestaat ook wanneer de voortgang voor de klant niet goed zichtbaar is. Bijvoorbeeld omdat er veel aan de code gewerkt is en minder aan de gebruikersinterface. Het is belangrijk dat de klant voldoende inzicht heeft in de inhoud en in de voortgang van een cyclus om ervoor te zorgen dat hij niet buiten spel komt te staan.

6. Een stap terug moet mogelijk zijn.
Ook bij agile projectmanagement bewandelt het team soms een weg, waarvan men later moet concluderen dat het niet de juiste was. Dan moet het mogelijk zijn om een stap terug te doen. Als een nieuwe module is gemaakt in een cyclus en het blijkt dat hij niet bevalt, moet de oude module terug in gebruik kunnen worden genomen. Dit stelt met name eisen aan de archivering en documentatie van de projectmaterialen. CVS (Concurrent Versioning Systeem) of Subversion zijn hier bijvoorbeeld een nuttig hulpmiddel voor (zie bijlage 3 voor een lijst van hulpmiddelen).

7. Programmeurs moeten naast programmeren ook kunnen communiceren met klanten en vice versa. Teamleden moeten in staat zijn conceptueel te denken. Discipline is nodig om het testgericht werken vol te houden. Hetzelfde geldt voor niet ICT agile teams.

8. De organisatie waarbinnen het project plaatsvindt moet ook voldoende steun bieden aan deze manier van werken. Systemen voor tijdschrijven, archivering en planning zijn nodig om de projecten te ondersteunen. Deze registratiesystemen zorgen voor de transparantie welke nodig is voor een goede verdeling van resources over de projecten en in de tijd.

9. Projecten moeten voldoende prioriteit hebben, teamleden moeten worden vrijgemaakt voor projecten. Het werkt niet als teamleden in veel projecten tegelijk moeten werken. Als een organisatie onvoldoende ingesteld is op het werken met projecten dan zal de lenigheid van agile projectmanagement eerder tot chaos leiden. Overigens is de watervalmethode ook gebaat bij een organisatie die ingesteld is op het werken met projecten (zie Wijnen, 2004, p. 111).

Een directeur van een softwarehuis die meer een visionair was dan een manager had bijna elke maand een goed idee en startte voortdurend nieuwe projecten in zijn bedrijf. Daardoor werden oude projecten nooit helemaal afgemaakt en deden de medewerkers soms wel vijf projecten tegelijk. De charismatische directeur had wel eens een boekje over rapid application development (RAD) gelezen en was er erg enthousiast over. Met name over het aspect ‘rapid’. Hij had boven het kopieerapparaat de uitgangspunten van RAD opgehangen en ging er vervolgens vanuit dat iedereen wel zou gaan werken volgens die uitgangspunten. Het was immers een prachtige methode.