Tag scrum

Gedachten naar aanleiding van een PI-planning

Ik had onlangs het geluk aanwezig te mogen zijn bij een Program Increment-planning - kortweg: PI-planning. Het was de tweede die mijn werkgever ooit organiseerde, en de eerste waar ontwikkelaars bij aanschoven. Het was een hele ervaring. En ik zal in wat volgt kort reflecteren op die ervaring.

De Grote Successenretro was een groot succes

Onze Scrummaster was er niet, en dus kwam het organiseren van de Sprint Retrospective op mijn bordje terecht. Omdat ik iets spannenders wilde organiseren dan een wat-ging-er-goed-en-wat-kon-er-beter-Retro (dat is de officiële term, toch?), nam ik een middag de tijd om verschillende vormen te bekijken. Voor de uiteindelijke opzet, putte ik inspiratie uit de cursus begeleidend coachen die ik de afgelopen maanden heb gevolgd. Eén van de belangrijkste lessen die ik heb getrokken uit die cursus, is de waarde van het focussen op successen. Wie oog heeft voor zijn eigen successen (of de successen van zijn/haar team), wie zijn eigen successen erkent en viert, opent de weg naar meer succes.

Het probleem met technische schuld op je backlog

Zo gaat mijn team om met het monitoren van technische schuld: we prikken elke Sprint een moment waarop we er met elkaar over praten, en als we het belangrijk genoeg vinden om er wat aan te doen, dan voeren we een Product Backlog Item op om die schuld weg te werken. Die aanpak werkt goed - goed genoeg, in elk geval. De technische schuld van onze huidige applicatie blijft grotendeels binnen de perken. En bovendien - dat is nog veel belangrijker - is iedereen in het team op de hoogte van het feit dat sommige plekken verbetering behoeven, en welke plekken dat zijn. Maar toch zit iets me niet helemaal lekker in die aanpak.

De Standup is geen statusmeeting

In The Art of Agile Development van James Shore kwam ik een zinsnede tegen die me deed opveren: de Daily Standup (ook wel Daily Scrum genoemd) is geen statusmeeting. - Laten we kijken wat dat betekent.

Tevreden ontwikkelaars én stakeholders dankzij speelruimte

Dit is denk ik voor veel teams een herkenbare situatie: de ene Sprint verbranden jullie achttien effort points, de volgende twintig, de keer daarop vijftien. Wat is dan de capaciteit van het team? Hoe kun je voorspellen wat jullie de volgende Sprint gaan opleveren, als de capaciteit fluctueert van keer tot keer? Het antwoord is: dat kun je niet. Maar in The Art of Agile Development van James Shore vond ik hier een oplossing voor.

Hoe lang hoort een Sprint Review te duren?

Soms sluit ik wel eens aan bij de Sprint Reviews van collega-teams. Wat me daarbij opvalt, is dat er een behoorlijke diversiteit in tijdsduur is tussen de Reviews van de verschillende teams. De onze zijn getimeboxt op een uur en ‘n kwartier, al duren ze in de praktijk meestal ongeveer een uur. Maar ik woon ook Reviews bij van een halfuurtje. Wat is er aan de hand?

Vijf nieuwe haiku's over software ontwikkelen

eerst verneuk je het, / daarna fix je de boel; dat / noemen we agile

U vraagt, wij draaien

Een stakeholder zei laatst iets tijdens een Sprint Review wat me tegen het zere been stootte. Ze was nog niet zo lang aangesloten bij de ontwikkeling van de applicatie en gebruikte deze zelf alleen nog als pilot. We spraken over aansluiten van een nieuwe gebruikersgroep op onze applicatie. De stakeholder gaf aan dat het op korte termijn - anderhalve sprint - moest gebeuren, en somde daarna een lijst features op die tegen die tijd af moesten zijn, “anders heeft het geen zin.” Harde woorden, en dat voor iemand die nog maar net komt kijken!

Agile zijn, niet Agile doen

Heeft Agile gefaald? Of heeft Agile nooit écht een voet aan de grond gekregen? In Clean Agile pleit Robert “Uncle Bob” Martin voor dat laatste. Het succes van Agile is zowel een vloek als een zegen geweest. Een zegen, omdat het het inefficiënte Waterval heeft verdreven, maar een vloek omdat de kerngedachte achter Agile zo vaak verkeerd begrepen is dat deze geheel verloren dreigt te gaan. Clean Agile is zijn poging de vele misverstanden recht te zetten.

Slecht nieuws en Sprint Reviews

Natuurlijk, het liefst toon je tijdens een Sprint Review de coole nieuwe features die jij en je team deze Sprint gebouwd hebben. Maar helaas, niet elke Sprint verloopt even soepel. Obstakels van buitenaf kunnen het ontwikkelwerk verstoord hebben, of een feature kan groter blijken dan op voorhand werd gedacht. Wat doe je wanneer je deze Sprint Review geen blijde boodschap hebt om te verkondigen?