Agile Software Development en de veranderende rol van de projectmanager

Agile Software Development en de veranderende rol van de projectmanager Auteur: Arjan Vis, [email protected] Supervisor: Prof. Dr. A. Eliens Faculteit der Exacte Wetenschappen, Vrije Universiteit Amsterdam

Abstract: Context: Traditional Software Development wordt steeds meer vervangen door Agile Software Development en wat heeft dit voor gevolgen voor een projectmanager. Doel: Het onderzoeken hoe een projectmanager zich dient te gedragen in een Agile Software Development project. Methode: Een drietal papers gelezen om te verschillen en overeenkomsten te kunnen vinden tussen Agile Software Development en Traditional Software Development, zowel globaal als lokaal. Hierbij gefocust op de rol van de projectmanager. Resultaten: Het beschrijven van een aantal leidraden voor een projectmanager. Conclusie: De rol van een projectmanager bij een Agile Software Development project is anders in vergelijking met de rol van een projectmanager bij een Traditional Software Development project. Deze veranderingen gelden zowel bij lokale als globale projecten, waarbij globale projecten nog iets meer taken geven aan een projectmanager.

1. Introductie Software Development en probleemstelling Agile Software Development (ASD) verschilt op een aantal vlakken van Traditional Software Development (TSD). Zo zijn ASD projecten (ASDp) flexibeler ten opzichte van TSD projecten (TSDp). Bij TSDp wordt vooraf een plan opgesteld en aan dat plan dient men zich te houden, in tegenstelling tot ASDp, waar er rekening wordt gehouden met veranderende omstandigheden, zodat daar direct op ingespeeld kan worden. Doordat ASD zo verschilt van TSD, is de rol van de projectleden ook anders en zij zullen zich moeten aanpassen aan de nieuwe situatie. Dit paper zal dieper ingaan op de veranderende rol van de projectmanager. De rol van de projectmanager is ervoor te zorgen dat het project op tijd af komt, maar als de projectmanager zich niet goed aanpast aan de nieuwe situatie, leidt dat tot vertraging, of in het uiterste geval afblazen, van het project. In deze paper zullen een aantal manieren beschreven worden hoe een projectmanager zich kan gedragen om tot een succesvol project te komen en daaruit volgt de onderzoeksvraag:

Hoe dient een projectmanager zich te gedragen in een Agile Software Development project, zodat het project succesvol zal verlopen?

1 Arjan Vis – 1981145 – IMM – Vrije Universiteit Amsterdam

Deze probleemstelling is vrij breed opgetrokken en in sectie 3 zal uitgelicht worden waarom dat zo is. De rest van de paper zal er als volgt uitzien: Sectie 2 zal de achtergrond van ASD en TSD weergeven, sectie 3 zal de verschillende kanten van de probleemstelling belichten en methoden van onderzoek, sectie 4 bevat een discussie over de bevindingen en uiteindelijk in sectie 5 een conclusie en aanbevelingen voor toekomstig werk.

2. Achtergrond: Agile Software Development vs. Traditional Software Development In deze sectie zal dieper worden ingegaan op de verschillen tussen Agile Software Development (ASD) en Traditional Software Development (TSD). Zoals al eerder vermeld zijn ASD projecten (ASDp) flexibeler dan TSD projecten (TSDp), maar er zijn nog meer verschillen. Zo beslissen de teamleden binnen ASDp hoe ze de dag gaan invullen. Dit in tegenstelling tot TSDp, waar de projectmanager beslist wie welke taak gaat uitvoeren. Hier schuilt een groot gevaar voor ASDp: de teamleden werken intensief samen en als een team een succesvol project heeft gehad, kan er bij een volgend project het zogeheten Groupthink/Abilene Paradox-effect optreden. Het gevolg van dit effect is dat teamleden automatisch accepteren wat een ander teamlid zegt, omdat ze denken aan het vorige, succesvol verlopen project.[1] Het verschil tussen Groupthink en Abilene Paradox is dat bij de Abilene Paradox iemand iets aangeeft om te gaan doen, bijvoorbeeld het afmaken van een bepaald deelproject, maar dat niemand, ook de persoon die het aangeeft, het eigenlijk ermee eens is, waarbij Groupthink de persoon die het aangeeft nog denkt dat dat het beste is om te doen. Dit hoeft geen nadelige effecten te hebben voor het verloop van het project, maar het kan wel tot problemen leiden. Er wordt uitgegaan van het beste van elk teamlid, dat iedereen uiteindelijk het beste voor heeft met het project, maar er zijn verschillende ethische vraagstukken te bedenken. Wat als een teamlid een aanbieding heeft ontvangen van een concurrerend bedrijf om het project te laten mislukken? Op de lange termijn zal dat zichzelf wel oplossen, het teamlid verdwijnt uit de projectgroep of de projectgroep wordt in zijn geheel anders ingedeeld, maar op de korte termijn zal dat destructief werken op een project. De projecten verlopen zelf ook anders: in ASDp wordt er getest zodra er een iteratie af is, een (meestal) relatief klein gedeelte van een project. Bij TSDp wordt er pas getest zodra er een complete fase afgerond is. De complete software wordt dus eerst ontwikkeld en daarna wordt gekeken of alles wel werkt. De negatieve kant bij TSDp is dat als er iets niet goed werkt, er de mogelijkheid is dat alles opnieuw moet worden geprogrammeerd. Hier hangen gigantische kostenplaatjes aan vast, onder andere vanwege de vertraging van het project. Dit houdt echter niet in dat de manier zoals ASDp dat oplost zaligmakend is. Zo kunnen relatief kleine, onbelangrijke dingen een heel project op zichzelf

2 Arjan Vis – 1981145 – IMM – Vrije Universiteit Amsterdam

worden omdat het niet goed werkt. Het is dus zaak dat er goed geprioriteerd wordt wat echt goed moet werken en wat later aangepakt kan worden. Verder is het klantcontact anders. Waar er in TSDp vooral vooraf veel contact is geweest met een klant en een compleet project is opgesteld met wat er moet gebeuren, neemt de klant in ASDp vaak zitting in de projectgroep. De klant heeft dus direct invloed op wat er gaat gebeuren en kan gemakkelijk nieuwe ideeën aanbrengen. Dit kan eveneens zowel positief als negatief uitwerken bij ASDp: een klant kan altijd het nieuwste wat het nieuwste willen, ook al is dat wellicht helemaal niet van toepassing op de klant en levert het alleen maar extra werk op. Het positieve is dat de klant ziet hoe het eindproduct ontstaat en kan kleine, nuttige aanpassingen aangeven.

3. Probleemstelling en methoden van onderzoek De probleemstelling is vrij breed opgetrokken. Agile Software Development is niet één methode, er zijn meerdere methodes die onder ASD vallen en voor elk van die methodes moet een projectmanager zich iets anders gedragen. Voorbeelden van een ASD-methode zijn Scrum, Extreme Programming en Agile Unified Process en zo zijn er nog velen meer. Ze hebben gemeen dat de leden van de projectteams de verantwoordelijkheid dragen voor wat ze doen en hoe ze het doen, maar bij de methoden onderling zijn er wel verschillen. De keuze om het zo breed te houden is welbewust gekozen, aangezien er waarschijnlijk voor de projectmanager een aantal vaste randvoorwaarden zijn, welke leiden tot een succesvol project. Naast de brede optrek van de probleemstelling, zijn er ook inhoudelijk punten aan te merken. Zo zijn er lokale ASDp, maar ook globale ASDp. Het onderzoek zal bij dit vlak vooral richten of er overeenkomsten en verschillen zijn bij het managen van die projecten, ofwel in hoeverre dient een projectmanager zich aan te passen aan het lokale of globale karakter van een project. Voor het onderzoek zullen drie papers [1][2][3] gebruikt worden. Het eerste paper geeft een algemeen beeld hoe de projectmanager zich gedragen zou moeten bij ASDp, waar het tweede paper wat dieper ingaat op Scrum. Dit zijn beide papers waar case studies gedaan zijn bij lokale projecten. Daarom ook de keus voor het derde paper, waar globale ASDp centraal staan. In het derde paper maken de onderzochte bedrijven gebruikt van de agile methoden Scrum en een mix van Scrum met Extreme Programming.

4. Discussie over resultaatbevindingen Voor lokale ASDp blijkt uit de onderzochte papers dat er voor een projectmanager een aantal overeenkomsten zijn in vergelijking met lokale TSDp. Zo blijft de projectmanager verantwoordelijk voor de eindresultaten van het project. Ook al kan hij zelf niet bepalen wat elk teamlid doet, hij moet wel in de gaten houden dat de deadline van het project gehaald wordt. Alhoewel de 3 Arjan Vis – 1981145 – IMM – Vrije Universiteit Amsterdam

verantwoordelijkheid van de projectmanager dus gelijk is gebleven op dat vlak, zal zijn rol nu meer een coachende rol zijn dan een leidende rol. Wat eveneens gelijk is gebleven is dat de projectmanager verantwoordelijk is voor de communicatie in de groep. Teamleden hebben onderling veel overleg, elke dag één keer in de zogeheten meetings, en de projectmanager moet aanvoelen of er problemen zijn in de groep. Deze problemen zullen niet altijd even expliciet duidelijk zijn en het is zaak dat een projectmanager impliciete kenmerken van slechte communicatie herkent en er tegen op kan treden. Al genoemd is de veranderende rol van de projectmanager en dat die nu meer als coach moet optreden dan als leider. Daarbij hoort ook een faciliterende rol: de projectmanager moet ervoor zorgen dat de teamleden hun beslissingen maken op de best beschikbare informatie. Hierbij valt te denken aan nieuwe methoden en/of veranderende omstandigheden. Wat eveneens verandert is, is het gevaar van het al eerder genoemde Groupthink/Abilene Paradox-effect. Een projectmanager moet kunnen optreden als advocaat van de duivel om er voor te zorgen dat de projectleden nadenken over de beslissingen die zij nemen en die ook kunnen beargumenteren. De projectmanager dient een balans te vinden tussen Groupthink/Abilene Paradox-effect en het geen initiatief meer durven te tonen. Het is de rol van de projectmanager om de teamleden bewust te maken van de beslissingen die zijn maken, zonder daarin door te slaan. Ook tussen globale ASDp en TSDp zijn een aantal overeenkomsten. Zo dient er vooraf veel contact te zijn tussen de projectteams om culturele en linguïstische problemen te voorkomen. Bij TSDp is het nodig een duidelijk projectplan op te stellen waarin elk team begrijpt wat er moet gebeuren. De projectteams zullen daarna alleen contact hebben als een fase is afgerond. ASDp gaat echter een stap verder: zij hebben elke dag een meeting, net als bij lokale ASDp, maar die meeting moet vooraf voorbereid worden, door het sturen van mails naar de andere teams. Zo kunnen de meetings zelf kort gehouden worden, wat nodig is vanwege de mogelijk grote tijdverschillen onderling. Bij globale ASDp moeten de project managers van elke locatie ook elke week een meeting hebben, welke ook nauwkeurig voorbereid dient te worden. De voorbereiding moet bevatten hoe een team er voor staat, waar er eventuele problemen zijn en hoe die opgelost gaan worden. Een voordeel van globalisering is het omlaag brengen van de kosten: werk kan verplaatst worden naar lagelonenlanden en er kan 24/7 aan een project gewerkt worden. De ethische vraagstukken die hierbij gesteld kunnen worden zijn: Is het geen uitbuiting van de lokale bevolking, en kan je het maken tegenover mensen die al jaren bij een bedrijf werken om die te ontslaan vanwege het kostenplaatje? Op deze vragen zijn twee antwoorden mogelijk: Ja, het is uitbuiting en je moet het niet willen. Daar kan echter ook een maar achter geplaatst worden, aangezien er wel gezorgd wordt voor werk en dat helpt de lokale bevolking wel. Ook de tweede vraag kan met ja

4 Arjan Vis – 1981145 – IMM – Vrije Universiteit Amsterdam

beantwoorden worden. Ja, dat kan je maken tegenover mensen, aangezien je een bedrijf leidt en geen liefdadigheidsinstelling. Ethisch gezien wellicht onverantwoord, bedrijfstechnisch gezien niet. Een kanttekening bij de resultaten is dat als een projectmanager aan bovenstaande punten voldoet, dit niet automatisch leidt tot een succesvol project. Een projectmanager is een onderdeel van het project en hij heeft veel verantwoordelijk, maar alles beïnvloeden lukt niet. Er zijn genoeg externe factoren die een project kunnen doen mislukken. Een faillissement van het bedrijf, een ongeluk waardoor er veel teamleden wegvallen en technische storingen zijn maar een aantal voorbeelden waardoor veel projecten kunnen mislukken. Daarnaast zijn er nog de interne factoren: teamleden die niet genoeg capaciteiten hebben om te doen wat er van ze verwacht wordt, een CEO die beloftes maakt aan de klant die onmogelijk waargemaakt kunnen worden. Het is dus geen blauwdruk voor succes en het is ook zo dat als een projectmanager één van bovenstaande eigenschappen ontbeert, het project sowieso mislukt. Het zijn eigenschappen die de kans vergroten op een succesvol project, die de projectmanager zullen helpen in zijn dagelijkse bezigheden.

5. Conclusie en toekomstig werk Er zijn een aantal verschillen en overeenkomsten tussen Traditional Software Development projecten en Agile Software Development projecten en ook in hoe de projectmanager zich dient te gedragen. De onderzoeksvraag luidde:

Hoe dient een projectmanager zich te gedragen in een Agile Software Development omgeving, zodat het project succesvol zal verlopen?

en die vraag kan niet eenduidig beantwoord worden, omdat er teveel factoren rond de projectmanager zijn die invloed hebben op het project. Het helpt echter wel als de projectmanager communicatief vaardig is, problemen kan aanvoelen en weet hoe ze op te lossen en het team in de best mogelijke omstandigheden kan laten werken. Dit geldt voor zowel lokaal als globaal, waarbij globaal nog bovenop komt dat de communicatie met de externe projectgroepen vooraf dient te worden voorbereid, zodat de communicatie duidelijk kan verlopen. Toekomstig werk kan zich richten op de projectmanager in de specifieke methoden van Agile Software Development. Dit onderzoek richtte zich vooral op de algemene leidraden waaraan een projectmanager dient te voldoen voor het succesvol verlopen van een project, maar de methoden onderling verschillen ook. Het kan interessant zijn om te onderzoeken of de randvoorwaarden voor een projectmanager verschillen bij die verschillende methoden.

Referenties 5 Arjan Vis – 1981145 – IMM – Vrije Universiteit Amsterdam

[1] J. McAvoy & T. Butler. The role of project management in ineffective decision making within Agile software development projects, European Journal of Information Systems (2009) 18, p. 372–383 [2] N.B. Moe, T. Dingsøyr & T. Dybå. A teamwork model for understanding an agile team: A case study of a Scrum project in Information and Software Technology 52 (2010), p. 480-491. [3] J. Sutherland, A. Viktorov, J. Blount & N. Puntikov. Distributed Scrum: Agile Project Management with Outsourced Development Teams in Proceedings of the 40th Hawaii International Conference on System Sciences – 2007.

6 Arjan Vis – 1981145 – IMM – Vrije Universiteit Amsterdam