"Bij de Proof of Collaboration sprints ligt de nadruk op het hoé, lever je direct stukjes werkende software op en werk je samen als één Scrumteam."

Mark van der Ploeg, CPO

avatar

Van Proof of Concept naar Proof of Collaboration

Neem de proef op de som in een praktijksituatie

banner

De voordelen en de uitvoering van de Proof of Collaboration

Proof of Concept: een fenomeen uit de Waterfall methode, waarbij je door je klant gevraagd werd om aan te tonen dat je in staat was het project uit te voeren. De klant wist precies wát er werd opgeleverd, maar nooit hoé er samengewerkt werd. Bij de Proof of Collaboration sprints ligt de nadruk op het hoé, lever je direct stukjes werkende software op en werk je samen als één Scrumteam. Je neemt de proef op de som in een praktijksituatie.

Waterfall – Proof of Concept

Bij de Proof of Concept nam je als klant een klein risico door slechts een gering budget te investeren en zo kon je ook nog eens ontdekken wat de kwaliteit van de leverancier was. Je wist of ze jouw requirements (scope) goed begrepen hadden, je wist of ze op tijd leverden (deadline) en je kreeg een indicatie van de kwaliteit van de software. Je kon precies zien wát er werd opgeleverd. Je zag alleen nooit hoé er tijdens de bouw van de POC gewerkt werd. Ach, een aanvaardbaar risico. Het deed er immers niet toe. Of toch wel?

De wereld is veranderd. In een Agile software methodologie bestaat Proof of Concept – en daarmee de bijbehorende terminologie (scope en deadline) – niet meer. De vraag hoé er gebouwd moet worden is minstens even belangrijk als het wát. De vraag tussen wat er gebouwd moet worden en hoe het gebouwd moet worden, is uit elkaar gehaald én gelijkgesteld. Geheel terecht overigens! Dus wat nu?

Vervang de POC door een POC: de Proof of Collaboration.

Agile – Proof of Collaboration

Een Proof of Collaboration is een periode van drie of vier sprints waarin het voltallige Scrumteam met elkaar aan de slag gaat en antwoord probeert te krijgen op de vraag: kunnen wij succesvol samenwerken? De Proof of Collaboration is dus gericht op het ontdekken en leren samenwerken als één team. De vraag wát er gebouwd moet worden is ondergeschikt aan de vraag hoé er samengewerkt wordt.

Het doel is om transparantie en vertrouwen op te bouwen tussen opdrachtgever (Product Owner) en leverancier (Scrum Master en developmentteam). Dat doen we door rollen, verantwoordelijkheden, verwachtingen, gelijkgestemdheid en een werkbaar proces binnen het team, via een praktijksituatie, duidelijk te maken.

Zo luidt the Scrum Guide: “Empiricism means working in a fact-based, experience-based, and evidence-based manner. Scrum implements an empirical process where progress is based on observations of reality, not fictitious plans.”

Aan het einde van elke sprint plant het Scrumteam een retrospective in om verbeteringen in de samenwerking te bespreken en door te voeren. Aan het einde van de POC bespreken we in een breder kader of de vooruitgang voldoende is om een langdurigere samenwerking aan te gaan. Je zou kunnen zeggen dat we op dát moment een extra uitvoerige retrospective inlassen met én voor stakeholders om te bepalen of er de intentie uitgesproken kan worden voor een lang(er) lopend traject.

Op basis van één sprint zijn er niet genoeg evidence based experiences, daarom duurt de POC drie of vier sprints. In deze periode kan er doorgaans een goede basis gelegd worden voor een succesvolle samenwerking. Als er na vier sprints geen goede basis gelegd is, is het redelijk om de samenwerking te beëindigen.

Oplevering van werkende software

Er wordt hoe dan ook aan het einde van elke sprint werkende software opgeleverd. Het verschil met een ouderwetse Proof of Concept is dat vooraf niet wordt afgestemd hoeveel er precies wordt opgeleverd (geen scope). Het Scrumteam pakt altijd de bovenste items van de Backlog en ontdekt gedurende de Proof of Collaboration hoeveel er per sprint gedaan kan worden.

Wat ná de POC periode?

Er zijn twee opties:

  • Er was niet genoeg chemie voor een langdurige samenwerking. Dat betekent dat de klant met datgene dat gebouwd is (nog steeds werkende software) een ander vervolgtraject in kan.
  • De samenwerking verloopt goed. Er wordt simpelweg doorgewerkt op de gevalideerde manier van samenwerken en zal (zoals Scrum citeert) aan het einde van elke sprint door middel van een retrospective geoptimaliseerd worden.

Nog niet geheel duidelijk?

Vergelijk het eens zo: in een Proof of Concept wordt een leverancier gevraagd iets te bouwen wat drijft en lijkt op een boot. Vervolgens wordt er gehoopt dat de leverancier uiteindelijk een boot kan bouwen. Gek toch? Hoe realistisch is die aanname eigenlijk?

Tijdens de Proof of Collaboration sprints bouwt het Scrumteam een heel klein stukje boot, maar wel van de échte boot. En leggen we vooral de focus op de samenwerking tussen leverancier en opdrachtgever om een goed transparant werkproces af te stemmen waaruit een veel waardevoller beeld ontstaat voor de uiteindelijke oplevering van het project.

Wil je meer weten over Mark?

Als People Manager hopt Mark van kantoor naar kantoor. Met zijn achtergrond als Delivery Manager kent hij de ins en outs van Scrum en offshore werken en momenteel versterkt hij het managementteam waarbij zijn focus ligt op “People en Processes”.

photo

rb2 is meer dan Mark we hebben nog meer goede verhalen

Bekijk de andere blogs
picture