Traditioneel ingestelde organisaties volgen meestal de PRINCE2 projectmanagement methodiek om hun projecten beheersbaar uit te voeren. Het biedt ze een redelijk formeel kader met beheersmaatregelen voor managers.
Scrum geeft daarentegen focus aan productontwikkeling, samenwerking, kwaliteit en aan het continue maximaliseren van de toegevoegde waarde vanuit het projectteam (meestal een agile team genoemd). Scrum is een zeer transparante en resultaat gedreven aanpak.
In de praktijk zie ik dat beide methodieken heel goed zijn te combineren en elkaar kunnen versterken. Dit is goed nieuws voor organisaties die PRINCE2 hebben geïmplementeerd en die overwegen om Scrum te introduceren. In dit artikel leest u hoe beide methodieken concreet zijn te combineren. Enige voorkennis van de projectmanagement methodieken wordt hierbij verondersteld.
De Scrum aanpak ‘dwingt’ de projectteamleden om samen te werken én steeds beter te worden hetgeen de projectresultaten en arbeidsvreugde sterk beïnvloed in een positieve zin. Binnen het PRINCE2 proces “Managing Product Delivery” is het dan ook logisch om de Scrum aanpak toe te passen.
Aandachtspunten bij het toepassen van de gecombineerde aanpak
Draai de ijzeren driehoek 180 graden
In een traditionele aanpak wordt de project scope bijna altijd vastgezet. In de Agile aanpak juist niet. Je wilt immers flexibel kunnen inspringen op nieuwe inzichten om de meeste waarde toe te voegen tijdens iedere sprint. Nieuwe inzichten die zijn er in overvloed want ieder project is uniek (learn to learn).
Omdat er in korte iteraties (sprints) wordt gewerkt die ‘shipable products’ leveren kan de opdrachtgever ook veel sneller beschikken over de resultaten. De zogenoemde ‘Cost of Delay’ (CoD) wordt daardoor aanzienlijk lager wat weer bijdraagt aan een betere Return on Investment (ROI).
Voor de kwaliteit van het werk is het ook beter. In de traditionele aanpak (waterval gedreven) wordt er veelal te snel in detail gespecificeerd. Dus op momenten dat de organisatie en/of het project team nog geen goed beeld hebben. Aanpassingen op specificaties zijn in de regel erg lastig (en duur). Zie ook phases of disillusionment.
Product Breakdown Structure (PBS)
Houd de PBS op een relatief hoog niveau (op Epics of wel business requirement niveau). Het laagste niveau is maximaal een User Story (of wel een feature, functioneel requirement). Via een WerkPakket (WP) wordt de PBS of een onderdeel daaruit doorgezet naar de Product Backlog.
Stage (technische fase)
Om de Producten/Resultaten uit de Backlog te realiseren kunnen er meerdere Sprints nodig zijn binnen een Stage. Aan het einde van de Stage wordt de Projectstuurgroep gevraagd om een go/no-go beslissing te nemen voor de rest van het project. Uiteraard stimuleren we de leden van de Projectstuurgroep deel te nemen aan de Sprint Reviews. In de praktijk is dat helaas zeldzaam terwijl betrokkenheid en ondersteuning vanuit het senior management in de top 3 staat van de kritische succesfactoren vanuit menig onafhankelijk onderzoek.
Product Owner
Toleranties, met name op scope, zullen veelal veel ruimer moeten zijn dan gebruikelijk (ijzeren driehoek). Ook zal de Projectstuurgroep een Product Owner moeten aanstellen met voldoende bevoegdheden daarop. De Product Owner en het Projectteam hebben in Scrum namelijk veel vrijheden en verantwoordelijkheden. De Product Owner bepaalt bijvoorbeeld per Sprint hoe de toegevoegde waarde gemaximaliseerd kan worden door aan te geven welke User Stories (scope) gerealiseerd dienen te worden. Het Projectteam bepaalt hoe ze dat gaan realiseren. Wanneer toleranties te strak staan dan zullen er te vaak en onnodig projectissues en wijzigingsverzoeken worden gerapporteerd aan de Projectstuurgroep.
Tip: door een wijzigingsautoriteit in te stellen en/of de Product Owner aan te stellen met een eigen budget kunnen belangrijke aanpassingen die buiten de toleranties vallen ook effectief en efficiënt worden afgehandeld. De stuurgroep hoeft dan niet ingeschakeld te worden.
Scrum voor niet-software gerelateerde producten
Net zoals PRINCE2 ook buiten Telecom en overheid wordt gebruikt, wordt Scrum ook gebruikt voor niet-software gerelateerde projecten. Beide methodieken zijn m.i. product en branche onafhankelijk en gebaseerd op de ervaringen (best-practices) vanuit het verleden.
Project Manager
De Project Manager, zal net zoals de stuurgroep, een aantal verantwoordelijkheden en bevoegdheden moeten delegeren aan de Product Owner, het Projectteam en de Scrum Master. Een Scrum Projectteam is immers zelfsturend en vaart wel bij faciliterend leiderschap en dus minder vanuit te strake regie en controle.
