Agile: modewoord, methode of (veel) meer?

Zegt een kip tegen een varken: ‘Zullen we een restaurant beginnen?’ Zegt het varken: ‘Misschien. Hoe gaan we het noemen?’ Kip:’Ik zat te denken aan Ham-n-eggs’. Varken: ‘Nee, dank je. Dan zou ik namelijk committed zijn en jij alleen maar involved.’ En zo zijn er wel meer grappen over Agile werken, vooral gemaakt door hen die het slechts als een buzzword zien. Maar waarom slaat het dan zo aan als het weinig om het lijf zou hebben?

Agile Manifesto als ‘bijbel’

Bij Ambrero werken we al twaalf jaar Agile. In die tijd zijn we flink gegroeid en hebben we heel wat tevreden en vooral wendbare, innovatieve klanten om ons heen verzameld. Ook vandaag de dag werken we met zo’n 70% van hen volgens de Agile-methodiek. Daarbij blijven we dichtbij de uitgangspunten van de ‘bijbel’ van deze methode: het Agile Manifesto. Zoals met bijbels gebruikelijk is, gaat iedereen er op een gegeven moment zijn eigen draai aan geven. Of de aanpak toepassen op gebieden en processen waar het helemaal niet voor bedoeld is. Hetzelfde geldt trouwens voor bijvoorbeeld een militaire commandostructuur. Die werkt prima in situaties waar geen tijd is voor overleg maar zouden we voor jouw organisatie zeker niet aanraden.

Waarom tóch Agile?

Als ervaringsexpert kennen we alle valkuilen natuurlijk als geen ander, zoals onvoldoende competenties bij de klant voor deze manier van werken. Of rollen die door elkaar gaan lopen. Daar zijn we ook altijd alert op. De voordelen van Agile wegen ruimschoots op tegen de eventuele nadelen. Die voordelen zijn in grote lijnen de nadelen van de watervalmethode, maar dat is iets te makkelijk en onduidelijk. Daarom de belangrijkste voordelen nog maar eens op een rijtje:

  • Een realistische planning en altijd inzicht in de voortgang
  • Effectief werken en open communicatie
  • Na elke sprint een stuk werkende software voor de klant
  • Er wordt uitsluitend functionaliteit ontwikkeld die ook daadwerkelijk wordt gebruikt
  • Mogelijkheid tot bijsturen tijdens de ontwikkeling op basis van voortschrijdend inzicht en veranderende markteisen

Deze voordelen zijn in wezen een vertaling van de uitgangspunten van het Agile Manifesto:

  • Mensen en hun onderlinge interactie boven processen en hulpmiddelen
  • Werkende software boven allesomvattende documentatie
  • Samenwerking met de klant boven contractonderhandelingen
  • Inspelen op verandering boven het volgen van een plan

Ambrero Blog - Agile modewoord methode of veel meer

Banken en Agile werken

Desondanks zijn er genoeg situaties en bedrijven waar een andere werkwijze toch beter past. Dit geldt niet in de laatste plaats voor organisaties die sterk hiërarchisch gestructureerd zijn en/of waar mensen niet over de vereiste vaardigheden beschikken. Opvallend genoeg, en misschien tegelijkertijd ook veelzeggend, laat juist de financiële sector (lees: hiërarchisch, legacy-systemen) zich de laatste tijd in met Agile. Die omslag is deels ingegeven door de snel veranderende marktomstandigheden, inclusief nieuwe technologieën. Dus laat die grappen nog maar een tijdje komen. We gaan ons pas zorgen maken als er niet meer gelachen wordt.

Bart Overbeek

Het product backlog prioriteren; 3 methodes

Ons vorige blog ging over het belang van prioriteiten stellen bij het ontwikkelen van een MVP. En de valkuilen die je hierbij kunt tegen komen. In deze blog belichten we drie beproefde methodes om functionaliteit te prioriteren in je product backlog. Basisvoorwaarde: een heldere productvisie.

Start met je productvisie

In een agile traject werk je iteratief op basis van voortschrijdend inzicht. Toch is het handig om vooraf je productvisie te formuleren. In deze productvisie koppel je de behoefte van je doelgroep aan de doelen van je product. De formulering van een productvisie dwingt je als product owner om goed na te denken over het hoofddoel dat je wilt bereiken. Het zorgt ook voor helderheid bij het projectteam. Binnen het Scrum proces is een heldere productvisie een belangrijk middel om je bedoelingen te toetsen bij de diverse stakeholders. Gedurende de voortgang van het project helpt de productvisie om de juiste prioriteiten te stellen.

Drie methodes om het product backlog te prioriteiten

Zodra je de productvisie hebt geformuleerd wordt het dus makkelijker om de prioriteiten te bewaken. Bij de ontwikkeling van software wordt vaak de Scrum methode gehanteerd, waarin functionaliteit is geordend op het product backlog: een geprioriteerde lijst van de resterende functionaliteit, gebaseerd op het toekomstbeeld en de concrete vereisten van de applicatie. Functionaliteit wordt omschreven in user stories: korte, specifieke beschrijvingen van functionele vereisten. De product owner brengt hier prioriteiten in aan en kijkt daarbij steeds of een user story van genoeg toegevoegde waarde is voor de visie. De volgende drie methodes zijn beproefde methodes om het backlog te prioriteren.

1. MoSCoW-methode

Dit is de meest bekende manier om de prioriteiten te ordenen. Maar voor wie deze methode niet kent: bij de MoSCoW-methode zet je de volgende punten onder elkaar:

  • Must-haves,
  • Should-haves,
  • Could-haves en
  • Would-haves

Dit is de makkelijkste manier van agile prioriteiten stellen, maar in de praktijk zie je dat de meeste activiteiten onder de Must-haves komen, iets minder onder de Should-haves en blijven de Could-haves en de Would-haves bijna leeg. Een handige tool om op prioriteiten te concretiseren is de prioriteiten-matrix.

2. Prioriteiten-matrix

Ambrero prioriteiten matrix. Voor het prioriteren van het backlog
Bron: Agile managen

Bij Ambrero gebruiken we vaak een matrix waarin we de hoeveelheid werk afzetten tegen de impact die de functionaliteit heeft op de waarde van je MVP voor de stakeholder. De quick wins zijn de punten die veel impact hebben en weinig werk vereisen. De puntjes op de i hebben een lage impact maar kosten ook weinig werk. De grote projecten kosten veel werk maar hebben ook veel toegevoegde waarde. De laagste prioriteit geef je aan die functionaliteit die veel werk vereist en niet zoveel toevoegt. Zo kun je op een wat rationelere manier je backlog indelen.

Je kunt ook andere eigenschappen op de assen zetten: kies de waarden die passen bij je productvisie. Is het bijvoorbeeld de ambitie om een innovatief product neer te zetten? Dan kun je de mate van innovatie op een van de assen zetten:

Ambrero prioriteiten matrix. Voor het prioriteren van het backlog

Je kunt ook verschillende matrices inzetten en kijken wat het doet met je prioriteitstelling. Kortom: experimenteer met verschillende variabelen en plaats steeds de user stories op het assenstelsel. Je zult zien dat het je helpt bij het prioriteren van het product backlog.

3. Weighted Shortest Job First

WSJF is eigenlijk een omgekeerde redenering. Je kijkt naar wat het kost als je een bepaalde functionaliteit niet opneemt: de kosten van uitstel. Deze wordt vertaald naar de relatieve prioriteit via de volgende formule:

prioriteit = kosten van uitstel ÷ doorlooptijd

De kosten van uitstel kunnen zitten in wat de uitstel van functionaliteit doet met de waardeontwikkeling van je product: veel behoefte betekent veel waarde. Het kan ook zitten in wat het doet met de interesse van je gebruiker. Misschien zorgt het er wel voor dat je minder betalende klanten krijgt of dat je het interne team niet meekrijgt. Verder weeg je ook de impact op risico’s en kansen mee. Omdat het moeilijk is om exacte bedragen aan deze kosten van uitstel te hangen, druk je die kosten uit in een relatief cijfer, bijvoorbeeld uit de rij van Fibonacci. Zo krijg je meer nuance. Deel de kosten van uitstel door de doorlooptijd, en je hebt de relatieve prioriteitstelling. Je bepaalt als het ware welk punt in het backlog de meeste toegevoegde waarde levert per tijdseenheid.

‘Scope creep’ vermijden door de juiste prioriteiten

Gedurende het verloop van een project treedt nogal eens ‘scope creep’ op. Als je niet oppast komen de aspecten ‘functionaliteit’ en ‘kwaliteit’ aan het einde van je tijd en geld steeds zwaarder onder druk te staan. Bovengenoemde hulpmiddelen helpen om prioriteiten op een objectieve manier vast te stellen. Welke tool geschikt is, kan per fase verschillen. Maak dus steeds opnieuw een juiste afweging.

Nieuwsgierig?

Wil je advies bij het prioriteren van je product backlog? Neem vrijblijvend contact met ons op.

Jelle van den Berg

Prioriteiten stellen in maatwerk softwareprojecten; 4 valkuilen

Het stellen van de juiste prioriteiten is essentieel voor het succes van je product. In dit blog gaan we in op technieken om op een rationele manier prioriteiten te stellen bij softwareprojecten. Maar eerst een introductie over de valkuilen die in de praktijk op de loer liggen.

Je idee voor het verbeteren van een bepaald bedrijfsproces met maatwerksoftware (zoals beschreven in ons vorige blog) is opgepakt. Als product owner weet je precies wat je wilt bereiken; je ziet de applicatie als het ware al voor je en gaat met een scrumteam aan de slag.

Allereerst stel je vast hoe je Minimum Viable Product (MVP) eruit gaat zien. Je wilt natuurlijk met een eerste versie van het product komen die genoeg toegevoegde waarde biedt. Maar hoe zorg je ervoor dat je ook daadwerkelijk het maximale uit het MVP haalt? En is de toegevoegde waarde voor al je stakeholders gelijk?

Prioriteiten stellen in softwareprojecten

Als opdrachtgever neem je in een agile project de rol van product owner in. Je vertegenwoordigt de verschillende stakeholders. De weg naar het Minimum Viable Product is er een van cyclisch repeterende sprints. Bij elke sprint bepaal je de prioriteiten van de user stories op het backlog.

Ondertussen krijgen de stakeholders de eerste demo’s te zien en krijg je ongetwijfeld een hoop input, die niet altijd met elkaar in lijn is. Hoefde je eerst alleen je eigen prioriteiten te ordenen, nu heb je te maken met allerlei verschillende belangen. Bovendien zorgt voortschrijdend inzicht ook voor nieuwe input op:

  • functionaliteit
  • rendabiliteit
  • stabiliteit

Om toch tot een goed MVP te komen, is het belangrijk de prioriteiten steeds goed vast te stellen en te bewaken.

Valkuilen bij prioritering

Ambrero prioriteren binnen Agile projecten - Valkuil: geen uitdaging meer

Als Product Owner ben je een belangrijke schakel in het Scrum proces. Wanneer er enige frictie ontstaat, bijvoorbeeld bij tegenstrijdige belangen of wanneer het budget of de planning onder druk staan, wordt het lastiger om de juiste prioriteiten te stellen. De afgelopen jaren hebben we situaties gezien waarin het lastig was om een scherpe blik te houden. We onderscheiden de volgende 4 valkuilen:

1. Je probeert iedereen te vriend te houden
Als je aan ieders belangen tegemoet wilt komen dan resulteert dat vaak in een algemeen product waarvan de essentie onduidelijk is. Daarom is het goed vooraf je productvisie te formuleren, waarin je de behoefte van je doelgroep aan de doelen van je product koppelt. Deze productvisie is een belangrijk instrument om de juiste afweging te maken. Durf stelling te nemen: als Product Owner moet je kiezen welke belangen de meeste waarde toevoegen. Het is dus ook belangrijk dat je dat mandaat hebt.

2. Je denkt teveel vanuit de functionaliteit
Je kent het werkproces vanuit de organisatie en wilt alles met de applicatie ondersteunen. Daardoor heb je wellicht minder oog voor ‘randzaken’ die de functionaliteit ondersteunen. Hoe gaat de gebruiker zijn weg vinden in de nieuwe applicatie, wat zijn de supportmogelijkheden? Ik noem het randzaken, maar dit zijn wel zaken die meewegen bij het uiteindelijke succes van het product. Je kunt beter de randzaken direct meenemen gedurende de ontwikkeling van functionaliteit dan dat je deze achteraf gaat toevoegen.

3. Je wilt dat alles perfect werkt
Hier gaat de bekende 80/20-regel op: de laatste 20% kost 80% van je tijd. Als je werkt volgens de MVP-strategie is dat niet wat je wilt: de truc is om je te blijven focussen op datgene wat de meeste business value oplevert.

4. Je bent overtuigd van je eigen gelijk
Natuurlijk weet je goed hoe de markt in elkaar steekt of wat er speelt op de werkvloer. Maar jouw perspectief is niet dat van de gebruiker. Als je in je eentje de prioriteiten stelt voor nieuwe software, heb je grote kans dat je ingehaald wordt door de eerste feedback van de gebruikers. Het devies luidt dus: release early, release often. Oftewel: behoud een open blik door in vroegtijdig stadium gebruikers te betrekken. Dit kun je doen door te zorgen voor een prototype en daarmee te experimenteren. Wat je daarvan leert, heeft invloed op je prioriteiten.

Tot slot

Een softwareproject heeft de grootste kans van slagen wanneer de Product Owner alle belangen weet te vertalen naar heldere prioriteiten. Dat die prioriteiten binnen het scrum traject veranderen is prima: je wilt immers gebruikmaken van voortschrijdend inzicht. Maar laat de momentopname niet doorslaggevend zijn. Daarom is het essentieel dat je regelmatig reflecteert op je prioriteiten. In wiens belang zijn de prioriteiten gesteld? Zijn de prioriteiten wel in lijn met de productvisie? En ligt de focus nog wel genoeg op de creatie van gebruikerswaarde? Neem een stapje terug en kijk of je niet toevallig in een van de genoemde valkuilen bent gestapt!

In een volgende blog gaan we dieper in op de productvisie en bespreken we drie methodes om het backlog te prioriteren. Mocht je advies willen bij het prioriteiten stellen in jouw softwareproject? Wij begeleiden je graag naar de maximale toegevoegde waarde van de nieuwe software.

Jelle van den Berg

Agile HR; meer ruimte voor ontwikkeling, zonder rompslomp

Met de groei van ons bedrijf ontstond er ook de wens om Human Resources te professionaliseren en updaten. De aanleiding? Het ontbreken van constante aandacht voor dit vakgebied hier. Nog een belangrijk punt; van de beoordelingssystematiek werd niemand hier meer vrolijk. Dus nadat er was geroepen “dit is de laatste keer dat we deze formulieren gebruiken” kwam ook automatisch de start voor verandering. Graag neem ik je mee in onze zoektocht.

In onze zoektocht naar een nieuwe manier van evalueren kwam ik al snel uit bij de term ‘Agile HR’. In eerste instantie dacht ik aan goede marketing, door Human Resource te koppelen aan Agile. De letterlijke vertaling van Agile is: behendig, rap, lenig en vlug. Niet bepaald termen die in mij opkomen als ik denk aan HR of Personeel en Organisatie. Maar mijn nieuwsgierigheid was gewekt, dus ik ging op zoek naar de betekenis.

Wat is Agile HR eigenlijk?

Binnen de software ontwikkeling bestaat Agile werken al meer dan 15 jaar. Binnen Ambrero werken we ook Agile aan onze projecten dus dat is bekend terrein. Maar wat betekent dit in het vakgebied van HR? Al snel kwam ik uit bij Agile HR Manifesto en diverse artikelen over de toepassing hiervan binnen dit vakgebied. Tegenwoordig staat vakmanschap (weer) centraal en wordt de medewerker gezien als een uniek mens. Die intrinsiek gemotiveerd is en zich graag ontwikkelt. Een medewerker die betrokken is bij een gezamenlijk bedrijfsdoel, mits deze zinnig is. HR kan hierin ondersteunen door de mens centraal te stellen en een werkomgeving te creëren waar ze de ruimte krijgen om hun vak uit te oefenen. Hé, dat klinkt bekend!

Deze methode sluit aan bij onze bedrijfscultuur, manier van werken en visie op software ontwikkeling. Waarom?

  • Team van professionals (vakmanschap)
  • Platte organisatiestructuur en zelfsturende teams
  • Ontwikkeling van ons team én bedrijf is een speerpunt
  • Agile werkwijze bij onze softwareprojecten
  • We zijn ambitieus en lopen graag voorop

Ambero Blog - Meer ruimte voor ontwikkeling zonder rompslomp met Agile HR

Onze eerste stappen in het nieuwe HR landschap

Allereerst heb ik de huidige situatie binnen ons bedrijf op het gebied van HR beschreven. En daarnaast de situatie waar we naar toe willen en de prioriteiten hierin, namelijk:

  • Evaluatie van prestaties en persoonlijke groei
  • Bouwen aan een focus op continue leren en een leercultuur op alle niveaus
  • Leren en aanmoedigen dat medewerkers elkaar directe feedback geven

Maar wat is dan de volgende stap? Het inschakelen van advies en begeleiding door een Agile HR professional! En die vonden we in de persoon van Esther Visser, HR vernieuwer van het eerste uur en tevens een heel leuk en open mens! Zij zorgde vanaf het eerste contact voor een heldere visie op Agile HR en voor inspiratie. Dit deed ze aan de hand van concrete voorbeelden van organisaties die ons voor gingen. Zoals een bedrijf dat ervoor koos om de verdeling van de jaarlijkse bonus over te laten aan de mensen in het team. Met als uitgangspunt dat zij gezamenlijk het beste konden bepalen wie er een extra beloning verdiende en waarom. Dat is nog eens een andere kijk op zaken!

“Geef mensen regelruimte en vertrouwen om hun talenten te ontwikkelen en je zult versteld staan van hoeveel tevreden en betrokken klanten dit oplevert!” – Esther Visser

De start van ons Agile HR traject

Het centraal stellen van de mens, betekent ook het betrekken van alle collega’s in dit traject. Om draagvlak te creëren en om te horen wat zij belangrijk vinden op het gebied van HR wat bijdraagt aan de invulling van de visie op werken bij Ambrero.

“Ambrero is een organisatie waar je prettig werkt en waarin ontwikkeling van en met elkaar centraal staat. We stimuleren persoonlijke groei en vakmanschap en geven elkaar feedback – zonder rompslomp. We hebben daarbij aandacht voor elkaars kracht en verschillen. Kortom: gelukkig team & gelukkige klanten.”

Hoe gaan we hier samen mee aan de slag? Door kleine stapjes te nemen waarbij we de ruimte houden voor nieuwe inzichten, door te experimenteren en te leren. Zonder hele plannen uit te werken en processen te beschrijven. Kortom, we hanteren een Agile aanpak. Duh!!

Inmiddels hebben we een kick-off, onder leiding van Esther, met het hele team achter de rug. Hierin hebben we allemaal aangegeven wat voor ons bijdraagt aan een gelukkig team. Ook hebben we gezamenlijk de input geprioriteerd en er is een scrumteam samengesteld. Een vijftal enthousiaste collega’s, waaronder ik zelf, die momenteel de user-stories uitwerken; ‘wat willen de medewerkers van Ambrero, evenals wat wil de directie, en waarom.’

Kortom; we zijn van start gegaan met onze invulling van Agile HR! Ik hou jullie op de hoogte van onze vorderingen.

Elisa Kossen

Scrum: de rol van de Scrum Master

Eerder schreef ik een korte introductie over de verschillende rollen en artifacts binnen een Scrum proces. In dit artikel ga ik verder in op de planning en uitvoering van een Scrum proces.

Ook ga ik verder in op de rol van de Scrum Master. Veel mensen denken dat dit een nieuw synomiem voor Project Manager is, maar niets is minder waar.

Wat doet een Scrum Master?

Zoals ik in het vorige artikel al schreef heeft de Scrum Master geen authoriteit binnen het Team. Een Scrum Master kan dus niet als projectmanager optreden, aangezien het team zelf bepaald welke features er in een iteratie worden opgepakt (zodirect meer hierover). Een Scrum Master treedt meer op als ‘Facilitator’; hij zorgt er voor dat het team niets in de weg staat om goed werk te kunnen verrichten. Ook begeleidt hij het team, Product owner en stakeholders tijdens de verschillende meetings en zorgt hij ervoor dat Scrum correct wordt geïmplementeerd.

Hoe plan je een Sprint?

Eerst nog even een reminder over het Scrum proces:

Ambrero Blog - Scrum de rol van Scrum Master - Sprintplanning

Voordat een Sprint gestart kan worden komen het team, de Scrum Master en de Product owner samen voor een Sprint planning meeting. Tijdens deze meeting geeft de Product owner zijn visie over het project en product en geeft hij toelichting op de features op het Product backlog. Het team classificeert de features op het backlog op basis van de benodigde hoeveelheid werk.

Als dit gedaan is kan de Product Owner samen met het team bepalen welke features binnen de komende sprint opgepakt kunnen worden. Het team committeert zich hieraan. Hierin verschilt Scrum van tradionele vormen; de tijd staat vast, de features niet.

Nadat er is bepaald welke features worden opgepakt, verlaat de Product Owner de meeting en gaat het Team de verschillende features opsplitsen in taken.

Tijdens een sprint

Nadat het plannen is voltooid begint de Sprint. Elke dag wordt er een Daily Scrum meeting gehouden, waarin de teamleden elkaar op de hoogte houden over de voortgang. Elk teamlid stelt zichzelf 3 vragen:

  • Wat heb ik gisteren gedaan?
  • Wat ga ik vandaag doen?
  • Wat staat mij in de weg?

Het is de verantwoordelijkheid van de Scrum Master om eventuele facilitaire problemen die naar voren komen op te lossen.

Na een sprint

Nadat de sprint is voltooid geeft het Team een demo aan de Product Owner en eventuele stakeholders. De product owner bepaalt welke features daadwerkelijk zijn opgeleverd en plaatst eventueel items terug op het backlog.

Ambrero Blog - Scrum de rol van Scrum Master - Cartoon Ook houden het Team en de Scrum Master een retrospective meeting, waarin ze bekijken hoe de Sprint is verlopen en welke verbeteringen er doorgevoerd zouden kunnen worden.

Hierna kan het process zich weer herhalen, totdat er in de ogen van de Product owner een product release gedaan kan worden. Vaak volgt er dan nog een ‘polish’ sprint, waarin de puntjes op de i worden gezet.

Wat is de rol van de Scrum Master; conclusie

Het is de rol van de Scrum Master om het team te beschermen tegen externe invloeden en om te zorgen dat iedereen zich aan de regels houdt. Het team wordt door de Scrum Master afgeschermd van de Product owner en andere stakeholders, waardoor het zich volledig kan richten op de software ontwikkeling.

Hierdoor is het risico op ‘Scope Creep’ een stuk kleiner, waardoor het team eerder geneigd is om gestelde deadlines te halen.

Meer informatie nodig?

Onze gecertificeerde Scrum Masters hebben brede ervaring in het introduceren van Scrum binnen ontwikkelteams. Met hun een technische achtergrond kunnen ze effectief en to-the-point communiceren met de ontwikkelaars binnen uw organisatie. Lees meer over onze Agile werkwijze of neem geheel vrijblijvend contact met ons op.

Bart Matthaei