Deadlines in een Agile ontwikkelomgeving: vloek of zegen?
Ik hoor het wel vaker: “Deadlines, met uitzondering van het sprint einde, horen niet in Agile omgeving”. Ondanks dat deze uitspraak veel voor komt, zie ik in praktijk dat, ook bij Agile (IT) ontwikkeling, deadlines gesteld worden. Vaak is het stellen van deadlines inherent aan de branche waarin gewerkt wordt en kun je ze niet altijd beïnvloeden. Hoe kun je met deadlines omgaan in een Agile ontwikkelomgeving?
Leestijd: 3 minuten – Auteur:
Thomas Franken
Data minded Business/Information analyst
Deadlines inherent aan het doen van (bepaalde) business
Deadlines vinden we in allerlei branches, ze geven duidelijkheid en richting aan een project of deliverable. Binnen de financiële wereld komen we deadlines vaak tegen, ook in Agile ontwikkelomgevingen. Veelal ontstaan deadlines door interne afhankelijkheden, budgetvaststelling of commitment naar externe afnemers/regulerende instanties. Zeker wanneer het gaat om regulerende partijen, ontkomt men vaak niet aan het stellen van deadlines.
Deadlines en Agile?
In het fundament is Agile niet bedacht om een kant en klaar product af te leveren op een bepaalde datum, het is eerder een proces waarin een organisatie iteratief (cyclisch) waarde levert en zodoende tot een eindproduct komt. Dat eindproduct wordt veelal omschreven als Minimal Viable Product (met minimale “levensvatbare” product). Vanuit de MVP-oplevering, wordt (ook weer in iteraties) incrementele waarde toegevoegd. Vanuit de exacte theorie zou men kunnen stellen dat een Agile proces “never ending” is en daarmee deadlines niet passen in de Agile context.
3 tips om deadlines en Agile toch te combineren
1. Zorg ervoor dat alle belangrijke features als eerst compleet zijn
Veelal is het zo dat stakeholders een werkend product willen wanneer de deadline is verstreken. Door eerst te werken aan het fundament (belangrijke features), zorgt het development team ervoor dat dit doel bereikt wordt. Belangrijk daarbij is dat de features die in productie staan, geen afhankelijkheden hebben met userstories die (nog) niet opgeleverd zijn. Na het opleveren van het product kan incrementeel waarde toegevoegd worden, maar is de business in ieder geval in staat om het product te gebruiken met de minimale vereisten.
2. Voer een open en eerlijke discussie met elkaar
Mijn ervaring is dat het belangrijk is om open te communiceren met management en stakeholders. Onderzoek wijst uit dat meer storypoints toewijzen dan dat er in de sprint passen, “technical debt” in de hand werkt. Technical debt motiveert developers (meestal) niet, maar maakt ook stakeholders niet enthousiast. Daarnaast is het evident dat het overbelasten van developers op lange termijn niet duurzaam is. Als een deadline staat en het minimaal vereiste niet geleverd kan worden, dan zullen resources uitgebreid moeten worden.
3. Beschrijf hoeveel van het werk gedaan is wanneer de deadline verstrijkt.
Het is belangrijk om te beschrijven welk werk er wel, en welk werk er niet gedaan is op het tijdstip dat de deadline gesteld is. Dit geeft een reële verwachting naar alle stakeholders, en biedt voedingsbodem voor een discussie over trade-offs/resources. Het is uitermate belangrijk dat de backlog inzichtelijk is voor de stakeholders. Dit betekent ook dat de userstories op zo’n manier beschreven zijn, dat het zowel voor Business partijen als IT te begrijpen is.
Hoe kan Magniv hierbij helpen?
De collega’s bij Magniv zijn gespecialiseerd in het stuk tussen IT en Business. Doordat wij “beide talen spreken”, kunnen wij helpen om de backlog zo op te stellen dat deze voor iedereen te begrijpen is. Daarnaast ondersteunen wij met ons analytisch denkvermogen het proces van prioritering. Meer weten over Agile en deadlines? Stuur mij een mailtje: t.franken@magniv.nl
Great change. Magniv careers.