Tag verantwoordelijkheid
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.
Wat je aanpakt weegt licht
De vloek van een goed functionerend team is dat de organisatie daarvan vindt: die kunnen dit en dat best erbij hebben. De zegening van een goed team is dat de organisatie daarin meestal wel een punt heeft. Dat gezegd hebbende, mijn team was niet blij toen we de opdracht in onze mik geschoven kregen om een bedrijfskritische legacy applicatie door te lichten. We hebben ons werk voor die applicatie lange tijd zo ver mogelijk naar achteren geschoven. Maar enkele Sprints terug was het dan toch zo ver. En eerlijk gezegd: het viel alleszins mee.
Twee sonnetten over software ontwikkelen
Stakeholder, u stijgt pas echt in achting / Als u - prijs de Heer voor dit geluk! - / Inziet wanneer niet de code de bug / Herbergt, maar uw eigen verwachting.
Blijven we dit ondersteunen?
Onze legacy-applicatie focust zich op de constructie van toetsen, niet op de afname. Om de afnameomgeving te kunnen bekijken, heeft de applicatie een integratiepunt met een externe tool. Maar de laatste tijd levert die functionaliteit vooral veel frustratie op. Problemen met de externe tool worden op onze applicatie geschoven, en het gedrag met de geïntegreerde versie is bij een grote load inconsistent met die van de externe tool. De klachten over de integratie vreten tijd van het ontwikkelteam, en zorgen bovendien voor frustraties over en weer naar de stakeholders.
Wie is verantwoordelijk voor jouw ontwikkeling?
Wie zijn vakinhoudelijke ontwikkeling afhankelijk maakt van zijn werkgever, zegt eigenlijk die ontwikkeling zelf niet zo belangrijk te vinden. Maar je persoonlijke ontwikkeling is wel belangrijk. Daarom is het essentieel dat je daar zelf de leiding in neemt. Als jij het niet belangrijk genoeg vindt om er tijd en geld in te steken, hoe kun je dan van je werkgever verwachten dat die dat wel doet?
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.
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.