De rol van user stories

Je hebt Agile, en je hebt “Agile”. Ik bedoel: je hebt ontwikkelteams die opereren volgens de Agile mindset, die zich de filosofie en de waarden achter Agile methodieken eigen hebben gemaakt en daar naar handelen - en je hebt ontwikkelteams die de uiterlijke vormen van Agile hebben overgenomen, maar die in de praktijk eigenlijk weinig met Agile van doen hebben.

Cargocult

Het tweede soort team heeft wat weg van de Cargocults die vanaf het einde van de negentiende eeuw ontstonden in Melanesië. Die religieuze gemeenschappen immiteerden het gedrag van Europese kolonisten, in de hoop dezelfde weelde te verkrijgen. Maar de Melanesiërs hadden geen weet van de complexe infrastructuur die die weelde mogelijk maakte; ze dachten onterecht dat het overnemen van de uiterlijke kenmerken van de kolonisten voldoende zou zijn.

Waar de grens loopt tussen die twee is niet altijd even goed te zeggen. Dat kan bijvoorbeeld komen doordat de visie en houding van de teams niet overeenkomt met die van de organisatie. Is een Agile team in een niet-Agile omgeving wel echt Agile? Kan zo’n team dat überhaupt wel zijn?

Een tweede bron van onduidelijkheid komt vooruit uit het feit dat Agile een notoir ondergedefinieerd concept is. Wie zich louter en alleen op het Agile manifest beroept, krijgt een totaal ander idee van wat deze vorm van ontwikkelen inhoudt, dan wie Robert Martins Clean Agile erop naslaat. (Het boek is overigens een aanrader; klik hier voor mijn recensie.)

En wie The Art of Agile Development van James Shore¹ doorbladert, doet weer heel nieuwe opzichten op.

Stories

Zijn hoofdstuk over stories (ook wel bekend als user stories, in Scrum ook wel Product Backlog Items (PBI’s) genoemd) deed me wel opveren, in elk geval.

Dat is niet in de laatste plaats doordat ik in het verleden heb geschreven over hoe ik mijn PBI’s opzet. Shores stelling - mening? inzicht? - is provocatief: een story moet op een index card passen. de volledige story zou dus uit niet meer dan een zin of een kreet hoeven bestaan.

Wat Shore effectief voorstelt, is om alles behalve de titel uit mijn voorstel te schrappen. Context, oplossingsrichting, acceptatiecriteria: weg ermee!

Sterker nog, hij noemt een investering in het schrijven van goede stories expliciet als een voorbeeld van Agile op z’n Cargocults. Het gaat immers niet om de story, het gaat om het leveren van waarde. En alle tijd die wordt gestoken in het uitgebreid beschrijven van een story, gaat niet zitten in het leveren van waarde.

Schrijven en spreken

De voor de hand liggende vraag is: hoe kan deze manier van werken ooit, eh, werken? Hoe weet je als ontwikkelaar in hemelsnaam wat je moet bouwen, als dat niet in een document is vastgelegd?

Het antwoord daarop is te vinden in het Agile manifest. Immers: Individuals and interactions over processes and tools. En: Customer collaboration over contract negotiation.

Dat betekent: de achtergrond van een story - de context, de oplossingsrichting - zouden onderdeel moeten zijn van de tribale kennis van het team.

Daarmee is niet gezegd dat het team zo goed in de materie zit, dat het niet nodig zou moeten zijn om uitgebreide specificaties te schrijven. De story fungeert niet als specificatie, maar als middel om het gesprek op gang te brengen.

Daar komt de samenwerking met de klant om de hoek kijken. In een echte Agile omgeving, moet een ontwikkelaar tijdens het coderen zó naar een klant kunnen stappen met de vraag: wil je het meer zus of zo?

Uitgewerkte specificatiedocumenten fungeren een tussenpersoon. Wie Agile is - écht Agile -, beseft zich dat zo’n tussenpersoon alleen maar voor ruis kan zorgen. Zo’n ontwikkelaar richt zich liever meteen tot de bron.

Het gaat niet om dat wat opgeschreven is. Het gaat erom dat er met elkaar gesproken wordt.

Werkbaar

Is dat werkbaar? Misschien, als een bedrijf tot in haar kern de Agile mindset tot zich heeft genomen. In een omgeving waar klanten het doodnormaal vinden van hun dagelijks werk weggeroepen te worden om met ontwikkelaars te sparren, zou Shores stelling - mening? inzicht? - nog best kunnen werken.

Maar de meeste bedrijven zijn niet op dat punt - ik druk het nog voorzichtig uit. Volledig afscheid van mijn eigen methodiek zou ik dus nog niet durven nemen. Is dat realisme of koppigheid? Daar zou je een goed gesprek over kunnen voeren, denk ik.

agile ontwikkeling · bedrijfscultuur · boeken · communicatie · product backlog items · samenwerking