Tag professionaliteit

Het is niet jouw verantwoordelijkheid een onmogelijke deadline te halen

Er gebeurt iets wonderlijks wanneer je tegen een ontwikkelteam zegt dat die en die feature een deadline heeft: ze gaan hun best doen om die deadline te halen. Dat is een nobel streven, natuurlijk. Maar het is ook een gevaarlijk gegeven. Want niet elke deadline voor elke feature is even realistisch. Een team dat, ongeacht de haalbaarheid, gaat rennen om die deadline te halen, werkt zichzelf – en haar stakeholders – in de nesten.

Waarom zou je naar tech podcasts luisteren?

Je wordt beïnvloed door dat waar je mee omgaat. Zorg er dus voor dat je omgaat met mensen met betere ideeën dan jijzelf. Podcasts zijn een middel om een bepaalde houding te cultiveren. Die houding is er één van: ik mag tevreden zijn - trots misschien zelfs wel - met waar ik nu sta, maar ik weet dat het nog beter kan. Hoe? Door te luisteren naar hen die het beter doen dan ik.

Tijdreis

Ik vroeg mijn collega’s: “Wat doet dit ding precies?” - waarop ze prompt de code tevoorschijn haalden en me stap voor stap door het importproces loodsten. Het was alsof ik terug werd geslingerd naar het begin van mijn ontwikkelcarrière, toen we met z’n allen een twaalf jaar oude legacy applicatie onderhielden die alleen te doorgronden was door nauwgezet de code te doorlopen. Wat blijkt: tijdreizen bestaat - je hoeft alleen maar bij een ander team te buurten.

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.

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.

Bewuste technische schuld

Is technische schuld erg? Niet per se, zolang de keuze voor technische schuld maar een bewuste is. Als het team duidelijk maakt dat de oplossingsrichting technische schuld met zich meebrengt en afdwingt dat er op middellange termijn tijd wordt vrijgemaakt om die op te ruimen, hoeft die schuld geen probleem op te leveren. Integendeel: dankzij die schuld zijn we in staat om op korte termijn - vóór de deadline - waarde te leveren.

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?

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?

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.