Sprintend naar een nieuwe website

Scrummen, zodra je het noemt, krijgen sommige mensen lichtjes in hun ogen en bij sommige mensen zie je lichte paniek opkomen. Wij vallen in de categorie ‘lichtjes in onze ogen’, maar we snappen dat het niet voor iedereen en niet voor ieder project is. Maar weet wel: tijdens een Scrumtraject vallen alle stukjes op hun plaats voor een prachtig eindresultaat.
De meerwaarde van Scrum in webtrajecten
Hoe kan je weten of Scrum past bij jou en jouw website project? Dat hangt samen met verschillende factoren. In deze blog lees je meer over de methode, waarom wij het bij sommige trajecten toepassen en waarom je soms beter een andere werkmethodiek kan gebruiken.
De essentie is in ieder geval: aan het begin weet je niet altijd wat het eindresultaat is. Maar wat je wel weet, is dat het perfect aansluit op de behoeftes van je doelgroep, dat doet deze blog hopelijk ook.
Wat is Scrum?
Laten we beginnen bij het begin: Ja, het is een rugbyterm. Ooit hebben Jeff Sutherland en Ken Schwaber bedacht dat Agile Scrum een slimme opzet kan zijn voor het ontwikkelen van software. Weer eens een andere werkmethodiek dan de waterval. Net als bij de Scrum in rugby, kom je regelmatig even met de koppen bij elkaar. Daarna ga je zelf aan het werk, totdat je weer met de koppen bij elkaar komt. Tijdens een Scrum traject heeft het team elke dag een standup (de daily om de stand van zaken te bespreken). Zo blijft het team op hetzelfde pad maar wel flexibel → Agile dus. Scrum is voor ons een goede methode om Agile te kunnen werken.
Een belangrijke speler in Scrum is de product owner. Hij of zij neemt eigenaarschap over het product en zorgt ervoor dat de belangen van de eindgebruiker (en andere relevante stakeholders) steeds voorop blijven staan. Meestal is de product owner een afgevaardigde van de klant, maar wij kunnen ook die rol aannemen! Verder leveren wij de scrummaster, dat is degene die het proces bewaakt en zorgt dat alles ook netjes wordt afgerond steeds.
Waarom wij Scrum gebruiken
Wij zetten Scrum in voor onze meer complexere webtrajecten. De bouw van (in ons geval dus) een website wordt opgedeeld in verschillende ‘sprints’. Deze sprints zijn blokken tijd waarin we samenwerken richting het eindproduct. De samenwerking is intensief en vraagt ook om inzet vanuit de klant en vanuit verschillende stakeholders. Het eindproduct is een website die aansluit bij de doelgroep, bij de stakeholders en bij jouw doel als onze klant. Elke sprint bouwt voort op de vorige, maar daarbij wordt ook continu geëvalueerd wat nu onze focus moet hebben. Welke onderdelen kunnen we nu bouwen voor de meeste meerwaarde? Daarom is de bouw van de website een iteratief proces. Zo weten we zeker dat wat we uiteindelijk opleveren goed is en precies aansluit op wat nodig is.
Meestal zijn Scrum trajecten voor ons de trajecten waarbij onze klant binnenkomt met de boodschap; “Ik wil een website waarmee ik mijn doelen bereik, maar ik weet nog niet precies hoe dat eruit moet zien.” Dankzij Scrum kunnen we in zo’n traject flexibel zijn en veranderingen omarmen. De feedback van elke sprint helpt ons om de eisen en doelen te verfijnen. Zo kunnen we snel reageren op nieuwe inzichten en veranderende behoeften, waardoor de website uiteindelijk enkel functionaliteiten heeft die perfect passen bij jouw doelen.
Proces opgedeeld in sprints
Van tevoren spreken we af hoeveel sprints binnen het budget passen en tijdens elk van die sprints ontwikkelen we de functionaliteit die op dat moment het meest relevant is voor het doel en de doelgroep van de website. Hoe ziet zo’n traject er dan verder uit? Dit is hoe wij de verschillende fases invullen:
- Sprint-0: Dit is de eerste sprint. In deze sprint worden wensen, ideeën en mogelijkheden (alle milestones) concreet gemaakt. Deze sprint draait om het inzichtelijk krijgen van de wensen en kansen voor het project. Om dit op tafel te krijgen worden er doorgaans meerdere sessies georganiseerd. Het overzicht van functionaliteiten die in deze sprint-0 geformuleerd, uitgewerkt en geprioriteerd worden vormt het backlog. De backlog vormt het uitgangspunt van alle productiesprints.
- We doorlopen daarna meerdere productiesprints. Dit zijn sprints waarin een (deel)product gerealiseerd wordt. Aan het begin wordt met het team naar de backlog gekeken en bepaald welke functionaliteiten prioriteit hebben en dus binnen deze sprint ontwikkeld worden. Stap voor stap werken we zo naar een eindproduct toe. We hebben regelmatig een gezamenlijke stand-up om de voortgang te bespreken. Het deelproduct hoeft niet noodzakelijk live te gaan, maar moet functioneel wel volledig werken. Aan het eind van elke productiesprint hebben we een retrospective, we reflecteren dan op de sprint, leveren het werk op, en beoordelen samen met de klant ons werk. Zo kunnen we snel inspelen op veranderingen en nieuwe inzichten, want met elke stap die we zetten wordt het pad naar de doelen duidelijker. En de week daarna beginnen we dus weer met een sprint.
- Afsluiting: Als we alle milestones die we hebben besproken/afgesproken hebben bereikt, gaan we geen nieuwe sprints meer doen. Komen er in de toekomst nieuwe vragen, mogelijkheden of opties tot ontwikkeling, starten we gewoon weer een nieuwe sprint
We spreken van tevoren af hoe lang elke sprint duurt, meestal is dat twee tot drie weken. Doorheen het hele proces houdt de product owner de belangen van de eindgebruiker in de gaten. Welke doelen moeten we bereiken om de functionaliteiten te bieden die zij nodig hebben? Passen alle functionaliteiten die we van tevoren hebben besproken wel bij de te bereiken doelen? Het eindproduct hangt samen met het budget dat je wil (kunt) uitgeven aan je website.
Voor de start van elke sprint spreken we af wat we in deze periode gaan maken. Komen we er tijdens de sprint achter dat een geplande functionaliteit toch anders moet? Dan verwijderen of wijzigen we deze in de backlog en zo kiezen we onze prioriteiten voor aankomende sprints. We werken continu vanuit een voortschrijdend inzicht en we spenderen onze tijd aan functies die je wel gaan helpen. Daarbij richten we ons (samen met de product owner) steeds op meerwaarde voor de eindgebruiker. Dat delen we allemaal op in behapbare brokken die gelijk afgemaakt en getest kunnen worden.
Wanneer werkt het niet?
Scrum is geweldig, maar het is echt niet altijd de beste oplossing. Soms heeft een project gewoon een andere aanpak nodig. Bijvoorbeeld als het al heel duidelijk afgebakend is, als je al heel goed weet wat je wilt en hoe je het wilt. Dan is Scrum misschien overkill. Ook als er strakke deadlines zijn waarbij er weinig ruimte is voor iteratie en aanpassingen, kan een meer traditionele aanpak zoals de watervalmethode beter werken. Daarom gebruiken we beide methodes graag.
Lang verhaal kort;
Scrum stelt ons in staat om doelgericht te bouwen en flexibel te blijven tijdens het proces. Door iteratief te werken, kunnen we ons snel aanpassen aan veranderende behoeften en prioriteiten, wat uiteindelijk resulteert in een product dat perfect aansluit bij de doelgroep en de doelen van onze klanten. Dus ja, als je op zoek bent naar een aanpak die je in staat stelt om gericht en effectief te bouwen, dan is Scrum zeker de moeite waard.
Wil je meer weten over hoe webtrajecten bij ons werken? We praten je graag bij! Dan kunnen we je gelijk helpen met de keuze voor of de waterval- of de Scrummethode.
Keep reading

