Voorspelbaar agile werken?!

Uit het dagboek van Karel, IT projectmanager

Ik kijk tevreden terug op de afgelopen vier weken van het project Pythagoras. Ik werk goed samen met Caroline, de business vertegenwoordigster. Zij voelt zich verantwoordelijk en is druk bezig om de backlog op orde te houden en te prioriteren. Het Integrale team is gestart en neemt de verantwoordelijkheid voor het opleveren van het resultaten op basis van de backlog.

 

Ik leun voldaan achterover in mijn stoel. Mijn oog valt op de planning, voortgangsrapportage en een dashboard van een ander project. Ik vraag mij af of het plannen van dit agile project anders is dan mijn voorgaande projecten? Ik sta op en ga opzoek naar Charmaine.

Plannen in een agile omgeving?

Ik vind Charmaine achter haar bureau. Zij is druk bezig om een stukje te schrijven over agile versus waterval. “Charmaine, kan ik een moment met je sparren over plannen in een agile omgeving?”. Charmaine kijkt op en vraagt mij om te gaan zittenen vraagt: “Wat zijn jouw beelden over plannen in een agile omgeving?”. Ik kijk haar aan en neem een moment om na te denken. Ik antwoord: “Ik denk dat plannen in een agile omgeving nodig is om een idee te hebben van wanneer iets wordt opgeleverd. Met de kanttekening dat de planning onderhevig is aan veranderingen.”. Charmaine reageert: “Klopt. Binnen agile werken heb je inderdaad ook een planning. Heb jij een beeld van wat de belangrijkste elementen zijn?”. Ik geef haar antwoord: “Ik denk dat belangrijke elementen zijn: een geprioriteerde backlog, de omvang van de items op de backlog en wat een team per iteratie kan oppakken.”. Charmaine: “Dit zijn inderdaad belangrijke items maar de voorspelbaarheid van een team is ook nodig.”. “Wat is dat, Charmaine?”, vraag ik. Charmaine: “De mate van voorspelbaarheid is de mate waarin het team conform hun commitment oplevert. Hoe beter de mate van voorspelbaarheid hoe beter het team in kan schatten wat hun commitment is.”. Ik reageer met: “OK. Is mijn beeld correct dat de geschatte doorlooptijd wordt bepaald door de geschatte backlog items in een omvang te delen door de velocity? En op basis van de voorspelbaarheid ontstaat een beeld hoe nauwkeurig de getallen zijn.”. Charmaine: “Klopt. Karel, ga jij managen op de datums die uit de berekening komen?”. Ik kijk haar aan en neem tijd om te reageren. “Het eenvoudigste antwoord is volgens mij nee, want agile werken gaat ervan uit dat de capaciteit van het team vast is en dat de prioriteit op de backlog bepaalt wat een team oppakt en de opleverdatum is daar een gevolg van.”.

Complexiteit

“Complexiteit ontstaat als het team items op moet leveren voor een heel strakke deadline. Ik vind dit een uitdaging.”. Charmaine: “Karel, dat klopt en het is inderdaad een uitdaging. Je kunt hier op verschillende manieren mee omgaan. Ik noem twee mogelijkheden die je in Pythagoras kunt gebruiken. De eerste is door prioritering. Door een prioriteringsmanier te kiezen in je backlog waardoor items bovenaan komen. De tweede mogelijkheid is om de iteratie niet geheel te vullen met zaken die echt moeten.”. Ik reageer tevreden en vraag aan Charmaine “Welke eenheid gebruik jij om te plannen?”. Charmaine begint te lachen. “Karel, dit is een zeer interessante vraag en hierbij zijn verschillende stromingen in agile land. Een stroming voor het meten in punten en de andere is de stroming van uren.”. “Charmaine, wat zou jij mij in dit geval adviseren?”, vraag ik aan Charmaine. Charmaine: “Ik zou nu adviseren om te beginnen met uren, omdat je net begint met een agile traject en parallel daaraan met punten.’.

Uren schrijven is controle

“Belangrijk is om de negatieve context van urenschrijven te managen. De medewerkers kunnen het schatten en vastleggen van uren voelen als een controle, terwijl dit niet het doel is. Het doel is inzicht verkrijgen en met elkaar, het team en jij, te kunnen bijsturen. Het is belangrijk dat de omvang van een item door het team wordt bepaald en niet door iemand anders, zo ontstaat eigenaarschap.”. Karel: “Klinkt interessant, ik ga het met het team bespreken. En hoe zit het met meten in een agile omgeving?” Charmaine lacht: “Karel, vind je het goed als ik hier morgen op terug kom. Ik moet nu naar mijn volgende overleg.”. “Prima!”, zeg ik en loop terug naar mijn werkplek.

Meten is weten en gissen is missen!

Ik zit op mijn fiets onderweg naar mijn werk en denk terug aan mijn eerste dag op de technische school. De eerste les ging over meten. De eerste tekst die de docent op het bord liet zien was Meten is weten en gissen is missen! Hij zei: “Als jullie niet goed meten, hoe weet je dan of iets past of dat je gereedschap is versleten?”. Ik ben benieuwd hoe meten een plaats heeft binnen agile werken. Ik zet mijn fiets in de fietsenstalling en loop naar binnen, hang mijn jas op en loop naar het koffiezetapparaat. Ik tref daar Charmaine in gesprek met Marc. Ik zeg goede morgen en neem een dubbele espresso. Marc vraagt aan mij: “Wanneer kan ik de voorgangsrapportage ontvangen en het dashboard met de eerste KPI’s? Dan kunnen wij in het MT bekijken of wij acties moeten ondernemen.”. Charmaine geeft een politiek correct antwoord: “Ik ga het zo met Karel hebben over het meten van voortgang in een agile omgeving. Ik zal in het eerstvolgende MT uitleg geven.”. “Prima.”,  zegt Marc en hij loopt door naar zijn kantoor.

Transparantie

Charmaine en ik nemen plaats in onze overlegruimte. Ik val met de deur in huis: “Hoe werkt een voortgangsrapportage in een agile omgeving?”. Charmaine legt mij het volgende uit: “Een van de pijlers van agile werken is transparantie. Transparantie betekent dat een aantal KPI’s of andere noodzakelijke informatie over de status van voortgang of de kwaliteit van het product, voor de omgeving inzichtelijk is. Belangrijk is om dit vooraf met je stakeholders af te stemmen.”. Ik reageer met: “Prima, maar je hoort Marc aangeven dat hij wil gaan sturen op basis van deze informatie.”. Charmaine reageert met: “Hoe het MT omgaat met deze informatie, bepaalt de mate van vrijheid die het team en jij voelen om informatie te delen. Een manager of leider dient goed in te schatten hoe hij of zij reageert en acteert op basis van de cijfers. Marc dient zijn leiderschapsstijl en wijze van interveniëren af te stemmen op de informatie en gemaakte afspraken. Is de voortgang niet zoals hij verwacht, dan zou zijn primaire reactie moeten zijn om te gaan informeren hoe dit komt en of hij kan helpen.”. Ik reageer met: “Voor mij is het duidelijk maar hoe zit het met meten in agile teams?”. Charmaine reageert met: “Dat het team continue verbetert is belangrijk. Het team doet dit na elke iteratie of regelmatig als zij op een Kanban manier samenwerken. Continu verbeteren kan niet zonder kwalitatieve of kwantitatieve metingen. Daarom is het belangrijk dat het team gezamenlijk of met behulp van een coach bepaalt wat het wil meten. Wat je meet, moet je regelmatig evalueren, omdat dit per iteratie kan verschillen.“.

Technische schuld

“Het team gebruikt metingen ook om te bepalen hoeveel technische schuld zij hebben en of een software-onderdeel opnieuw geschreven moet worden.”. Ik reageer met: “Wat bedoel je met technische schuld?”. Charmaine reageert: “Technische schuld vertaal ik, voor de eenvoud, met uitgesteld onderhoud. Dit is de tijd die het team in de applicatie moet stoppen om het systeem goed onderhoudbaar te maken of op de laatste standaarden te brengen. Een voorbeeld van technische schuld is het snel oplossen van een productie-incident, maar het team weet dat het niet netjes is geprogrammeerd. Het team moet na het oplossen nog tijd investeren om de code goed onderhoudbaar te maken. Een ander voorbeeld is als code niet meer wordt gebruikt maar deze is nog wel aanwezig in de applicatie. Deze code moet op enig moment worden uitgebouwd. Het laatste voorbeeld dat ik wil noemen, is achterlopen in versies van software. Soms wordt dit uitgesteld omdat er haast wordt gemaakt met het opleveren van functionaliteit. Het upgraden van de applicatie naar een nieuwe versie kost tijd en deze moet op enig moment worden geïnvesteerd.”. Ik reageer met: “Dank je wel, maar wat bedoel je met je laatste opmerking over opnieuw schrijven?”. Charmaine: “Opnieuw programmeren van een applicatie kan op een bepaald moment verstandig zijn, omdat de onderhoudbaarheid lastig is geworden. De oorzaak is vaak dat er al zoveel aan de code is bijgeprogrammeerd of aangepast dat nieuwe aanpassingen of het oplossen van problemen, langer duurt. Daarom is het belangrijk om inzicht te hebben in hoelang je als team ergens over doet. Als je dit uitzet in de tijd, krijg je inzicht of het oplossen van een bevinding langer is gaan duren. Op basis van deze historische informatie kan het team besluiten dat het teveel tijd kost en een herprogrammering kwantitatief onderbouwen.”.

Metrieken

Karel: “Interessant allemaal. Welke metrieken zou jij adviseren?”. Charmaine: “Karel, er zijn vele metrieken beschikbaar op allerlei vlakken. Mijn advies is: laat iedereen zich verdiepen in de literatuur of in de ontwikkelsystemen die jullie gebruiken. Bepaal welke informatie je wilt of denkt in de toekomst te willen meten. Bepaal, op basis van deze informatie, welke gegevens nodig zijn om nu of in de toekomst te meten. Als je ooit iets met uren wilt gaan doen is het verstandig om uren vast te leggen. Ik geef een paar voorbeelden van wat je zou kunnen meten. De waarde/geïnvesteerde eenheid meten om te bepalen wat de investering aan waarde oplevert. Een ander voorbeeld is de productiviteit van een team. Bijvoorbeeld in het aantal functiepunten per uur. Functiepunten klinkt oubollig maar ik heb nog geen andere genormeerde manier gevonden om opgeleverde functionaliteit te meten. Derde partijen kunnen de metingen ook uitvoeren. Een aantal andere metingen hebben wij gisteren al besproken, zoals velocity en de mate van het nakomen van commitment.”. Karel: “Dank je voor deze sessie en ik ga in overleg met stakeholders en het team over wat wij gaan meten.”. Wij verlaten de vergaderkamer en lopen samen naar het koffiezetapparaat. Charmaine vraagt: “Hoe doet Caroline het?”. “Prima, zij pakt haar rol goed op en wij leren met zijn allen hoe de rol van de PO, het team en mijn rol vorm te geven.”, geef ik als reactie. Wij pakken nog een kop koffie en ieder vervolgt zijn weg.

 Vijf overwegingen voor voorspelbaar agile:

  1. Agile is adaptief plannen. Wel plannen, en aanpassen op basis van veranderende omstandigheden
  2. Neem een eenheid op basis waarvan je de backlog items inschat m.b.t. de omvang van het werk en gebruik deze eenheid om de velocity van het team te bepalen. Zo kun je plannen. Er is niets mis mee om dit in uren te doen
  3. Bepaal de voorspelbaarheid van een team. Dit is de mate waarin het team zijn commitment nakomt
  4. Meten is weten en gissen is missen. Binnen agile werken is meten gebruikelijk om te kunnen verbeteren
  5. De wijze waarop managers omgaan met de voortgang en meetresultaten, bepaalt de openheid van mensen en teams

 

Blogdetails

01-03-2019
Blog
  • Erik van Daalen

    Senior Project Manager

    Pragmatische zelfstartende traditioneel / agile projectmanager die zich kenmerkt door zijn drive, besluitvaardigheid en duidelijkheid. Analyseert vraagstukken snel, scherp en gestructureerd. Neemt ownership, heeft oog voor ieders belangen, en zorgt voor verbinding binnen en buiten zijn projectorganisatie.

    Meer over Erik van Daalen

  • Erik van Daalen

Wil je meer weten?

We vertellen je graag meer over onze aanpak van het succesvol managen van projecten en programma’s.

Bel ons op 030 – 600 47 79 Stuur ons een bericht