Effectiviteit en Efficiëntie

In de vorige blog stond systeemontwikkeling als proces centraal. We zagen dat er op hoofdlijnen drie ontwikkelaanpakken zijn: waterval, iteratief incrementeel en agile. In deze blog kijken we naar twee begrippen die vaak worden gerelateerd aan processen: effectiviteit en efficiëntie. Helaas worden effectiviteit en efficiëntie vaak in één adem genoemd met als gevolg dat ze in het dagelijks leven nogal eens door elkaar heen worden gehaald. Voor de business analist is effectiviteit een van de belangrijkste woorden. Voordat ik uitleg waarom dit zo is zal ik eerst de twee begrippen beschrijven. Als voorbeelden zal ik daarbij gebruik maken van een aantal one-liners van Johan Cruijff.

Effectiviteit

Onder effectiviteit wordt verstaan de mate waarin inspanningen en/of uitgaven bijdragen aan de realisatie van een beoogd doel of wel ‘de goede dingen doen’. Johan Cruijff omschreef effectiviteit in de ‘voetballerij’ als volgt:

"Kijk, de bal moet minimaal tussen die twee palen."

Efficiëntie

Onder efficiëntie wordt verstaan: de mate waarin iets veel en snel resultaat heeft, ofwel ‘de dingen goed doen’. Meestal kan dit worden vertaald in de verhouding tussen de prestaties of activiteiten enerzijds en de hiervoor ingezette middelen anderzijds. Centrale vraag is daarbij: staan de kosten in verhouding tot de opbrengsten? Cruijff had ook een paar prachtige one-liners over efficiëntie:

"In voetbal is het simpel: je bent op tijd of je bent te laat. Als je te laat bent, moet je zorgen dat je op tijd vertrekt“

"Als je ergens niet bent, ben je óf te vroeg óf te laat"

Je kunt als team dat een informatiesysteem ontwikkelt heel snel te werk gaan, maar als je met z’n allen het verkeerde systeem bouwt (hetgeen helaas nogal eens voorkomt) dan is de inspanning van het gehele team voor niets geweest. In vele projecten en programma’s is de (business) analist verantwoordelijk om ervoor te zorgen dat het ontwikkelteam de goede dingen op het juiste moment oppakt. De analist brengt requirements in kaart en het ontwikkelteam programmeert en test op basis van deze requirements. Onthoud als analist dus dit:

Effectiviteit vóór Efficiëntie!

Maar hoe zorg je voor effectiviteit?

Zoals ik reeds heb geschreven in eerdere blogs is het vakgebied Business analyse onder te verdelen in 4 deelgebieden: Strategie analyse, Proces analyse, People analyse en Product analyse. Door eerst de doelstellingen van een organisatie goed in kaart te brengen (o.b.v. een strategie analyse) en de daarbij horende processen te modelleren en te analyseren (procesanalyse) levert de business analist een belangrijke inspanning die ervoor moet zorgen dat het juiste softwareproduct kan worden ontwikkeld (of gekocht).

Ook met betrekking tot het in kaart brengen van de gewenste producteisen speelt een analist een voorname rol (als product analist). In de vorige blog kon je lezen dat een analist in een RUP-project veel aandacht besteedt aan het in kaart brengen van de stakeholders, hun behoeften en de bijhorende product features (high level system requirements). Ook stakeholder consensus met betrekking tot deze featurelijst is belangrijk want als stakeholders het niet eens zijn over wat een product moet doen dan zal daar eerst energie in gestoken moeten worden alvorens een product kan worden gebouwd. In het kort komt het erop neer dat de analist ervoor zorgt dat het softwareproduct business value én stakeholder value oplevert.

Pas op voor analyseverlamming!

Hoewel effectiviteit een erg belangrijk woord is voor de analist, moet hij/zij beducht zijn op analyseverlamming (‘analysis paralysis’). In geval van analyseverlamming (dit kwam/komt nogal eens voor in traditionele watervalprojecten) wordt er dermate gefocust op effectiviteit dat men blijft analyseren zonder concrete resultaten op te leveren. Ik heb ooit eens een cursist gehad die sprak over een inception-fase van 2 jaar! Normaliter duurt deze maximaal 2 maanden.

Om analyseverlamming te voorkomen zal er dus naast effectiviteit voldoende aandacht besteed moeten worden aan efficiëntie waardoor verbeteringen niet alleen worden bedacht, maar ook in de organisatie worden doorgevoerd. Dit is naast laagdrempeligheid een van de voordelen van Scrum: er worden met dit framework al snel concrete resultaten behaald hetgeen betekent dat je ook snel kunt bijsturen indien nodig.

Maar om in Cruijff-termen te blijven: ‘elk voordeel heb z’n nadeel’. Door de laagdrempeligheid gaan ontwikkelteams in de praktijk vaak té snel systemen bouwen zonder dat men de toegevoegde waarde van het nieuwe systeem goed heeft begrepen. Het is van groot belang – met name in agile ontwikkelaanpakken waar men de neiging heeft om ‘gewoon te beginnen’ – dat men vooraf goed weet wat de doelen zijn van een project/product. In een Scrum-project is het de Product Owner die verantwoordelijk is voor het definiëren van de juiste system requirements op het juiste moment. Aangezien de productscope aan verandering onderhevig is - zie de paradigma-verschuiving uit de vorige blog - is het van belang dat de Product owner de Product Backlog gedurende het gehele project voortdurend onder de loep neemt.

Discover to deliver

In het boek ‘Discover to deliver’ stellen Ellen Gottesdiener en Mary Gorman dat lean en agile productontwikkeling begint met een ontdekkingstocht (discovery) waarin eerst de contouren van een nieuw product in kaart gebracht (de stipjes in de onderstaande figuur) en waarin langzaam duidelijk wordt wat de kenmerken (epics of stories) moeten zijn van het nieuwe product.

Bron: EBG Consulting

Op basis van de productkenmerken kunnen de teammembers in het deliver-deel een softwareproduct bouwen dat vervolgens aan de stakeholders kan worden voorgelegd. Op basis van de productdemo die na de delivery plaatsvindt, weten de stakeholders beter wat ze precies willen en worden nieuwe requirements opgesteld. Dit is de volgende discoverronde, gevolgd door een nieuwe deliverronde, etc. Deze lemniscaat van discover en deliver is een on-going proces van systeemontwikkeling. Door middel van IKIWISI (zie vorige blog) wordt gaandeweg steeds meer functionaliteit aan het product toegevoegd totdat het uiteindelijke product is gebouwd.

Tussen de twee lussen discover en deliver kan de lijst met product features (de product backlog of Work Items List) worden geplaatst, waarvan de meeste items nog nadere specificatie nodig hebben. Items met de hoogste prioriteit komen bovenaan de lijst te staan. In de onderstaande figuur is de lemniscaat op een andere wijze weergegeven: een linker (discovery)cirkel waarin de business analist/product owner verantwoordelijk is voor het plaatsen van de goede items op de lijst. Effectiviteit is hierin het sleutelwoord. Dit zijn namelijk de items die ervoor zorgen dat het product tegemoet komt aan de business requirements plus de behoeften van stakeholders (stakeholder requirements).

Product analyse

In de rechter (delivery)cirkel zorgt het ontwikkelteam ervoor dat de items op de backlog worden ontwikkeld tot een softwareproduct dat zo goed mogelijk aansluit bij de behoeften van de stakeholders. Efficiëntie is hierbij het sleutelwoord: ieder item wordt ontwikkeld met minimale verspilling. Doordat de ‘discovery-kant’ steeds ‘de goede dingen’ op de backlog zet, kunnen de ontwikkelaars zich concentreren op efficiëntie (‘ de dingen goed doen’) door steeds de bovenste items van de lijst op te pakken en te ontwikkelen. Dit wordt het pull-effect genoemd, een term die afkomstig is uit de Lean-filosofie. Meer over Lean in een volgende blog.

Double diamond

The British Design Council (2005) voegt aan Discover en Deliver nog 2 extra stappen toe: Define en Develop. Ze stellen ieder ontwerpproces voor als een ‘double diamond’, zie onderstaande figuur.

Double diamond

In de eerste ‘diamant’ staat effectiviteit centraal: hierbij draait het voornamelijk om de Waarom-vraag en de Wat-vraag. De vorm ontstaat omdat het Discover-deel meestal een divergerend (creatief) proces is waarin vele ideeën worden bedacht (de lijnen lopen uit elkaar), gevolgd door een convergerend proces ‘define’ waarin de lijnen weer naar elkaar toe lopen. Door middel van ‘define‘ wordt er een lijst met eisen opgesteld waaraan het product dient te voldoen. Deze vormt de basis voor het ontwikkelteam om over de oplossing na te denken en de ontwikkeling van het product te starten (of uit te breiden).

Product Backlog Refinement

In Scrum is ook een duidelijk onderscheid te maken tussen effectiviteit en efficiëntie. Zie onderstaande figuur. Hoewel het framework met name gericht is op efficiëntie, wordt effectiviteit bereikt door een Product Owner (PO) aan te stellen die een Product Backlog bijhoudt en prioriteert. Zoals is beschreven in de vorige blog is dit een lijst die aan voortdurende verandering onderhevig is. Deze voortdurende verfijning van de lijst met requirements wordt Product Backlog Refinement (of Backlog grooming) genoemd.

De Scrum Guide [1] definieert Product Backlog Refinement als volgt:

“Product Backlog verfijning (“Refinement”) is het toevoegen van detail, schattingen en volgorde aan de items op de Product Backlog. Dit is een doorlopend proces waarbij de Product Owner en het Ontwikkelteam samenwerken aan de details van de Product Backlog items. Gedurende Product Backlog Refinement worden items beoordeeld en bijgewerkt. Refinement neemt gewoonlijk niet meer dan 10% van de capaciteit van het Ontwikkelteam in beslag. Echter, Product Backlog Items kunnen op elk moment worden bijgewerkt door de Product Owner en naar de Product Owner’s eigen beoordeling. Product Backlog items met een hogere rangorde zijn normaliter duidelijker en meer gedetailleerd dan die met een lagere rangorde. De schattingen zijn meer precies vanwege de hogere mate van duidelijkheid en detaillering. Hoe lager de rangorde, hoe minder details. De Product Backlog items waarmee het Ontwikkelteam de komende Sprint aan de slag gaat zijn zo ver verfijnd dat elk item “Klaar” kan zijn binnen een Sprint. De Product Backlog items die door het Ontwikkelteam “Klaar” kunnen zijn binnen een Sprint worden beschouwd als “Ready” voor selectie in een Sprint Planningsbijeenkomst. Product Backlog items verkrijgen deze mate van transparantie over het algemeen door de verfijningsactiviteiten die hierboven beschreven staan. Het Ontwikkelteam is verantwoordelijk voor alle schattingen. De Product Owner mag het Ontwikkelteam beïnvloeden door te helpen bij het begrijpen en maken van afwegingen, maar de mensen die het werk moeten doen maken de uiteindelijke schatting.”

Uit bovenstaande blijkt dat Product Backlog Refinement in feite bestaat uit 3 onderdelen:

Prioritering van de backlog items. Dit is de verantwoordelijkheid van de PO.
Detaillering van de bovenste backlog items. Dit is de verantwoordelijkheid van de PO.
Inschatting van de inspanning om de items te realiseren. Dit is de verantwoordelijkheid van het ontwikkelteam.

De Product Owner start met het prioriteren van de items, werkt vervolgens de bovenste items in detail uit en communiceert deze naar de teamleden opdat zij een inschatting kunnen doen van de inspanning en daarmee kunnen bepalen wat er allemaal in de volgende sprint kan worden gerealiseerd.

Omdat de detaillering (stap 2) een specialisme is van analisten, zie je in de praktijk vaak dat zij de Product Owner ondersteunen met het detailleren van de requirements of deze taak zelfs geheel op zich nemen (meestal als een van de teamleden). Uiteraard is er dan voortdurende afstemming nodig met de Product Owner. Een andere reden waarom Product Owners deze taak uitbesteden is omdat ze er vaak te weinig tijd voor (over) hebben. Meer hierover in een volgende blog.

Samenvatting

In deze blog hebben we gekeken naar de begrippen effectiviteit en efficiëntie in systeemontwikkelingsprojecten. De analist concentreert zich met name op effectiviteit. Hij/zij doet dit door zich te focussen op de stappen discover (welke behoeften hebben we eigenlijk?), define en refine (wat willen we precies?). In Scrum-projecten is de Product Owner degene die hiervoor verantwoordelijk is. Meestal wordt de PO ondersteunt door een analist bij het opstellen en detailleren van de requirements. Ten eerste omdat analisten gewend zijn om eerst business en stakeholder requirements op te stellen en zich dan pas te concentreren op een (software)product. Ten tweede zijn zij een expert in het aanscherpen van requirements tot een detailniveau waarmee ontwikkelaars een gerichte inschatting van de inspanning kunnen doen voor de volgende sprint.

Door de enorme hoeveelheid taken en verantwoordelijkheden van de product owner en daarbij komende vaardigheden hebben PO’s vaak te weinig tijd om ervoor te zorgen dat ‘de goede dingen’ kunnen worden opgepakt door het ontwikkelteam. De analist kan in die gevallen prima fungeren als zijn/haar rechterhand. Meer hierover in volgende blogs.

vorige pagina