De twee-traps kick-off voor een Agile project

Leesduur: 8 minuten

Allereerst is het een veelgehoorde misvatting dat Agile projecten (of ze nu scrum zijn, of niet) geen planning hebben. Planning is binnen scrum juist een proces wat continu plaatsvindt gedurende elke sprint. We zijn recent (volledig online :)) begonnen aan zo'n project waarbij planning nu echt nog heel lastig is, maar toch zijn we eraan begonnen en ik durf best te stellen dat we goed van start zijn en er best al zekerheid ontstaat over onze planning.

Omdat we nog lang niet alle uitkomsten weten en ook moeten voorkomen dat we het project al van A-Z uitdenken en daarmee belangrijke flexibiliteit verliezen, is het wel belangrijk dat we dus nadenken over planning de juiste aanpak hanteren. In deze post proberen we uit te leggen hoe we de start van een dergelijk complex project aanvliegen.

^{Al wat termen gezien waarbij je het afvroeg waar het over hadden? Lees dan eerst even de begrippenlijst.}

Waar beginnen we?

Bij het starten van zo'n nieuw (Agile) project is het ook belangrijk dat er goede voorbereiding en ondersteunende documentatie aanwezig is. Deze informatie haal je middels een uitgebreide voorbereiding en door jezelf als team te bedwingen om direct in de eerste sprint aan het development en visueel design te beginnen.

We startten vorige week met een heel aantal deelnemers en specialisten (Magento development, GraphQL, VUE front-end en uiteraard design/UX) waarbij in de beginfase de focus vooral ligt op ontwikkeling van flows en wireframes waarbij betrokkenen vanuit de business (zowel product owner als klant) intensief meedenken.

Zoals gezegd: voordat we van start gaan is het dus informatie vergaren, helder krijgen en zo zicht ontwikkelen op planning. Informatie is key!

Informatie vergaren, cases helder krijgen

Om een succesvolle start van het Agile-project te garanderen, is een goed voorbereide kick-off meeting een must. In de praktijk werken wij met een soort van twee-traps kick-off; het eerste deel is erg gericht op wát we gaan doen en vindt plaats middels enkele workshops met de klant. Het tweede deel is bij de daadwerkelijke start van het project, de eerste sprint (meestal 2 weken), en focust meer op het uitdiepen van de wensen en hóe we het doen.

Het eerste deel van de kick-off noemen we sprint 0, waarbij we, zoals eerder aangegeven, gericht zijn op het vergaren van informatie. Al deze informatie zorgt ervoor dat alle teamleden, maar ook de klant en andere belangrijke stakeholders, uitgelijnd zijn over de te bereiken doelen, wat we willen ontwikkelen en eventueel zelfs al de criteria waarmee succes wordt gemeten.

Onderstaand gaan we dieper in op deze sprint 0. In een latere post gaan we in de op de eerste sprint, die dus het tweede deel van kick-off is en meer focust op hóe we het product gaan ontwikkelen.

Sprint 0, visie op het product en het backlog

Vaak heeft onze klant een idee over het product en de mogelijkheden, maar heeft ze nog geen helder beeld over wat er ontwikkeld moet worden. Om hierachter te komen en meer zicht te krijgen op wensen, hebben wij de gewoonte om een workshop te organiseren met de klant en het ontwikkelteam samen, om zo een start te maken met de creatie van het Product Backlog.
Hiermee krijgen wij, maar dus ook de klant, steeds meer helderheid over het project en leggen we uitkomsten vast in een concept projectplan. Op basis daarvan zijn wij al in staat om ook een redelijke range te geven van benodigde tijd, doorlooptijd en dus ook mogelijke kosten.

Wij zijn heel blij met de transparantie en heldere communicatie. Uitstekend werk zo!

Het gezamenlijk hebben van een workshop is meer dan het ontwikkelen van een product visie en backlog. Het is ook zeer nuttig en zinvol om elkaar goed te leren begrijpen, risico's te zien, best practices te delen en als klant zeer nuttige kennis van het development-team mee te krijgen. Op deze wijze leren we elkaar, als klant en team, echt kennen. Een goed vertrouwen, een uitstekende start.

De inhoud van sprint 0

Voordat sprint 0 wordt afgenomen is er uiteraard wel een uitgebreide verkenning, dit is vrijblijvend en vindt plaats middels een gesprek met implementatie-specialisten en eventueel een aantal andere specialisten. Eigenlijk is deze eerste verkenning geen officieel onderdeel van sprint 0, maar uiteraard wel onderdeel van het hele proces in de aanloop naar een project.

Iedere sprint 0 kent een vast aantal terugkerende onderdelen en heel soms variëren we erop, afhankelijk van de case die voor ons ligt. Onderstaand een opsomming van in ieder geval de vaste onderdelen met een korte toelichting daarbij.

Sessie 1: idee ontwikkelingIn deze sessie proberen we met elkaar in te zoomen op inspirerende voorbeelden en de user journey te analyseren.
Het ontdekken van knelpunten en bedenken van oplossingen is een belangrijke basis onder de ontwikkeling van een product visie. Dit is eveneens de basis onder sessie 2.Sessie 2: verfijnen van epics (en user stories)Wat willen we nu eigenlijk en wat moet er grofweg gebeuren? Op deze vraag zoomen we met elkaar in om inzicht te krijgen op de belangrijkste onderdelen en kenmerken van het beoogde project.

Met elkaar zetten we de belangrijkste wensen op een rijtje, proberen we te classificeren en prioriteren (middels het Moscow principe), schetsen we eventueel de epics en bijbehorende wensen al grofweg uit in mogelijke "schermen".Intern: verwerking uitkomstenIntern zullen we de uitkomsten na afloop van de sessie administreren, vragen stellen en epics en user stories verfijnen.Sessie 3: prioritering en in kaart brengen projectfasenAls de grote lijnen ook meer details hebben en we met elkaar nog weer iets beter weten wat we willen, proberen we met elkaar ook een volgorde aan te brengen in epics en bepalen we waar we met elkaar als eerst mee aan de slag gaan.

Het verfijnen van epics, het proces zoals beschreven in sessie 2, gaat zich nog vaker herhalen en zo ontstaan er later mooie en vloeiende iteraties in projecten.Intern: concept projectplanningDit is een intern vervolg en gebaseerd op alle voorgaande momenten. Als we het nodig achten, kan het zijn dat we tijd investeren in zaken als een technisch ontwerp of de ontwikkeling van een proof of concept.
Zo hebben we met elkaar behoorlijk zicht op benodigde tijd.STARTOp basis van bovenstaande en alle ontwikkelde documentatie kunnen we van start gaan.

Tot slot

Een goede voorbereiding is écht het halve werk, maar overvoorbereiding is zonde van je werk. Als product owners zijn we na sprint 0 uitstekend in staat om het project goed en tot in de puntjes voor te bereiden, maar het is belangrijk om één valkuil vakkundig te omzeilen en dat is de valkuil van het teveel voorbereiden en daarmee invullen.

We proberen er om die reden goed op te letten dat we ook weer niet zoveel voorbereiden, dat het team niet meer voldoende aan het woord komt en zo belangrijke input en/of inzichten onvoldoende aan bod komen. Als we de balans hebben weten te bewaken, is het een feest om weer zo'n project samen af te trappen!

Begrippenlijst

Leuk, al die termen zoals epics, user stories, product owners, proof of concept, etc. Om niet teveel spraakverwarring te krijgen, gebruiken we wel graag de juiste termen maar verklaren we zo ook graag voor je nader.

Agile
Agile staat voor flexibel en is een manier van denken, werken en organiseren. Het stelt organisaties in staat om snel en effectief in te spelen op veranderingen in de buitenwereld.

Epics
Grote schetsmatig omschreven behoeften, ideeën. Iets wat je in je project mogelijk belangrijk vindt zoals bijvoorbeeld een pagina om makkelijke winkels te vinden. Een "store-locator" pagina dus.

User stories
Meer specifieke wensen binnen een epic, zoals bijvoorbeeld dat de winkels op zo'n store-locator pagina op een kaartje getoond moeten worden.

Acceptatie-criteria
Een nog specifiekere eis, iets waar de uitgewerkte user story aan moet voldoen zoals bijvoorbeeld dat de winkels op daar kaartje klikbaar zijn en door de webshop-beheerder kunnen worden ingevoerd.

Minimun Viable Product (MVP)
Een binnen het Agile project belangrijke mijlpaal, namelijk de eerste versie van het product waarin waarde voor de eindgebruiker vertegenwoordigd is. Vaak ook te lanceren, want van waarde.

Een MVP betekent niet dat je klaar bent, wel dat je al kunt profiteren van de waarde.

MoSCoW prioritering
Een manier om wensen te prioriteren door ze te classificeren in 4 mogelijkheden.

Must haves, should haves, could haves en would haves. Waar de benaming voor zich spreekt, gaan we vanuit.

Proof of concept
Een grove uitwerking van een onderdeel van het project om de werking te bewijzen of testen. Vaak de uitwerking van een user story of epic, een interactief design of een meer complete uitwerking.

Product owner
De persoon binnen het project die ervoor zorgt dat alle wensen en vereisten boven tafel komen en erop toeziet dat dit ook wordt meegenomen in de uitwerking die het team doet.

We werken altijd met een eigen product owner.

Scrum Master
Eén van de teamleden die het scrum proces bewaakt, het team faciliteert om goed volgens het scrum principe te werken. Niet alleen binnen het team, maar ook vanúit het team richting de klant en de product owner.

Stakeholders
Ook wel belanghebbenden genoemd. In scrum eigenlijk alle personen die te maken hebben met een epic, vaak de personen die behoefte hebben aan de uitwerking en dus belang bij hóe het wordt uitgewerkt.

Het in goed in kaart brengen van de stakeholders is onderdeel van ons proces.