Agile Projectmanagement Sprint

Sprints zijn een kenmerk van de meest populaire agile benaderingen voor projectmanagement en productoplevering. Ze worden voornamelijk gebruikt om grote stukken werk op te delen in kleinere, beter beheersbare delen die door agile teams kunnen worden opgeleverd.

Sprints werden voor het eerst beschreven als onderdeel van Scrum – een van de eerste en zeker de meest populaire agile benaderingen die vandaag de dag worden gebruikt. Ze worden ook gebruikt door Nexus en LeSS (benaderingen die worden gebruikt voor het opschalen van Scrum) en de nieuwste versie van AgilePM. Andere agile benaderingen zoals SAFe, DAD en XP gebruiken een bijna identiek concept maar hanteren de term Iteratie in plaats van Sprint.

In de volgende alinea's begin ik met het beschrijven van wat Sprints zijn en hoe ze zijn gestructureerd, voordat ik inga op praktisch advies en begeleiding om ervoor te zorgen dat ze leveren wat ze zouden moeten.

Een Sprint is een korte tijdsperiode met vaste lengte waarin een team werkt aan het voltooien van een set geprioriteerd werk. Sprints zijn bedoeld om leveringsteams in staat te stellen om op een voorspelbare, stapsgewijze manier betekenisvolle, incrementele voortgang te boeken richting langetermijndoelen.

Door Sprints te beperken tot een tijdsbestek van 2-4 weken, en ervoor te zorgen dat elke Sprint een duidelijk doel heeft, wordt frequente levering van waardevolle, strategisch afgestemde resultaten aangemoedigd.

Het ritme en de discipline van Sprints helpen teams momentum op te bouwen, complexiteit incrementeel te beheren, en zich snel aan te passen aan veranderingen. Belangrijk is dat het continue verbetering mogelijk maakt door frequente gelegenheid te bieden voor feedback, leren en aanpassing.

De Sprint, zoals gedefinieerd door Scrum, heeft een specifieke structuur. In deze vorm is het het meest geschikt voor gebruik in een niet-projectcontext, aangezien Scrum de rol van een Project Manager niet erkent. AgilePM stelt enkele praktische en pragmatische verbeteringen voor aan deze standaardstructuur die waarde bieden in de context van een project zonder de oorspronkelijke bedoeling van Scrum tegen te spreken of er afbreuk aan te doen.

Het onderstaande diagram toont de structuur van een Sprint zoals beschreven in de Scrum Guide 2020 – de definitieve gids voor Scrum geschreven door de medeoprichters van Scrum Jeff Sutherland en Ken Schwaber.

Het beschrijft vier belangrijke Events die de meeste mensen zouden herkennen als teamvergaderingen die plaatsvinden tijdens een Sprint. Het diagram toont een 2-weken sprint, maar voor Sprints met een andere duur zouden de meeste Events dienovereenkomstig geschaald moeten worden.

1. Elke Sprint begint met een Sprint Planning event waarbij:

• Een Sprint Goal wordt overeengekomen
  • Dit is een collaboratief proces waarbij de Product Owner en de Developers in het Scrum Team betrokken zijn.
  • De Product Owner is verantwoordelijk voor het waarborgen dat het geplande werk optimale waarde levert aan stakeholders.
  • Het Scrum Team moet een doel onderhandelen waaraan zij zich kunnen committeren.
• Wat er gedaan moet worden in de Sprint wordt onderhandeld
  • Dit is ook een collaboratief proces waarbij de Product Owner en de Developers betrokken zijn.
  • Items die nodig zijn om het Sprint Goal te behalen en een Product Goal te bereiken worden genomen uit de Product Backlog. Let op dat een Product Goal meerdere Sprints kan vergen om te bereiken.
  • Er kan een zekere mate van iteratie zijn tussen het overeenkomen van een precieze Sprint Goal en het werk dat nodig is om deze te bereiken.
• Hoe het overeengekomen werk gedaan zal worden
  • Dit is een collaboratief proces waarbij de Developers de geselecteerde Product Backlog items opsplitsen in uitvoerbare werk items en overeenkomen hoe deze geordend zullen worden in de Sprint Backlog.

De Sprint Backlog omvat alle drie bovenstaande elementen van het werk dat gedaan moet worden. Aan het eind van Sprint Planning is de Sprint Backlog, wat 'het plan' is voor de Sprint dat eigendom is van de Developers, overeengekomen.

2. De Daily Scrum

• Dit is een dagelijkse vergadering van 15 minuten (maximum) van de developers
  • Het wordt doorgaans op hetzelfde tijdstip elke werkdag gehouden.
  • Het schaalt niet in verhouding tot de lengte van de Sprint.
  • Het doel is om de developers in staat te stellen hun plannen aan te passen om de focus op en hun commitment aan het Sprint Goal te behouden.

Naarmate de Sprint vordert kunnen Product Increments geleverd worden, waarbij elke dergelijke Increment die welke eraan voorafgaan omvat. Levering van Product Increments is de maatstaf van de betekenisvolle incrementele vooruitgang die eerder genoemd werd.

3. Sprint Review

• Dit is het forum dat door het Scrum Team gebruikt wordt om aan stakeholders de waarde te demonstreren die het aan het eind van de Sprint heeft geleverd.
• Het uiteindelijke Product Increment wordt formeel beoordeeld in de context van zijn bijdrage aan het Product Goal en eventuele potentiële verbeteringen worden besproken
• Dergelijke verbeteringen worden toegevoegd aan de Product Backlog, ervan uitgaande dat ze nog niet genoteerd zijn.

4. Sprint Retrospective

• Het doel van dit event is voor het Scrum Team om te reflecteren op de effectiviteit van hun manier van werken
• Eventuele ideeën voor verbetering worden besproken en geprioriteerd. Een of twee van deze ideeën worden geadopteerd als experimenten voor de volgende Sprint waarbij de impact geëvalueerd wordt tijdens de daaropvolgende Retrospective

De volgende verbeteringen aan de Scrum Sprint worden voorgesteld door AgilePM waar ze waarde toevoegen in de context van projectmanagement. Ze zullen hoogstwaarschijnlijk waarde toevoegen in projecten met meerdere teams waar plannen tussen teams moeten synchroniseren tot een samenhangend overkoepelend projectplan.

5. De eerste van de verbeteringen is het vervangen van de Daily Scrum die 2 dagen voor het einde van de Sprint plaatsvindt door een speciale Consolidatie Scrum.

• Met een duur van 30 minuten is dit evenement iets langer dan de Daily Scrum.
• Naast het doel van het evenement dat het vervangt, wordt het Scrum Team gevraagd te voorspellen welk deel van het uitstaande werk van de Sprint zal worden voltooid en wat hoogstwaarschijnlijk onvoltooid zal blijven.

6. De tweede verbetering is de introductie van het Project Planning Evenement.

• Dit evenement wordt bijgewoond door de projectleiderschapsrollen van Business Visionary, Solution Architect en Project Manager, elk met specifieke verantwoordelijkheden in de leiding van het project in AgilePM.

Opmerking: Vanuit een algemeen projectmanagementperspectief zijn de rollabels onbelangrijk. Het evenement moet worden bijgewoond door de projectmanager en anderen die verantwoordelijk zijn voor het vormgeven van de koers van het project Sprint-voor-Sprint.

• De zeer korte-termijn voorspellingen van de Consolidatie Scrum dienen als input voor het evenement en maken zinnige planningsinput mogelijk voor alle teams voor de volgende Sprint
• Het evenement biedt ook de mogelijkheid voor planning richting een horizon voorbij de aanstaande Sprint en voor projectactiviteiten die uitgevoerd moeten worden door projectteamleden die mogelijk geen leden zijn van een Scrum Team.

Ik werk sinds 1997 met agile benaderingen voor projectmanagement en oplevering. Ik weet hoe goed ze kunnen werken en, evenzo, hoe slecht de prestaties kunnen zijn als dingen niet werken zoals ze zouden moeten.

Als je wenst om wendbaarheid in projectmanagement te omarmen, is het beste advies dat ik kan geven om je Sprints uit te voeren in overeenstemming met Scrum-richtlijnen. Dit betekent dat je als projectmanager wat afstand moet houden van de planning en uitvoering van Sprints. Je moet dichtbij genoeg zijn om ervoor te zorgen dat ze werken zoals ze zouden moeten, terwijl je de krachtigste aspecten van wendbaarheid toestaat om hun oplevering te versnellen.

Hier zijn 6 'toptips' voor het succesvol gebruik van Sprints

1. Probeer Scrum met rust te laten.

• Het is beproefd, getest en effectief als het juist wordt toegepast in lijn met Scrum Guide-richtlijnen. Dat gezegd hebbende, het begrijpen van wat het doet werken, in plaats van het alleen maar op een procedurele manier volgen, is essentieel om er het meeste uit te halen.

2. Gebruik Sprints van vaste lengte in een regelmatig ritme

• In theorie kun je de lengte van elke Sprint in een reeks variëren en af en toe is het logisch om nu en dan een Sprint van onregelmatige lengte te hebben. Bijvoorbeeld, een incidentele Sprint kan langer of korter zijn dan gewoonlijk om te passen rond seizoensgebonden vakanties of om een opleverdatum te halen die anders midden in een Sprint zou vallen.
• Standaard uitlopen op een Sprint van vaste lengte maakt echter het plannen van stakeholder-betrokkenheid en het volgen van voortgang gemakkelijker.

3. Verschuif NOOIT een Sprint-einddatum

• Een van de belangrijkste voordelen van het gebruik van Sprints is de voorspelbaarheid van oplevering die het biedt. Tijdige oplevering van een waardevol product kan vrijwel worden gegarandeerd door:
  • De einddatum van de Sprint te respecteren, en
  • Het werk te prioriteren om de hoogste waarde en/of meest risicovolle aspecten aan te pakken vóór lagere waarde en/of meer eenvoudige aspecten.

4. Sla geen evenementen over.

• Elk evenement in een Sprint heeft een doel dat gekoppeld is aan de empirische fundamenten van wendbaarheid. Specifiek:
  • Transparantie van wat er wordt gedaan en hoe
  • Inspectie van het evoluerende product en werkwijzen
  • Aanpassing van deze om het product steeds waardevoller te maken en om de efficiëntie en effectiviteit van werkpraktijken te verbeteren

5. Probeer het concept van team-empowerment te 'leven'.

• Begrijp en omarm de waarden die de agile werkwijze ondersteunen en moedig iedereen die geassocieerd is met het project aan om dit te doen. Scrum definieert deze waarden als Toewijding, Focus, Openheid, Respect en Moed. Citerend uit de 2020 Scrum Guide:

"Wanneer deze waarden belichaamd worden door het Scrum Team en de mensen met wie ze werken, komen de empirische Scrum-pijlers van transparantie, inspectie en aanpassing tot leven en bouwen ze vertrouwen op."

Houd in gedachten dat je geen Scrum-benadering hoeft te volgen om de waarden ervan over te nemen. Het omarmen ervan zal waarde toevoegen aan elke teamgebaseerde onderneming.

• Dicteer niet, leid collaboratief.
  • Team-eigenaarschap en toewijding worden aanzienlijk verminderd in een omgeving waar een enkel individu, zoals een projectmanager, dicteert wat er gedaan moet worden en wanneer
  • Een collaboratieve benadering van leiderschap die de hierboven beschreven Scrum-waarden omarmt, zal leiden tot verbeterde kwaliteit en productiviteit.
• Beïnvloed plannen (voor zowel de oplossing als het opleveringsschema) via de Product Owners. Dit vereist erkenning door de Product Owner dat projectleiderschapsrollen belangrijke stakeholders zijn.

En als je teams niet het best geplaatst zijn om op een agile manier te presteren...

6. Coach ze ernaar toe

• De agile werkwijze leunt zwaar op het idee dat de mensen die het werk doen het best in staat zijn om gedetailleerde beslissingen te nemen over wat er gedaan moet worden en hoe. Gecombineerd met een duidelijke gedetailleerde definitie van wat er nodig is en waarom van een Product Owner die collaboratief werkt als onderdeel van het team, werkt dit erg goed. Ik heb persoonlijk aanzienlijke productiviteitsstijgingen meegemaakt die alleen kunnen worden toegeschreven aan een verschuiving naar empowered teams vanuit een gecentraliseerde 'command and control'-benadering.
• Empowerment moet echter erkend worden als een tweerichtingsstraat, waarbij leiders bereid zijn om hun teams te empoweren en teams in staat zijn om die empowerment te omarmen. In situaties zonder competentie en toewijding van teamleden heb ik de productiviteit zien kelderen.
• De theorie van situationeel leiderschap ontwikkeld door Paul Hersey en Ken Blanchard in de jaren 1970 beschrijft hoe een leider, misschien in onze context een projectmanager, kan overgaan naar een optimale leider/team-dynamiek voor wendbaarheid.

Sprints zijn een hoeksteen van veel agile benaderingen en bieden structuur, focus en ritme aan de levering van waarde. Hoewel hun oorsprong ligt in Scrum, is het concept succesvol aangepast door een reeks frameworks en geschaalde modellen, vaak onder de bredere term "iteratie." Ongeacht de terminologie blijven de principes consistent: werk timeboxen, frequente inspectie en aanpassing mogelijk maken, en teams in staat stellen zichzelf te organiseren rondom duidelijke doelen.

Wanneer doordacht gebruikt, kunnen Sprints de projectoplevering drastisch verbeteren — maar alleen als ze gerespecteerd worden. Sprints behandelen als meer dan alleen een schema, en de discipline, waarden en samenwerkingsgeest omarmen die eraan ten grondslag liggen, is wat hun potentieel ontsluit.

Voor projectmanagers die in agile omgevingen werken, is de uitdaging om te ondersteunen zonder te controleren — ruimte te creëren voor gemachtigde teams terwijl afstemming en focus gewaarborgd blijven. Goed gedaan leidt deze balans niet alleen tot succesvolle Sprints, maar tot consistent goed presterende teams en duurzaam projectsucces.