De ijzeren driehoek van planning

De ultieme evenwichtsoefening en hoe je het nirvana van agile projectmanagement bereikt

Tareq Aljaber By Tareq Aljaber
Onderwerpen zoeken

Alle agile softwareprojecten hebben doelen: wat het project moet opleveren, wanneer het moet worden geleverd en binnen welk budget. Het beheren van deze drie beperkingen kan echter een lastige uitdaging zijn. Neem een voorbeeld aan de decennia oude ijzeren driehoek van planning en ontdek hoe het balanceren van verschillende variabelen agile softwareteams kan helpen schalen.

De traditionele ijzeren driehoek

De ijzeren driehoek modelleert beperkingen van projectmanagement en deze beperkingen worden als 'ijzer' beschouwd omdat je de ene beperking niet kunt veranderen zonder de anderen te beïnvloeden. De originele ijzeren driehoek, voorgesteld door dr. Martin Barnes in 1969, volgt een watervalaanpak van productontwikkeling: scope staat vast en middelen en tijd zijn variabel. Voor een softwareteam zou dit betekenen dat teams een project starten door productvereisten te definiëren om de scope van een project te bepalen (een lijst met werkitems). De middelen en planning zijn variabel en worden geschat afhankelijk van de vaste scope.

Beperkingen van de ijzeren driehoek
  • Scope is het werk dat moet worden verricht, zoals functies en functionaliteiten, om een werkend product te leveren.
  • Middelen of resources verwijst naar budget en teamleden die werken aan levering en uitvoering.
  • Tijd verwijst naar momenten dat teams daadwerkelijk leveren, zoals via releases en mijlpalen.

Het doel van de ijzeren driehoek is om productteams de nodige informatie te geven om afwegingen te maken die het bedrijf zullen helpen. Als teams bijvoorbeeld worden geconfronteerd met een vaste scope, bestaat de kans dat ze halverwege een project tot de conclusie komen dat ze hun releasedatum niet gaan halen. De enige variabelen waarmee ze kunnen spelen zijn: 1) Tijd - ze kunnen een latere releasedatum accepteren of 2) Middelen - ze kunnen wat meer mensen aan het project toevoegen, wat de kosten verhoogt. Naarmate softwareontwikkeling in de 21e eeuw evolueerde, werd de behoefte aan betere samenwerking en het vermogen om snel te reageren op feedback van klanten cruciaal, en zo ontstond de agile methodologie.

IJzeren driehoek en watervalaanpak | Atlassian agile coach

De ijzeren driehoek transformeren naar agile

Als je een team bent dat watervalontwikkeling beoefent of nieuw is bij agile ontwikkeling, is het belangrijkste om te onthouden het verschil tussen wat vaststaat en wat wordt geschat. In tegenstelling tot watervalontwikkeling hebben agile projecten een vast schema en vaste middelen, terwijl de scope varieert. Hoewel de scope van een project kan veranderen in agile ontwikkeling, verplichten teams zich aan vaste iteraties van werk: sprints als je een scrumframework gebruikt, WIP-limieten als je een Kanban-framework gebruikt. Het is ook een best practice om teams tijdens het ontwikkelingsproces ongewijzigd te laten. Door teams consistent te houden op een product of project, worden ze efficiënter door ontwikkeld vertrouwen en continuïteit.

Waterval vs agile | Atlassian agile coach

Het idee van scope is hetzelfde in agile ontwikkeling: welke software moet worden gebouwd en geleverd. Agile richt zich echter op eisen op algemeen niveau in plaats van vooraf te komen met diepgaande en gedetailleerde vereisten. De scope van een project wordt regelmatig beheerd en opgeschoond (prioriteit gegeven) door de productmanager in een tool als Jira Software. De productmanager beslist welk werk in de volgende sprint moet worden uitgevoerd op basis van flexibele kwalitatieve en kwantitatieve feedback uit verschillende kanalen (marktomstandigheden, feedback van klanten, concurrenten, enz.). En omdat middelen en tijd vaststaan, is het voor ontwikkelingsteams gemakkelijker om te reageren op marktveranderingen en om sneller waarde te leveren aan klanten. Deze transparantie van beperkingen houdt teams eerlijk binnen een consistente en snelle releasecadans, wat een belangrijk kenmerk is van agile ontwikkeling. Door naar projecten te kijken door de lens van de ijzeren driehoek kunnen teams zich aanpassen zonder een plan op te geven.

Agile planning op lange termijn en de ijzeren driehoek

Naarmate projecten groter worden, zijn er meer teams nodig en wordt het tijdvak langer. Het idee om middelen en tijd vast te zetten en de scope te laten variëren is niet voor alle agile projecten een geschikte aanpak. Agile planning op de lange termijn vereist een meer flexibele ijzeren driehoek waarmee teams vooruit kunnen plannen en die ervoor zorgt dat ze aan de bedrijfsdoelstellingen voldoen. Denk bijvoorbeeld aan de lean start-upbeweging en het idee van een Minimum Viable Product (MVP) Een MVP bestaat per definitie uit een kleine set functies (scope) die klantwaarde biedt. Om tot een MVP te komen, moeten teams zich mogelijk houden aan een vaste scope (het aantal functies) en is tijd hun enige variabele (bijv. je kunt een product niet releasen zonder bepaalde functies, dus moet de releasedatum worden opgeschoven). Pas na het starten van de MVP schakelen teams over naar een variabele scope.

Ongeacht de verschillen tussen ontwikkeling op basis van de watervalaanpak en agile, is er bij gebruik van de ijzeren driehoek geen goede of verkeerde manier. De driehoek is er om je te helpen de beste beslissingen en afwegingen te nemen om de bedrijfsdoelen te halen. Een tool als Roadmaps visualiseert de bouwstenen van een plan (scope, mensen en tijd) om teams te helpen in realtime te plannen. Je kunt eenvoudig experimenteren met scope, teams en tijd om je volgende productrelease te plannen met behulp van de bestaande gegevens van het team in Jira Software.