Achieving ‘maintainable pace’


Gemiddeld gezien lopen software-projecten uit, staan ontwikkelaars onder druk en raken projectleiders gestresst. Deze optelling is niet goed voor de mensen, niet goed voor de kwaliteit en uiteindelijk niet goed voor de portomonee. Een aantal slimme koppen kwamen bij elkaar en schreef in het Agile manifesto dat de software-productie een ‘maintainable pace’ dient te hebben. Het tempo binnen een project moet vol te houden zijn. Makkelijk gezegd, maar hoe kom je tot zo’n houdbaar tempo? Vorige week hebben we binnen Octavalent opnieuw al het geplande werk afgekregen. Wat betekent dat en hoe doen we dat?

Iedere maandagochtend houden we de zogenaamde weekopening. In deze vergadering, waarbij iedereen aanwezig is, bespreken we de voorgaande week en plannen we het werk voor de komende week. Dit geplande werk is niet zo maar een gedachte, maar zien we als een commitment. Hoe gaat dit plannen in zijn werk?

Een software-project hakken we op in zo klein mogelijk stukken: de stories. Uiteindelijk bestaat een groot project daardoor uit enkele tientallen handzame stories. Iedere story kennen we een aantal punten toe. 1 punt betekent dat het niet veel werk is, niet complex is, en niet veel risico behelst. 2 punten betekent letterlijk 2 keer zoveel als 1, en 8 punten betekent dus 4 keer zoveel als 2 punten. Door punten te gebruiken in plaats van uren (en dit te schatten middels planningpoker) blijkt het aantal punten redelijke goed te kloppen.

Door stories in te plannen in een week, kun je de punten bij elkaar optellen en zo komen tot een totaal aantal punten voor die week. Achteraf kun je tellen hoeveel punten je daadwerkelijk gedaan hebt. Door dit een lange periode vol te houden (en hier zit de crux), bouwden we ervaringsstatistieken op. Zo weten we dat we gemiddeld 9 punten per FTE kunnen doen. Nu wordt het al gemakkelijker.

Tel op maandag de beschikbaarheid van de ontwikkelaars (in FTE), vermenigvuldig dit met 9 en dan hebben we het aantal punten dat we de komende week inplannen. Aangezien de stories punten kregen vóór het maken van deze rekensom, is het daarná slechts een kwestie van bepalen welke stories in de komende week op het planbord komen.

So far, so good. Maar we zijn er niet. Niets garandeerd dat de week niet overhoop wordt gehaald door haastklussen, bugmeldingen en tegenvallers. Haastklussen zijn heel simpel. Dat kan altijd, maar moet geruild worden met eerder ingepland werk. Dit is het principe van: “Je wilt dat XYZ in de planning komt? Wat gaat er dan uit de planning?”.

Bugmeldingen zijn lastiger. Een plotselinge test-woede van een collega of klant kan een stortvloed van kleine verbeterpunten opleveren. Alles is even belangrijk, maar het is de vraag of het nu moet. Bugs die geen showstoppers zijn, stellen we zonder pardon uit tot de volgende week. Blijkt op die maandag dat er veel bugs opgelost moeten worden, dan stellen we de productiviteits-schatting navenant bij van 9 naar 8 (of 7 of 6). Zijn er weinig bugs, dan gaat de productiviteits-schatting naar 10, of wellicht 11. Door bugs niet direct op te pakken, maar in te plannen, creeëren we een hoop rust wat de kwaliteit ten goede komt.

Tot slot kan het werk altijd tegenvallen. Een 2-punter (statistische gezien 6 uur werk) kan 3 dagen in beslag nemen. Weg planning? Niet helemaal. We hebben nog een sluitpost. Die sluitpost heet ‘Verbeteringen’. Verbetering zijn werkzaamheden waarvan het ontwikkelteam vindt dat ze nodig zijn. Voorbeelden zijn: wijzigingen in de architectuur, het inzetten van een nieuw technologie of het upgraden van een component. Dit zijn werkzaamheden die niet onmiddelijk moeten gebeuren. Ze kunnen makkelijk worden uitgesteld naar de volgende week. En dat doen we dan ook.

Hier zit wel een valkuil. Door verbeteringen als sluitpost te hanteren, loop je het risico er nooit aan toe te komen. Wij hebben dit ondervangen door voor verbeteringen een budget te bepalen, en wel 10% van alle ontwikkeluren. Dit tellen we per kwartaal. Stel dat we na drie weken in het kwartaal slechts 5% hebben besteed aan verbeteringen, dan weten we dus dat we voor de volgende week een lagere productiviteit moeten aanhouden.

 

 

 

 

 

 

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s