Het “Agile” werken wint steeds meer aan populariteit. Toch zijn veel bedrijven hier nog niet klaar voor. En dan staat – in de IT wereld – ineens de volgende stap aan de deur te kloppen: DevOps. DevOps brengt de ontwikkel en beheer wereld bij elkaar: twee werelden die in de praktijk vaak ver uit elkaar liggen, ondanks dat ze zich allebei met IT bezighouden. DevOps teams zijn nóg beter in staat om zelfsturend te opereren. Maar als die teams zo zelfsturend gaan zijn, wat voor nut heeft de projectmanager dan nog? Maakt DevOps een eind aan de projectmanager?
Wat is DevOps ook alweer?
De gedachte achter Agile werken is dat er multidisciplinaire teams worden geformeerd. In de IT zijn dit vaak ontwikkelteams, die zeer snel – via korte sprints – werkende software kunnen opleveren en uitbreiden op basis van de wensen van de klant. De klant – vertegenwoordigd door de Product Owner – geeft zijn wensen aan en bepaalt de prioriteit van deze wensen. Per sprint wordt vervolgens bekeken wat kan worden gebouwd en wat niet.
Wat je in de praktijk ziet, is dat het Agile werken – met behulp van Scrum – beperkt blijft tot de systeemontwikkeling afdelingen. De IT afdelingen die zich bezighouden met het beheer van de IT infrastructuur werken echter vaak nog steeds met bijvoorbeeld ITIL processen, en als er projecten worden gedraaid, verlopen deze vaak op de waterval methode. DevOps tracht die afstand te overbruggen door de beheerders deel uit te laten maken van de teams, zodat software niet alleen kan worden ontwikkeld, maar ook direct op een goede manier in beheer kan worden genomen. Soms zijn bij de bouw van software wijzigingen nodig in de infrastructuur, en deze zaken kunnen direct binnen de DevOps teams worden opgepakt. Dit vergroot de flexibiliteit van de teams. Ontwikkelaars zullen hierbij soms meer beheertaken gaan uitvoeren, beheerders soms iets meer ontwikkel-achtige taken.
De rol van projectmanager verschuift
Doordat Agile/Scrum teams snel schakelen, multidisciplinair zijn ingestoken, de klant rechtstreeks bespreekt met de teams wat er moet worden gebouwd, en dit ook meteen in productie wordt opgeleverd, kun je je afvragen wat de rol van de projectmanager nog is in deze manier van werken. De Scrum Master kijkt immers of het team goed “werkt” en coördineert al een heleboel. Hoe lang het traject duurt, staat vast, en vaak ook al wat dit de klant gaat kosten. Wat blijft er dan nog over?
Wat je daarbij overigens ook merkt is dat het woord “project” bijna een besmeurd karakter heeft gekregen. Maar: het bouwen van software, op welke wijze dit dan ook gebeurt, is nog steeds een project. En er komt een keer een moment dat de software voor 80% klaar is, en dat de doorontwikkeling “stopt” (op minor aanpassingen na). Het pakket wordt in beheer genomen en er zal worden gewerkt aan iets nieuws.
De beginfase is cruciaal
De projectleider heeft ten eerste een grote rol aan het begin van het traject. Je kunt immers niet zomaar beginnen. Er zal tijd moeten worden besteed met klant om te vragen wat hij wil. En waarom. Als deze uitgangspunten zijn geformuleerd, zal er een korte haalbaarheidsstudie moeten worden uitgevoerd. Hetgeen wat gevraagd wordt, zal immers moeten aansluiten bij de bedrijfsprocessen – mogelijk ook van andere afdelingen die worden geraakt. Om nog maar over de technische haalbaarheid te zwijgen. Hoewel technisch “alles mogelijk is”, zijn er op voorhand zeker grofweg uitspraken te doen of de mogelijkheden daartoe ook daadwerkelijk realistisch zijn. De business case zal moeten worden opgesteld en heel misschien kan er al een prototype worden gebouwd. Het is daarnaast ook niet onverstandig om ook hier al een toetsing te doen van de succeskans van het project (bijvoorbeeld m.b.v. de Projects: Done™ methode).
Als er besloten wordt het project door te zetten, kunnen de requirements verder worden gespecificeerd en kan de klant de prioriteiten hiervan bepalen. Feitelijk is dit de vulling van de backlog voor de teams die aan het bouwen zullen slaan. Ook zal moeten worden beschreven wie het team gaat bemensen, welke rollen, verantwoordelijkheden, taken en bevoegdheden er van toepassing zijn en hoe het project zal worden bestuurd en gemonitord – los van wat er binnen het project allemaal via Scrum zal worden gerealiseerd.
De rol van de projectmanager is in deze fase niet te onderschatten. De activiteiten die moeten worden verricht, wijken niet bijster veel af van traditionele projecten. Dit is niet direct iets wat DevOps teams volledig zullen afvangen. Je zou kunnen zeggen dat dit het politieke en managerial deel is van het project wat vooral dient plaats te vinden voor er geld is/beschikbaar wordt gesteld om een groep mensen aan het werk te zetten.
Projectafsluiting
De bouw van het product is iets waar de projectmanager een minder actieve rol heeft dan in traditionele projecten. Er komt echter een moment dat het product zodanig “af” is, dat deze kan worden overgedragen naar de beheerafdeling. Het product kan niet eindeloos in ontwikkeling blijven: om “Lean” te blijven zul je niet moeten “overengineeren”. Als 80% van de gewenste functies klaar is, zullen de kosten voor de 20% die nog te gaan zijn namelijk relatief gezien toenemen, en onvoldoende extra klantwaarde leveren. Als het product in beheer genomen worden, kan het ontwikkelteam weer bezig met de volgende major release, of een compleet ander pakket uiteraard.
Maar dan? Het project zal uiteraard wel netjes moeten worden afgesloten. Er is geld uitgegeven, er is iets gebouwd, en er was een business case waarin de uitgaven die zijn gedaan iets zouden moeten opleveren. Dat moet wel getoetst worden. De benefits moeten worden gemeten, misschien is het team langer bezig geweest dan bedacht, zijn er meer sprints geweest, of is het team uitgebreid. De kosten zijn hierdoor toegenomen en je wilt natuurlijk wel weten hoe je project het heeft gedaan. De Product Owner zal in de DevOps teams wellicht wel functionaliteit vragen waarvan hij vindt dat het klantwaarde heeft, maar dit zal overall gezien – op programma / portfolio niveau – wel moeten worden geborgd.
Ook in deze eindfase is voor de projectmanager dus een grote rol weggelegd.
Conclusie
Hoewel op het eerste gezicht lijkt alsof de projectmanager geen rol meer heeft in een DevOps organisatie, lijkt het dus nog geen verloren zaak te zijn voor de projectmanager. De rol zal wel verschuiven – en het ‘gewicht’ van de rol schuift iets meer naar de voor- en achterzijde van het project. Gedurende het project zal de projectmanager vooral contact moeten hebben met de Scrum Master en de Product Owner om te kijken hoe de zaken verlopen. Maar mijn stelling is dus dat de projectmanager zeker niet direct zal verdwijnen uit het IT-organisatie landschap.
Eén reactie op “Maakt DevOps een eind aan de projectmanager?”