Bij deze succesvolle toepassing van de Agile Pm aanpak, lees je dat Scrum en de Agile PM aanpak goed naast elkaar kunnen werken. Juist de combinatie met enkele projectmanagement aspecten blijkt hier het verschil te maken. Namelijk, monitoring door een Projectboard, was hier helpend. Daarnaast heeft de MOSCOW prioriterings techniek hen het meest geholpen.
Dit sluit aan bij de ervaring van mijn collega Natasja Spaans, die in haar vorige blog, schreef over de toegevoegde waarde van een “scope governance board”. Daar blijkt ook behoefte te zijn aan een coördinerend orgaan dat afstemming organiseert rondom scope, prioritering en budget.
Smals is de gemeenschappelijke ICT-organisatie van de openbare instellingen van de sociale zekerheid in België. Zij realiseren innovatieve ICT-projecten en -diensten op het gebied van werk, gezin en gezondheid voor socialezekerheids- en zorginstellingen en biedt hen een brede waaier van ICT-diensten aan.
'ICT voor de samenleving' is niet alleen een slogan voor Smals; ze nemen deel aan baanbrekend werk in e-government en e-gezondheid in België en zijn een belangrijke speler in de digitale transformatie van de sociale zekerheid en de gezondheidszorg. Ze zijn ook actief in de ontwikkeling van de G-Cloud, de Belgische overheidscloud.
Karine Picart
Karine is Projectleider & Teamleider bij Smals. Zij is een specialist in collaborative tools en is verantwoordelijk voor het SharePoint competence center van Smals.
Wat is uw rol bij Smals?
Ik ben verantwoordelijk voor het SharePoint Competence Centre bij Smals, de gemeenschappelijke ICT-organisatie van de Belgische openbare instellingen van sociale zekerheid. Ik ben als project manager verantwoordelijk voor de SharePoint projecten die ons door onze leden worden toevertrouwd.
Hoe heeft u AgilePM leren kennen en wat was uw eerste behoefte?
De AgilePM-training maakt deel uit van onze trainingscatalogus. Ik was op zoek naar een agile methode en ik wist dat de Scrum-aanpak - die ook bij Smals wordt gebruikt - vooral bedoeld is voor softwareontwikkelteams. We hadden al eens geprobeerd om deze aanpak toe te passen op SharePoint-projecten, maar dat was niet overtuigend gebleken. Ik was op zoek naar een meer globale aanpak die ook projectmanagement integreert, waardoor we de vertegenwoordigers van de business beter zouden kunnen betrekken bij onze projecten om ervoor te zorgen dat we werken aan de dingen die ertoe doen.
Kort na de AgilePM training heeft u dit succesvol toegepast op belangrijke projecten. Kunt u de achtergrond van die projecten toelichten?
Het eerste project waarop we de AgilePM-aanpak hebben toegepast, betrof een Belgische socialezekerheidsinstelling die twee applicaties, die voorheen in Lotus Notes bestonden, wilde vernieuwen tot SharePoint-applicaties. Het ging om twee grote pilotprojecten (een toepassing voor het beheer van aanvragen en een portaal voor interne communicatie) die hen ook zouden toelaten hun vaardigheden op het vlak van SharePoint en projectbeheer verder te ontwikkelen. We implementeerden de AgilePM-aanpak en het ging heel goed; we waren om vele redenen zeer tevreden.
Na mijn training heb ik een van mijn collega's opgeleid om op te treden als architect/ontwikkelaar/technische coach voor de klant. Het doel was om ervoor te zorgen dat de aanpak van de projecten goed werd begrepen aan de kant van de klant en om maximale betrokkenheid te stimuleren.
We briefden onze business (business ambassadeur) en technische (ontwikkelaars) contacten op dezelfde kick-off voor beide projecten. Ik heb de methode uitgelegd, de rollen en verantwoordelijkheden van elk, en hoe het zou werken. Aan het einde van de kick-off gaven we het bedrijf de taak om een eerste versie van de backlog te maken door hun requirements te beschrijven en ze te prioriteren volgens de MoSCoW prioriteringstechniek (Must have, Should have, Could have, Won't have this time). De uitdaging was om 60% van de totale projectinspanning als must-haves aan te wijzen, wat moeilijk kan zijn (vaak krijgen we 70 of zelfs 80% van de vereisten als must-haves in de eerste ronde).
Wat waren uw beperkingen en uitdagingen?
De eerste uitdaging was die van het coachen, aangezien een deel van het team niet mijn gebruikelijke team was. De tweede uitdaging was ervoor te zorgen dat het hele projectteam de regels, de visie en de problemen volgde. Een van de ontwikkelaars die technisch zeer goed was, was bijvoorbeeld niet overtuigd van de AgilePM-aanpak; hij was in het begin een beetje sceptisch. Maar uiteindelijk speelde hij het spel mee en kon hij de logica van de aanpak inzien en verliep de relatie met het bedrijf heel goed. Ook de klanten apprecieerden de agile manier van werken dankzij AgilePM, waardoor het bedrijf veel meer betrokken is bij het project en bij de dagelijkse beslissingen. Het is niet ongebruikelijk dat het bedrijf denkt dat iets eenvoudig is. Maar door betrokken te zijn, begrijpen ze de taak en de bijbehorende uitdagingen beter. Omgekeerd hebben de ontwikkelaars een beter begrip van de onderliggende behoeften. De AgilePM-aanpak maakt het mogelijk om een transparante dialoog te voeren en de juiste keuzes te maken, zonder dat de ontwikkelteams blijven hangen in zaken die niet erg belangrijk zijn voor de klant/business.
De klanten verwachtten dat het project snel zou vorderen (en resultaten zou opleveren) zonder een deadline te stellen (wat een valkuil kan zijn omdat het veel langer kan duren dan nodig is). We slaagden er echter in snel te leveren en binnen drie maanden waren we klaar om live te gaan. Er waren wat problemen met de netwerkprestaties waardoor we niet volgens plan live konden gaan, maar we waren er klaar voor. We gaven er de voorkeur aan om te wachten en het netwerkprobleem op te lossen in plaats van een tool te leveren die als ondermaats zou zijn ervaren, ook al lag de oorzaak buiten de tool.
Hoe hebben jullie AgilePM geïmplementeerd?
Na de coaching en kick-off hebben we elke twee weken sprint review/sprint planning meetings opgezet voor elk van de projecten, wat betekende dat het ene project de ene week zou worden behandeld en het andere de volgende, enzovoort. Elk van de twee business ambassadeurs woonde de vergaderingen van de ander bij om consistentie in beslissingen te garanderen, aangezien we op hetzelfde technische platform werkten. Elke dag was er ook een stand-up meeting van 15 minuten met het projectteam (zakelijke en technische contacten).
We organiseerden maandelijks een project board van een uur en dat was voldoende om de voortgang van het project te volgen. Het is belangrijk om tijdens de project-raden niet te veel in te gaan op functionele of technische details, maar om gefocust te blijven op de projectopvolging. Toen deze monitoringstructuur er eenmaal was, liep het project bijna vanzelf!
Aan het einde van het project hebben we op afstand een lessons-learned exercitie uitgevoerd. De feedback van de klant was dat ze in het begin niet echt begrepen wat er tijdens de kick-off was uitgelegd, noch waarom we om bepaalde dingen vroegen. Naarmate de tijd verstreek werd alles echter duidelijker, begrepen ze waarom en waarom we zo intensief hebben gewerkt. Voor een toekomstig project zullen we meer aandacht besteden aan dit aspect.
De klant was zich in het begin van de inspanning ook niet bewust van wat het van hun kant zou vergen. Ambassadeur zijn van een bedrijf is bijna een fulltime baan en het is belangrijk dat zij de tijd krijgen om deze belangrijke rol uit te voeren. Er zijn verschillende vergaderingen bij te wonen en je moet ook klaar staan om dagelijks vragen en zorgen van het ontwikkelingsteam te beantwoorden, deel te nemen aan tests, enz.
Hoe heeft de AgilePM-aanpak u geholpen? Was er een bepaald element dat het meest nuttig voor u?
Het meest nuttig is naar mijn mening de MoSCoW prioriteringstechniek. Er is een groot verschil tussen het rangschikken van de requirements in een volgorde (1-2-3-4-5) en accepteren dat een requirement die je belangrijk vindt slechts een "should-have" is die misschien nooit zal worden geïmplementeerd, omdat andere requirements eerst komen. Continue prioritering is waarschijnlijk het meest nuttige aspect. Natuurlijk is dit niet het enige punt, het hele raamwerk is nuttig.
Heeft u advies voor collega project professionals in de sector?
Je moet je laten opleiden. Ik raad aan om een training te volgen bij een expert en het niet alleen te proberen, het boek te lezen en alleen die elementen er uit te pikken die je aanspreken. Ik heb een training gevolgd in een kleine groep en dat stelde me in staat om de methode goed te begrijpen, om sjablonen te maken en om mijn vragen te stellen. Persoonlijk zou ik zonder de training nooit het hele handboek hebben gelezen en zou ik belangrijke voordelen van de methode hebben gemist.
Een paar woorden tot besluit?
Onlangs heb ik ook een DevOps cursus gevolgd en ik kan zien dat de twee goed bij elkaar passen omdat de
filosofie en cultuur vergelijkbaar zijn.
Bron: APMG International, QRP Developing Professionals, APMG International AgilePM, Agile Business Consortium
Bij deze succesvolle toepassing van de Agile Pm aanpak, lees je dat Scrum en de Agile PM aanpak goed naast elkaar kunnen werken. Juist de combinatie met enkele projectmanagement aspecten blijkt hier het verschil te maken. Namelijk, monitoring door een Projectboard, was hier helpend. Daarnaast heeft de MOSCOW prioriterings techniek hen het meest geholpen.
Dit sluit aan bij de ervaring van mijn collega Natasja Spaans, die in haar vorige blog, schreef over de toegevoegde waarde van een “scope governance board”. Daar blijkt ook behoefte te zijn aan een coördinerend orgaan dat afstemming organiseert rondom scope, prioritering en budget.
Smals is de gemeenschappelijke ICT-organisatie van de openbare instellingen van de sociale zekerheid in België. Zij realiseren innovatieve ICT-projecten en -diensten op het gebied van werk, gezin en gezondheid voor socialezekerheids- en zorginstellingen en biedt hen een brede waaier van ICT-diensten aan.
'ICT voor de samenleving' is niet alleen een slogan voor Smals; ze nemen deel aan baanbrekend werk in e-government en e-gezondheid in België en zijn een belangrijke speler in de digitale transformatie van de sociale zekerheid en de gezondheidszorg. Ze zijn ook actief in de ontwikkeling van de G-Cloud, de Belgische overheidscloud.
Karine Picart
Karine is Projectleider & Teamleider bij Smals. Zij is een specialist in collaborative tools en is verantwoordelijk voor het SharePoint competence center van Smals.
Wat is uw rol bij Smals?
Ik ben verantwoordelijk voor het SharePoint Competence Centre bij Smals, de gemeenschappelijke ICT-organisatie van de Belgische openbare instellingen van sociale zekerheid. Ik ben als project manager verantwoordelijk voor de SharePoint projecten die ons door onze leden worden toevertrouwd.
Hoe heeft u AgilePM leren kennen en wat was uw eerste behoefte?
De AgilePM-training maakt deel uit van onze trainingscatalogus. Ik was op zoek naar een agile methode en ik wist dat de Scrum-aanpak - die ook bij Smals wordt gebruikt - vooral bedoeld is voor softwareontwikkelteams. We hadden al eens geprobeerd om deze aanpak toe te passen op SharePoint-projecten, maar dat was niet overtuigend gebleken. Ik was op zoek naar een meer globale aanpak die ook projectmanagement integreert, waardoor we de vertegenwoordigers van de business beter zouden kunnen betrekken bij onze projecten om ervoor te zorgen dat we werken aan de dingen die ertoe doen.
Kort na de AgilePM training heeft u dit succesvol toegepast op belangrijke projecten. Kunt u de achtergrond van die projecten toelichten?
Het eerste project waarop we de AgilePM-aanpak hebben toegepast, betrof een Belgische socialezekerheidsinstelling die twee applicaties, die voorheen in Lotus Notes bestonden, wilde vernieuwen tot SharePoint-applicaties. Het ging om twee grote pilotprojecten (een toepassing voor het beheer van aanvragen en een portaal voor interne communicatie) die hen ook zouden toelaten hun vaardigheden op het vlak van SharePoint en projectbeheer verder te ontwikkelen. We implementeerden de AgilePM-aanpak en het ging heel goed; we waren om vele redenen zeer tevreden.
Na mijn training heb ik een van mijn collega's opgeleid om op te treden als architect/ontwikkelaar/technische coach voor de klant. Het doel was om ervoor te zorgen dat de aanpak van de projecten goed werd begrepen aan de kant van de klant en om maximale betrokkenheid te stimuleren.
We briefden onze business (business ambassadeur) en technische (ontwikkelaars) contacten op dezelfde kick-off voor beide projecten. Ik heb de methode uitgelegd, de rollen en verantwoordelijkheden van elk, en hoe het zou werken. Aan het einde van de kick-off gaven we het bedrijf de taak om een eerste versie van de backlog te maken door hun requirements te beschrijven en ze te prioriteren volgens de MoSCoW prioriteringstechniek (Must have, Should have, Could have, Won't have this time). De uitdaging was om 60% van de totale projectinspanning als must-haves aan te wijzen, wat moeilijk kan zijn (vaak krijgen we 70 of zelfs 80% van de vereisten als must-haves in de eerste ronde).
Wat waren uw beperkingen en uitdagingen?
De eerste uitdaging was die van het coachen, aangezien een deel van het team niet mijn gebruikelijke team was. De tweede uitdaging was ervoor te zorgen dat het hele projectteam de regels, de visie en de problemen volgde. Een van de ontwikkelaars die technisch zeer goed was, was bijvoorbeeld niet overtuigd van de AgilePM-aanpak; hij was in het begin een beetje sceptisch. Maar uiteindelijk speelde hij het spel mee en kon hij de logica van de aanpak inzien en verliep de relatie met het bedrijf heel goed. Ook de klanten apprecieerden de agile manier van werken dankzij AgilePM, waardoor het bedrijf veel meer betrokken is bij het project en bij de dagelijkse beslissingen. Het is niet ongebruikelijk dat het bedrijf denkt dat iets eenvoudig is. Maar door betrokken te zijn, begrijpen ze de taak en de bijbehorende uitdagingen beter. Omgekeerd hebben de ontwikkelaars een beter begrip van de onderliggende behoeften. De AgilePM-aanpak maakt het mogelijk om een transparante dialoog te voeren en de juiste keuzes te maken, zonder dat de ontwikkelteams blijven hangen in zaken die niet erg belangrijk zijn voor de klant/business.
De klanten verwachtten dat het project snel zou vorderen (en resultaten zou opleveren) zonder een deadline te stellen (wat een valkuil kan zijn omdat het veel langer kan duren dan nodig is). We slaagden er echter in snel te leveren en binnen drie maanden waren we klaar om live te gaan. Er waren wat problemen met de netwerkprestaties waardoor we niet volgens plan live konden gaan, maar we waren er klaar voor. We gaven er de voorkeur aan om te wachten en het netwerkprobleem op te lossen in plaats van een tool te leveren die als ondermaats zou zijn ervaren, ook al lag de oorzaak buiten de tool.
Hoe hebben jullie AgilePM geïmplementeerd?
Na de coaching en kick-off hebben we elke twee weken sprint review/sprint planning meetings opgezet voor elk van de projecten, wat betekende dat het ene project de ene week zou worden behandeld en het andere de volgende, enzovoort. Elk van de twee business ambassadeurs woonde de vergaderingen van de ander bij om consistentie in beslissingen te garanderen, aangezien we op hetzelfde technische platform werkten. Elke dag was er ook een stand-up meeting van 15 minuten met het projectteam (zakelijke en technische contacten).
We organiseerden maandelijks een project board van een uur en dat was voldoende om de voortgang van het project te volgen. Het is belangrijk om tijdens de project-raden niet te veel in te gaan op functionele of technische details, maar om gefocust te blijven op de projectopvolging. Toen deze monitoringstructuur er eenmaal was, liep het project bijna vanzelf!
Aan het einde van het project hebben we op afstand een lessons-learned exercitie uitgevoerd. De feedback van de klant was dat ze in het begin niet echt begrepen wat er tijdens de kick-off was uitgelegd, noch waarom we om bepaalde dingen vroegen. Naarmate de tijd verstreek werd alles echter duidelijker, begrepen ze waarom en waarom we zo intensief hebben gewerkt. Voor een toekomstig project zullen we meer aandacht besteden aan dit aspect.
De klant was zich in het begin van de inspanning ook niet bewust van wat het van hun kant zou vergen. Ambassadeur zijn van een bedrijf is bijna een fulltime baan en het is belangrijk dat zij de tijd krijgen om deze belangrijke rol uit te voeren. Er zijn verschillende vergaderingen bij te wonen en je moet ook klaar staan om dagelijks vragen en zorgen van het ontwikkelingsteam te beantwoorden, deel te nemen aan tests, enz.
Hoe heeft de AgilePM-aanpak u geholpen? Was er een bepaald element dat het meest nuttig voor u?
Het meest nuttig is naar mijn mening de MoSCoW prioriteringstechniek. Er is een groot verschil tussen het rangschikken van de requirements in een volgorde (1-2-3-4-5) en accepteren dat een requirement die je belangrijk vindt slechts een "should-have" is die misschien nooit zal worden geïmplementeerd, omdat andere requirements eerst komen. Continue prioritering is waarschijnlijk het meest nuttige aspect. Natuurlijk is dit niet het enige punt, het hele raamwerk is nuttig.
Heeft u advies voor collega project professionals in de sector?
Je moet je laten opleiden. Ik raad aan om een training te volgen bij een expert en het niet alleen te proberen, het boek te lezen en alleen die elementen er uit te pikken die je aanspreken. Ik heb een training gevolgd in een kleine groep en dat stelde me in staat om de methode goed te begrijpen, om sjablonen te maken en om mijn vragen te stellen. Persoonlijk zou ik zonder de training nooit het hele handboek hebben gelezen en zou ik belangrijke voordelen van de methode hebben gemist.
Een paar woorden tot besluit?
Onlangs heb ik ook een DevOps cursus gevolgd en ik kan zien dat de twee goed bij elkaar passen omdat de
filosofie en cultuur vergelijkbaar zijn.
Bron: APMG International, QRP Developing Professionals, APMG International AgilePM, Agile Business Consortium
Het is onze missie om klanten te helpen hun veranderambities waar te maken.
Onze locatie in Amersfoort ligt pal tegenover de hoofdingang van het NS-station en is dus eenvoudig per openbaar vervoer bereikbaar.
Kom je met de auto, dan kun je het beste parkeren in de Q-Park P+R Barchman Wuytierslaan op circa 5 minuten loopafstand van ons kantoor.
