Agile zegt flexibel om te kunnen gaan met wijzigingen. Ze juicht wijzigingen zelfs toe en stimuleert voortschrijdend inzicht. Een wijziging is namelijk een teken dat je een beetje beter zicht op de daadwerkelijke behoeften van de business hebt gekregen.

Maar wijzigingen in de reeds opgestelde requirements veroorzaken ook extra werk. Daar wordt niemand blij van, zeker het management niet. En al helemaal niet als het negatieve impact heeft op de planning. Dit is precies waar het wringt in organisaties waar het management onvoldoende mee verandert in de transitie van een traditionele naar een agile werkwijze.

Ze willen dan meteen weten hoeveel extra tijd de wijziging kost.

En wie moet vervolgens gaan uitzoeken wat de wijziging precies inhoudt en hoe groot de impact is?

Als je pech hebt, kijkt iedereen naar jou en wordt het bepalen van de impact een taak van de analisten. Ten onrechte, want het druist in tegen de teamgedachte en gezamenlijke verantwoordelijkheid van agile. Het bepalen van de impact opnemen in je agile werkwijze, is waarschijnlijk de best haalbare optie in organisaties die nog traditionele planningen en impactanalyses hebben.

Met de volgende 3 stappen kom je tegemoet aan de informatiebehoefte van traditionele managers én verstoor je de agile werkwijze zo min mogelijk.

Stap 1: Nieuwe of bestaande user story

De product owner zoekt (samen met een analist) uit of de gewenste wijziging een nieuwe user story of een wijziging op een bestaande user story moet worden.

Als men genoegen neemt met een grove urenschatting vraag je de ontwikkelaars de omvang van de wijziging te schatten in t-shirt maten of in story points (zie stap 3). Na goedkeuring van de wijziging voegt de product owner de nieuwe of gewijzigde user story op de juiste plek op de product backlog in.

Laat stakeholders duidelijk zien welke user stories naar achteren schuiven door het invoegen van de wijziging. Plaats de wijziging in het grotere geheel en in de context van de overall businesswaarde die het systeem moet gaan leveren. Leg de stakeholders vervolgens een keuze voor: Wat is belangrijker, user story xyz of de wijziging?

Vragen hoe belangrijk de wijziging is kun je beter niet doen. Evenals vragen hoe snel de wijziging doorgevoerd moet worden. Dan krijg je namelijk steevast het antwoord dat het meteen of zo snel mogelijk moet.

Als een nauwkeurige inschatting op basis van gedetailleerde requirements vereist is, vervolg je met stap 2 en 3.

Stap 2: Refinement

Maak het verder uitwerken van de wijziging/user story onderdeel van jullie (wekelijkse) product backlog refinement. Als het goed is detailleren daarin de product owner/analist, de ontwikkelaars en eventueel de betreffende stakeholder samen de user story. Zodra de ontwikkelaars genoeg informatie hebben om de omvang ervan in te schatten, ben je klaar met het verfijnen van de user story.

Vergeet de afhankelijkheden met andere teams niet. Geef het aan als je denkt dat de wijziging ook werk voor één of meer andere teams tot gevolg heeft. Zij moeten dan immers ook een impactanalyse uitvoeren.

Stap 3: Schatting

De ontwikkelaars schatten de omvang van de user story in. Hoewel traditionele managers willen weten hoeveel uren het gaat kosten om de wijziging te realiseren, adviseren wij om altijd gebruik te maken van relatieve schattingen (in story points). Die zijn namelijk betrouwbaarder en gemakkelijker te geven dan een schatting in uren.

Met schattingen in story points is de velocity (gemiddelde ontwikkelsnelheid van het team) vast te stellen. Daarmee kun je met behulp van de product backlog (mits geprioriteerd en ingeschat) aangeven in welke sprint welke stories aan de beurt zijn. En ook hoe alles door invoegen van een wijziging gaat schuiven.

Wil het management de impact op de planning toch in uren en geld uitgedrukt zien? Dan is de agile planning vrij eenvoudig om te rekenen naar een traditionele planning. Eventueel met een beetje hulp van de projectmanager of PMO (Project Management Office).

Onze ervaring is dat het management goed overweg kan met het inzicht dat de agile plannings- en voortgangsoverzichten geven. Wel hebben ze dikwijls even tijd nodig om aan de nieuwe zienswijze te wennen. Voeg daarom bij elke urenschatting ongevraagd een burn down chart toe (en gebruik de visuele plannings- en voortgangsoverzichten van agile vooral ook zelf binnen je eigen team).

Traditionele impactanalyse in een agile jasje

De hierboven beschreven werkwijze is voor organisaties met traditionele planningen en fixed price projecten waarschijnlijk de best haalbare werkwijze. Toch is het goed om je te realiseren dat het in feite een traditionele impactanalyse in een agile jasje is.

Vaak is daar ook een RFC (request for change) proces aan gekoppeld, met de ongewenste effecten die daarbij horen. Zo werpt het bijvoorbeeld een drempel op om wijzigingen (beter gezegd verbeteringen) door te voeren. En wat denk je van de tijd die het kost om een impactanalyse uit te voeren.

Je hebt meer invloed op je omgeving dan je denkt. Dat laten we je ervaren in onze online masterclass Cocktail van agile en traditionele requirements voor agile analisten die samenwerken met traditioneel denkende stakeholders.

Wat was ook alweer de reden dat je organisatie agile is gaan werken? Een kortere time to market? Meer flexibiliteit? Meer businesswaarde?

Is het management zich bewust van de bijeffecten en negatieve consequenties van impactanalyses, een RFC proces en traditionele planningen? Misschien is het de moeite waard die bewustwording op gang te brengen.

Je zou inzichtelijk kunnen maken hoe de impactanalyses jullie werkproces verstoren. Dus hoeveel tijd gaat eraan verloren? Ofwel hoeveel extra tijd hadden jullie aan het realiseren van businesswaarde kunnen besteden?

Om het nog concreter voor het management te maken: welke functionaliteit of user stories hadden jullie in die tijd kunnen opleveren?

Nicole de Swart & Priya Soekhai

Misschien vind je dit ook interessant

2 reacties

  • Randal Pieplenbosch

    Wat je in de praktijk veel tegenkomt is dat in de impact analyse vaak alleen een inschatting van tijd / kosten wordt opgenomen. Een goede impact analyse bevat de impact van een voorgestelde wijziging op verschillende onderdelen zoals:

    – Bedrijfs- en werkprocessen;
    – Organisatie;
    – functionaliteit(en);
    – Koppelvlakken;
    – Infrastructuur;
    – Beheer;
    – Opleidingsmaterialen/ werkinstructies;
    etc.

    Wanneer je een impact analyse volledig en goed uitvoert kan het zijn dat op basis van de impact, en niet eens de uren/kosten, wordt besloten om een wijziging niet uit te voeren. Zo kan een wijziging vanuit een specifiek bedrijfsproces impact hebben op een ander bedrijfsproces wat niet wenselijk is. Een impact analyse zou ook een advies moeten bevatten over het wel of niet uitvoeren van een wijziging.

    In de praktijk worden impact analyses dusdanig summier uitgevoerd dat de besluitvorming zich vaak alleen concentreert op uren en kosten.
    Het in kaart brengen van de schatting is goed maar zeker niet het belangrijkste.

    Hoe ga je in een agile omgeving een uitvoerige impact analyse uitvoeren zoals hierboven is aangegeven?

    • Nicole de Swart

      Bedankt voor je vraag Randal. En eens dat je in een impactanalyse veel meer aspecten mee zou moeten nemen dan alleen uren en kosten.
      Een agile team wijzigt elke sprint het software-increment (productierijpe software als het goed is) die ze de voorgaande sprint hebben opgeleverd. Impactanalyses zijn een integraal onderdeel van het iteratieve en incrementele agile proces. Elke sprint bepaalt het team de impact van de wijzigingen die ze willen doorvoeren. Of beter gezegd: Ze bekijken op welke manier ze de gewenste businesswaarde het beste kunnen leveren. (Dat is niet hetzelfde dan afgesproken requirements of user stories implementeren).

Geef een reactie