Tag scrum
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?
Horizontale of verticale PBI's?
Een risico van horizontaal ontwikkelen is dat je veel tijd besteedt aan de back-end, om er vervolgens bij de implementatie van de front-end achter te komen dat je iets over het hoofd hebt gezien. Met als gevolg dat je alsnog verticaal aan het ontwikkelen slaat. Dat is niet alleen irritant, het is ook ontzettend inefficiënt!
Iteratieve verfijning
Dat software ontwikkelen - vandaag de dag in elk geval - een iteratief proces is, is een plattitude. Dat ook de voorbereidingswerkzaamheden van programmeren iteratief kunnen (of moeten?) worden vormgegeven, is iets wat ik misschien wel wist, maar me nooit helemaal beseft heb. Het interessante van Scrum (en van softwareontwikkeling in het algemeen) is dat je het jarenlang kunt doen, en toch steeds opnieuw best en better practices kunt ontdekken - of herontdekken.
Hoe technische schuld te monitoren én prioriteren
Software ontwikkelen is mensenwerk. Hoe goed de tooling tegenwoordig ook is, ze is niet meer dan een hulpmiddel voor ontwikkelaars om grip te krijgen op een codebase. De beste manier om technische schuld in beeld te krijgen, is dan ook niet door allerhande tools op je code los te laten, maar door erover te praten met je collega’s.
Hoe ik mijn PBI's opzet
Immitatie is de hoogste vorm van vlijerij, zegt men wel. En inderdaad, toen ik laatst zag dat onze stagiaire de structuur van mijn PBI’s had overgenomen, kon ik mezelf een gevoel van trots niet ontzeggen. Misschien is het een goed idee om uiteen te zetten hoe ik mijn PBI’s opzet en waarom.
Schrijf PBI's - en doe het goed
Het is niemands favoriete klus: Product Backlog Items (PBI’s) aanmaken om de komende Sprints op te kunnen pakken. En toch, het is een onderdeel van je werk als ontwikkelaar. En een belangrijk onderdeel ook, want zonder goed opgezette PBI’s kan een team helemaal niets.
"Niet zo bijzonder"
Onze stagiaire heeft onlangs een volledige Sprint besteed aan het op orde krijgen van haar documentatie. Tijdens de Sprint Review karakteriseerde ze die twee weken werk als “niet zo bijzonder”. Ik kwam tegen die woorden in het verweer.
Het doel van deze Sprint is niet om code te schrijven
Mijn team worstelt al een tijd met het voldoende gevuld krijgen van de Product Backlog. Dat heeft impact op onze Planning-sessies. Deze zijn lang en moeizaam, omdat we last minute PBI’s inschatten om de komende Sprint maar gevuld te krijgen. We zijn het er al langere tijd over eens dat dit een onwenselijke situatie is. Toch krijgt het team maar niet voor elkaar dit aan te pakken. Maar misschien heb ik een manier gevonden.