• 26 oktober 2015
  • #Kennis
  • #Nieuws

Help!
Mijn webbureau wil scrummen

Soms, als we als internetbureau beginnen te praten in termen als Planning Poker, Burndown Charts en Story Points, denken onze klanten dat we gek zijn geworden. Grote kans dat ze dan voor het eerst horen van de Agile Scrum manier van werken, één van de meest populaire software ontwikkelmethoden van de afgelopen jaren. Bij ROQUIN wordt dan ook met veel enthousiasme gescrumd, voor UX, design, content én development.

Maar wat is scrummen eigenlijk? Hoe ga je hier als opdrachtgever mee om? Doe je echt soms 2x zoveel in de helft van de tijd? En natuurlijk: werkt het?

Vergelijking met rugby

Scrum dankt haar naam aan een term uit de rugbysport, een sport die nu volop in de belangstelling staat wegens het WK Rugby 2015 in Engeland. De vergelijking is ooit gelegd door de manier waarop een rugbyteam als groep de achterlijn van de tegenstander probeert te bereiken. Hierbij is samenwerking, aanpassingsvermogen, snelheid en zelfsturing van cruciaal belang en dat zijn nu precies de elementen die overeen komen met die van multidisciplinaire teams die websites of software ontwikkelen.

Multidisciplinaire teams?

Multidisciplinair omdat er in een team kennis en ervaring op verschillende gebieden aanwezig is. Denk aan front & back end developers, interaction designers, grafisch ontwerpers, marketeers, de opdrachtgever, communicatiemedewerkers, webredacteuren die met het CMS gaan werken, mensen die met de eindgebruikers werken etc..

Scrum is ouder dan je misschien denkt

Scrum (onderdeel van de Agile-software-ontwikkeling) is al jaren een stijgende trend en heeft zich inmiddels al bij vele organisaties bewezen. Officieel bestaat het sinds 1995 en dat is in internet-jaren een eeuwigheid. Het komt voort uit een Amerikaans onderzoek waaruit bleek dat projecten met kleine (multidisciplinaire) teams historisch gezien het beste resultaat leveren.

Al vanaf 2001 is de methode op grote schaal omarmd door vooraanstaande multinationals, zoals Google, Amazon, Microsoft en Nokia. Scrum is er dus al een hele tijd en zal voorlopig ook nog wel blijven.

Waarom veranderen? Watervallen is toch ook prima?

Stel jezelf de volgende vragen eens: Hoe goed gaat het watervallen van online projecten nou echt? Krijg je aan het einde altijd geleverd waar je – als opdrachtgever én (eind)gebruiker – ook écht op zit te wachten? Is het tegenwoordig überhaupt (nog) mogelijk om vooraf alle gewenste functionaliteit gedetailleerd op papier te zetten? Heb je tijdens de realisatiefase (al gauw enkele maanden) enig idee hoe het gaat met de ontwikkeling van de site/app? Bevalt het om na oplevering in één keer de complete applicatie te moeten testen? Wat vind je van het proces van ‘change requests’?

Oké, maar wat biedt Scrum mij dan?

Het basisprincipe van Scrum (in het Engels) is: Manage Complexity, Unpredictability and Change through Visibility, Inspection and Adaption. In de praktijk (en in het Nederlands) betekent dit dat er vanuit het Scrum manifest gekozen wordt voor…

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

En hoewel Scrum waardering heeft voor al hetgeen aan de rechterkant staat vermeld (veelal onderdelen van de watervalmethode), hecht Scrum méér waarde aan wat aan de linkerzijde wordt genoemd.

En wat is het resultaat?

Dit is wat Scrum minimaal nastreeft:

  • Zoveel mogelijk waarde creëren
  • Face-to-face communicatie
  • Transparantie en kwaliteit
  • Een constant tempo vasthouden
  • Omarm verandering
  • Hou het simpel
  • Regelmatige reflectie/evaluatie
  • Evoluerende designs
  • Regelmatige oplevering van werkende software
  • Teamwork en gemotiveerde mensen

Klinkt goed, toch? Daar zegt niemand nee tegen! Toch bemerken we bij onze (nieuwe) klanten nog steeds vaak wat voorzichtigheid of terughoudendheid ten opzichte van Scrum. Dat is ook niet gek als je je bedenkt dat het een behoorlijke verandering is, vooral als men aan de watervalmethode is gewend.

Wat verandert er dan voor mij als opdrachtgever?

Bij start (sprint 0) nog weinig

Bij het voortraject – de zogenaamde sprint 0 – veranderd er nauwelijks iets. We onderzoeken nog steeds uw vraag aan ons waarin het fundament voor het project grotendeels wordt vastgelegd. Als resultaat ontvangt u gewoon een duidelijk, no-nonsense samenwerkingsvoorstel, inclusief:

  • een globale omschrijving van wat we gaan maken (user stories);
  • wat we verwachten dat het gaat kosten (budget);
  • wanneer we het ongeveer af kunnen hebben (planning).

Opmerking: Ter waarborging van het proces en het uiteindelijke resultaat werkt Scrum liever niet met fixed-price, -scope en/of -date projecten. Echter, we snappen dat projecten intern uiteindelijk ook ‘verkocht’ dienen te worden en denken hierin mee waar nodig.

Bij aanvang realisatie (sprint 1) verandert alles

Na akkoord, start met sprint 1 de ontwikkeling. Hoeveel sprints er nodig zijn hangt af van de grootte van het project. Standaard hanteren we bij ROQUIN sprints van 2 weken en in elke sprint wordt hetzelfde proces herhaald:

  1. Voorbereiding: We plannen samen welke User Stories er ontwikkeld gaan worden;
  2. Het scrumteam gaat aan het werk en komt dagelijks 15 minuten bij elkaar in de Daily Scrum om de voortgang te bespreken;
  3. Het scrumteam pakt kleine brokken werk op die onafhankelijk ontwikkeld, getest en uitgeleverd kunnen worden;
  4. Belangrijk voor u als opdrachtgever: Aan het einde van iedere sprint houden we de Sprint Review Meeting en presenteert het scrumteam de tussentijdse resultaten. Geen fancy slides maar gewoon, echt werkende functionaliteiten. U geeft feedback en het team kan weer verder;
  5. Het scrum team evalueert de afgelopen sprint – de Retrospective – en bedenkt procesverbeteringen die moeten zorgen voor een hogere productiviteit en kwaliteit;
  6. De volgende sprint begint dan weer bij stap 1.

Onderstaande afbeelding is een handige schematische weergave van dit scrumproces:

Proces Scrum

FIGUUR: Visuele weergave van het scrumproces

Veel gestelde scrum vragen

Wat staat er precies in user stories?

Een goede user story bevat minimaal de volgende informatie:

Story

Als een <type gebruiker>
wil ik <iets doen>
zodat ik <er iets aan heb>
Bijvoorbeeld: Als een potentiële klant wil ik me kunnen inschrijven voor de nieuwsbrief zodat ik op de hoogte blijf van het laatste nieuws

Verkorte naam

Bijvoorbeeld: Inschrijfformulier nieuwsbrief

Acceptatie Criteria

Dit zijn de eisen waaraan, na afloop van ontwikkeling, het resultaat getoetst wordt.

Test Scenario’s

Het testscript wat bij afronding van het werk door de ontwikkelaar doorlopen wordt. Deze moeten allemaal slagen voordat het resultaat aan de product owner en opdrachtgever getoond kan worden.

User Story Points

Relatieve inschatting van de hoeveelheid werk in punten, ingeschat door het scrum team. De puntentelling verloopt volgens de zogenaamde Fibonacci reeks: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100.

Achtergrond informatie

Bijvoorbeeld interactie ontwerpen, designs, etc.

Prioriteit

Elke User Story krijgt een bepaalde prioriteit toegekend, waardoor het scrum team altijd weet welke User Stories als volgende moeten oppakken.

U ziet het: een user story bevat behoorlijk veel informatie maar is meestal minder diepgaand dan wanneer je een nieuwe functionaliteit in een functioneel ontwerp zou beschrijven. Daar zit dan ook net de crux; om genoeg vrijheid te behouden voor het scrum team om er iets moois van te maken.

Scrum gaat namelijk uit van hun expertise en professionaliteit om op basis van een user story iets nieuws te bouwen. Maar het gaat ook uit van de feedbackloop met de opdrachtgever waardoor het resultaat later geoptimaliseerd kan worden en écht aansluit bij zijn/haar behoefte.

User stories worden meestal door ons geschreven maar we kunnen het ook samen doen, graag zelfs! Als voor een nieuw project de user stories compleet zijn en de opdrachtgever heeft ze goedgekeurd, dan kunnen ze ingeschat worden door het scrum team. Dat doen ze met behulp van story points.

Story points? Hoe weet ik dan wat mijn project gaat kosten?

Nieuwe user stories worden met behulp van story points ingeschat en daarbij wordt de Fibonacci reeks gebruikt: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40 en 100 punten. Zodra een story op meer dan 8 punten geschat wordt, dan is het doorgaans te groot en moet de story opgeknipt worden in kleinere brokken.

Scrumkaarten

AFBEELDING: Planning Poker kaarten voor het inschatten van nieuwe user stories door het gehele scrum team

Het inschatten van nieuwe user stories gebeurt wekelijks in de Sprint Planning Meeting. Het hele scrum team doet mee waarbij de gezamenlijke kennis & ervaring wordt ingezet om tot een reële en gedragen inschatting te komen. Als ijkpunt zijn er twee a drie ‘generieke’ user stories van bijvoorbeeld 1 punt en bij elke nieuwe user story wordt er gekeken hoe die zich daar relatief tot verhoudt. Dit ‘relatief schatten’ is makkelijker en betrouwbaarder dan schatten in uren.

Maar hoe bereken je dan het benodigde budget voor het project? Dat doen we met behulp van deze formule:

Formule beschikbare uren per sprint

Rekenvoorbeeld

Stel we hebben vijf fulltime teamleden die in totaal 400 uur per sprint (twee weken) beschikbaar zijn. Vanuit de voorgaande sprints weten we dat dit team ongeveer 80 story points per sprint kan verwerken. De waarde van 1 story point is dan 400 / 80 = 5 uur per story point.

Tel vervolgens alle user story punten voor het project bij elkaar op en vermenigvuldig dat met de uren per punt. Dat vermenigvuldig je met het uurtarief en VOILA! daar is het geschatte projectbudget in reële Euro’s.

Is met een Scrum offerte wel duidelijk wat ik ga krijgen?

Dat hangt er van af van welke samenwerkingsvorm we kiezen. De volgende binnen Scrum zijn mogelijk:

  • Een inspanningsverplichting in de vorm van een x-aantal afgekochte sprints/uren
  • Een resultaatverplichting in de vorm van een vastgelegde set van user stories

Ter vergelijking, een overzicht

Inspannings verplichting

Voordelen

Dit is écht scrummen. Als opdrachtgever kunt u doorlopend bijsturen om zo tot een optimaal resultaat te komen (voortschrijdend inzicht). U weet zeker dat we geen tijd verliezen aan het uitwerken van user stories die later toch niet nodig blijken te zijn.

Nadelen

Het kan u, gezien het open karakter van onze offerte, wat meer moeite kosten om deze offertevorm goedgekeurd te krijgen door uw inkoopafdeling.

Aandachtspunten

Deze vorm vereist een sterke vertrouwensband tussen opdrachtgever en –nemer (ROQUIN). Er zal gedurende het hele project intensief contact zijn tussen u, de product owner en het scrum team.

Resultaat verplichting

Voordelen

U weet van tevoren waar het scrum team aan gaat werken. De user stories, requirements en acceptatie criteria zijn bekend. U weet dus op een globaal, user story niveau wat u gaat krijgen.

Nadelen

Kost meer tijd om een offerte te maken omdat alle user stories eerst uitgewerkt en ingeschat moeten worden. U dient dus eerst een kleine investering te doen (vooronderzoek, sprint 0) alvorens wij u het totale project kunnen offreren.

Aandachtspunten

Ondanks de resultaatverplichting blijft deze offertevorm een schatting. Bij tegenslag valt/vallen één of meerdere lage prioriteit user stories af. Er is tijdens de realisatie minder contact met u nodig, omdat reeds duidelijk is welke user stories uitgewerkt gaan worden en wat de prioriteiten zijn.

Flexibel aanpassingen doorvoeren met exchange requests?

De traditionele manier van werken (de waterval methode) gebruikt change requests om wijzigingen in de scope door te voeren. Scrum is veel flexibeler en sneller. We spreken dan niet van change requests maar van exchange requests. Komt er vanuit de opdrachtgever en/of het scrumteam een wijziging of iets nieuws als user story in de backlog, dan halen we er in overleg een user story van gelijke grootte uit. Sterker nog, als het budget het toelaat wordt deze wijziging als user story gewoon toegevoegd.

Leuk dat scrummen, maar ik wil toch liever watervallen

Geen probleem! Er kunnen nog steeds allerlei goede redenen zijn om voor de watervalmethode te kiezen. Bijvoorbeeld als uw interne organisatie en stakeholders-groep groot is en alle tussenproducten daardoor goedgekeurd moeten worden. Zeker als dat een langdurig proces is, dan kan je beter gefaseerd gaan werken ipv. iteratief. Wij passen ons proces daar dan op aan.

Kan je met kleine projecten ook scrummen?

Jazeker! Alles kan in principe een sprint in. Kleine projecten van slechts enkele user stories tot zelfs eenvoudige wijzigingsverzoeken of supportaanvragen. Het is een mythe dat je alleen grote projecten kan scrummen. Het is wel zo dat je het liefst projecten hebt die je over meerdere sprints kan verdelen, om zo optimaal baat te hebben bij de voordelen van scrum.

Meer weten?

Ook nieuwsgierig geworden hoe we met scrummen uw online initiatieven kunnen optimaliseren opdat deze echt gaan wérken? Laat ons meedenken en neem contact met ons op.

Let’s connect

We hebben altijd zin in nieuwe en uitdagende projecten. We gaan graag met je in gesprek!