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:

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.

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.

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. 

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 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.

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.