Webprojecten via Agile en Scrum

Agile is een projectaanpak die principieel anders werkt dan waterfall projecten. Bij waterfall probeert men reeds voor aanvang van een project alle aspecten van dat project vast te leggen. Dit werkt vaak contraprodutief bij het verloop van een project, omdat voortschrijdend inzicht een belangrijke factor is in een web project.

De 3 factoren van een project: scope, budget en tijd zijn in realiteit altijd onderhevig aan onvoorziene factoren, en kunnen eigenlijk veel efficiënter aangepakt worden. Daarom is er Agile.

Agile werd in 2001 zeer concreet gemaakt, door het vooropstellen van deze principes:

Agile projectaanpak door web agency Calibrate
  • Klanttevredenheid door snelle levering van bruikbare software op continue basis
  • Regelmatig aanbod van nieuwe werkende software (eerder per week dan per maand)
  • Wijziging van doelstellingen zijn welkom, zelfs laat in het proces
  • Nauwe samenwerking op dagelijkse basis tussen ontwikkelaars en hun belanghebbenden
  • Direct persoonlijk contact
  • Eenvoud
  • Zelf-organiserende teams
  • Voortdurende aanpassing aan veranderende omstandigheden

Hoe werkt agile?

We passen Agile toe door middel van Scrum technieken. Dit is ook de aanpak die wij als web agency doorgaans hanteren.

Binnen elke sprint zijn er verschillende stappen, die we hierna kort beschrijven. Deze stappen worden iteratief afgewerkt, waardoor Agile heel snel een concreet resultaat bereikt.

Scrum Cycle

Voorbereidend : opstellen van een backlog

Voorafgaand aan de sprints wordt werk gemaakt van een backlog. Deze bevat een aantal high level functionaliteiten. Deze zogenaamde “Epic stories” gaan niet in detail, maar geven een concrete use case weer. Deze user stories worden in een latere fase verfijnd en in detail vastgelegd.
Er worden dus User stories aangemaakt die duidelijk een stukje van de scope vastleggen. Deze vormen samen de project backlog.

Deze User Stories lees je in de volgende vorm :

"Als [rol] kan ik [functionaliteit uitvoeren] zodat [doel van de functionaliteit]"

Een praktisch voorbeeld kan zijn :

"Als bezoeker kan ik mijn taal wijzigen in een menu zodat ik de website kan bezoeken in mijn eigen taal."

Het kan misschien voor de hand liggend lijken, en een beetje triviaal, maar een user story is eigenlijk een zeer handige manier van werken. Samen met de designs en de wireframes vormt dit een sluitende omschrijving van de beoogde functionaliteit. Bovendien heeft het team de kans gekregen om de functionaliteit te bepalen samen met de klant, zodat iedereen steeds goed weet wat te verwachten bij een oplevering. De nodige aantekeningen worden steeds gemaakt in ons communicatie platform, waarin de backlog wordt aangemaakt. Dit zorgt voor een uitgebreide audit trail. Alle leden van het project kunnen dus ten allen tijde goed bekijken wat de status is, en welke beslissingen er gemaakt zijn in het project.

Deze stories, samen met de definition of done, zorgen er voor dat het team zeer goed weet hoe een story uit te voeren, en welke controles moeten uitgevoerd worden tijdens de ontwikkeling.

Stap 1 : backlog refinement

Tijdens deze sessie bespreken we opnieuw samen met de Product Owner en eventuele andere stakeholders de functionaliteit die we gaan bouwen. Deze zijn reeds high level beschreven in Epic user stories in een Product Backlog. Deze user stories bevatten vanuit business perspectief de omschrijven van de te verwezenlijken functionaliteit.
Tijdens deze sessies gaan we elke Epic story opdelen in aparte, in te schatten user stories. Hier bespreken we van elke story hoe deze moet uitgewerkt worden, met het volledige team.

Stap 2 : Sprint planning

Vanuit de backlog wordt samen met de Product Owner bepaald welke zaken het meest prioriteit moeten krijgen, en deze stories worden ingeschat in punten. Deze stories worden in een sprint planning overzicht gezet, tot wanneer het team denkt dat er geen punten meer in de volledige sprint kunnen.

Stap 3 : Sprint ontwikkeling

Het team gaat aan de slag en verwezenlijkt de eerste sprint, en komt met een eindresultaat dat een zo concreet mogelijk stuk werkend software is.

Stap 4 : Sprint demo

Het resultaat van de sprint wordt aan het volledige team voorgesteld, en wordt beoordeeld. Er wordt kort besproken wat er goed en slecht ging. 

Waarom is Agile beter?

De bovenstaande punten zijn duidelijk een verbetering tegenover een traject waarbij analyse, User Interface Design, ontwikkeling en testing allemaal verschillende, opeenvolgende trajecten zijn, die nauwelijks met elkaar in aanraking komen.

Agile projectaanpak

Bij Agile wordt er veel sneller concrete business value gecreëerd voor de klant. Een tastbaar, tussentijds product wordt bij elke sprint opgeleverd, terwijl dat bij waterfall slechts op het einde van het project is.  Het Pareto principe illustreert waarom dat een groot voordeel is.

Door deze tussentijdse opleveringen is ook voortdurend ruimte en plaats voor evaluatie door de klant, en kan er snel bijgestuurd worden waar dat nodig zou zijn. Het team leert als het ware samen tijdens het project, en de waarde van deze inzichten kan meteen omgezet worden in de volgende iteratie van een sprint. Agile levert sneller resultaten, en een goed lopend agile traject is ook sneller en budget effectiever dan een waterfall project. 

Inperken van project risico’s

Inperken van project risico’s

Het risico voor een klant is veel kleiner. Agile waarborgt dat er regelmatig concrete functionaliteit wordt opgeleverd.  Ervaring wijst ook uit dat 80% van de business requirements doorgaans reeds uitgewerkt wordt met 20 à 30 % van totale inspanning van het volledige project. Door iteratief te werken verkleint dus het risico op een onafgewerkt product, en vergroot ook de visibiliteit voor de klant. Bij elke tussenoplevering wordt een concreet geheel opgeleverd.

Budget, tijd en Scope in Agile

Omdat er geen fixed price afspraak is tussen 2 partijen, draait Agile in de eerste plaats om vertrouwen. De filosofie is : we willen weg van de kloof tussen leverancier en klant. Wij willen een partnership opstarten, waarbij we samen de voordelen van een Agile project kunnen gebruiken, en, als er onvoorziene zaken zijn in een project, we samen delen in de effecten daarvan.

Lagere kostprijs
In fixed price afspraken is het voor een bedrijf nodig om marges in tarieven en budgetten te verwerken, om het risico van een fixed price project in te dekken. Agile werkt aan de hand van een Time & Materials principe, waarbij maandelijks alleen de effectief gepresteerde uren worden gefactureerd. Daardoor valt dit risico weg, en zijn de dagtarieven voor alle medewerkers in een Agile project dus lager, wat resulteert in een lagere kostprijs voor de klant.

Minium Viable Scope

Omdat Agile een vertrouwensband vereist, is er vaak aarzeling bij veel bedrijven om hierin te stappen. Dat is begrijpelijk, omdat fixed price afspraken vaak even belangrijk zijn dan concreet resultaat voor bij de beheerders van budgetten. 
Om een garantie te kunnen geven op resultaat binnen een bepaald budget, wordt vaak gewerkt met een Minium Viable Scope (MVP)
Dit is een beperkte set van user stories die absoluut noodzakelijk zijn om de business waarde van de klant te realiseren. Deze worden gescheiden van de user stories die buiten deze omschrijving vallen, en worden apart ingeschat.
Het resultaat is een (nauwe) budgetvork, die aangeeft dat, om de minimaal benodigde scope te realiseren, er een bedrag nodig is dat ergens tussen het minimale en maximale getal van de budget vork zweeft.
De rest van de user stories wordt op een gelijkaardige manier ingeschat om een ruwe indicatie te geven van het benodigde budget, en de tijd die nodig is in de planning. 

Uitdoving van dagtarieven

Om de vertrouwensband tussen klant en leverancier verder aan te sterken, wordt vaak gewerkt met een mechanisme van uitdovend tarief. 

De Product Owner

De product owner is een sleutelfiguur, en heel belangrijk in een Agile project.

Aan de kant van de klant wordt een persoon aangeduid die met uitgebreide kennis van de business aspecten aan de slag gaat met het team. Door middel van de project meetings is deze persoon in staat om prioriteiten te bepalen binnen het project en het team bij te sturen met business inzichten waar nodig.
Het gevolg van Agile is dat de tijd en energie die van een klant gevraagd wordt, niet voornamelijk in het begin (analyse) en het einde (testing) zit, zoals bij waterfall projecten. Bij Agile is deze energie veel meer verspreid overheen het volledige traject, en wordt de product owner dus minder onder druk gezet bij de aanvang en einde van het project.

Het is wel zeer belangrijk dat deze product owner het mandaat krijgt van de instelling waarvoor hij actief is. Dat mandaat moet hem toelaten om beslissingen te nemen, en het project mee te sturen. Anderzijds moet deze product owner ook meestappen in het gedachtengoed dat hij zelf deel uit maakt van het team, en daar niet buiten staat. Samenwerking en transparante communicatie is zeer belangrijk in een Agile project.

Voorwaarden voor succes met Agile

Werken via een Agile proces heeft veel voordelen, maar om dit te laten slagen, zijn er enkele voorwaarden

  • Een Agile team werkt samen, en is samen verantwoordelijk voor het opleveren van een sprint.
  • Tijdens de sprint moet de Product Owner van de klant ter beschikking staan om feedback te geven over de business aspecten, en om samen met het team te bepalen wat de prioriteiten zijn.
  • Deze personen werken steeds binnen een Agile team.
  • Aan het eind van elke iteratie zal de klant, aan de hand van acceptatietesten, bekijken of de nodige business value gerealiseerd is.

 

Meer weten over onze Agile projectaanpak?

Laat hier je contactgegevens achter en wij contacteren jou zo spoedig mogelijk. Of stuur je vraag via hello@calibrate.be.