Stel je voor dat je op een verjaardag aan iemand uit wil leggen wat je nieuwe project inhoudt. Ik heb het de laatste tijd een aantal keren moeten doen. Weliswaar niet op een verjaardag, door de lockdown, maar wel meerdere malen tijdens een wandeling. Het ging over een project dat ik zelf heel gaaf vond. De eerste keer dat ik het uitlegde vertelde ik over een structuurwijziging, processen stroomlijnen en betere besturing.
“Gaaaaaap”
Halverwege kreeg mijn enthousiasme de overhand en begon ik eigenlijk opnieuw:
“Om klaar te zijn voor de toekomst wil de organisatie medewerkers veel meer eigenaarschap geven. Ze vinden het belangrijk dat ze creatief zijn in het helpen van de klant. Bovendien balen ze van het enorme verloop onder het personeel. Daarom…”
Nu gingen de ogen van mijn gesprekspartner helder staan. Er ontstond een beeld, inleving en nieuwsgierigheid over hoe je zoiets voor elkaar kan krijgen. Mijn project werd een verhaal en deze persoon wilde zo meedoen!
Dat werkt niet alleen op een verjaardag of tijdens een wandeling. Ook in een organisatie is het superbelangrijk dat het project een verhaal heeft. Voor de mensen die het project betalen, degenen die het resultaat moeten gebruiken en natuurlijk voor degenen die het product of de dienst aan het maken zijn.
Projecten zonder verhaallijn
De laatste tijd kom ik steeds meer projecten tegen die lijden onder het tegenovergestelde. Onder het mom van agile zijn de oude structuren losgelaten en daarmee zijn ze vrijwel alle (verhaal)lijn kwijtgeraakt. Projecten zonder visie, planning, stuurgroep of rapportages. Weliswaar stand-ups en sprints, maar geen tussentijdse opleveringen en geen tussentijdse feedback. Stakeholders hebben geen idee of het project goed verloopt, projectmedewerkers weten niet wat er precies van ze verwacht wordt, onderlinge afstemming tussen partijen vergt heel veel moeite.
Ik kom backlogs tegen als een grote bak met losse items, waarover niemand het overzicht heeft. Het zijn ouderwetse requirements, verpakt in een ander jasje. Ondanks de benamingen ‘stories’ en ‘epics’ is er van een verhaallijn geen sprake. Wat moet eerst? Wat levert het meest op? Wat hoort bij elkaar?
Het verhaal als oplossing
Terug maar weer naar een ouderwetse projectaanpak? Daar is zit tenminste een duidelijke lijn in. Maar dat is geen oplossing voor organisaties die juist de flexibiliteit en energie van een agile aanpak willen gebruiken. Agile lijkt alleen langzaam te verworden tot een cowboyaanpak, waarbij iedereen op zijn eigen manier aan het werk is. Het grootste manco is dat deze trajecten geen verhaal hebben. Het is onduidelijk geworden waarom een project loopt, hoe het verloopt, welke stappen er worden genomen en waar het heen gaat. Een verhaal zorgt voor samenhang tussen de onderdelen. Het creëert betrokkenheid en saamhorigheid. Met een goed verhaal neem je de omgeving mee, snappen mensen waarom iets gebeurt en willen ze er deel van uitmaken.
Het bijzondere is dat een methode als Scrum draait om verhalen. Dat is een groot deel van de kracht ervan. Hoe kan juist dat aspect zo snel verdwijnen? En nog belangrijker: hoe krijg je het terug?
Stappen die je kunt zetten
Om het verhaal terug te krijgen in mijn projecten gebruik ik graag Jeff Patton als leidraad. Ik kan iedereen aanraden zijn boek ‘Story mapping’ te gebruiken bij het vormgeven van een agile werkwijze met een verhaal. Hieronder noem ik 3 stappen, die ik gebruik om zulke verzande trajecten weer een lijn te geven.
1. Maak echte Stories
Stories en Epics zijn andere woorden voor ‘verhalen’. In een verhaal speelt altijd iemand een hoofdrol. Die iemand vormt het perspectief van de story: wat heeft deze persoon nodig? De hoofdrolspeler heeft ook een doel. Van elke story moet duidelijk zijn wat de bijdrage is aan dat doel. Door dit element weer terug te brengen in de ‘grote bak stories’ zijn de delen weer begrijpelijk geworden.
Een paar voorbeelden. In plaats van ‘analyseren mailboxen’ bij een migratie naar Office365 krijg je: als projectmanager wil ik weten wat de aantallen en hoe groot de mailboxen van onze organisatie zijn, zodat ik kan bepalen of ik ze in een keer kan overzetten. Of vanuit een opleidingsproject, waarin een item ‘cross selling’ staat. Dit kan veranderd worden in: als medewerker wil ik een training in cross selling hebben, zodat ik weet hoe ik in een chatgesprek andere relevante producten kan verkopen. En dit zijn dan alleen de titels. Vanuit daaruit start het gesprek over wat er precies nodig is en hoe dat vervaardigd kan worden. Dus niet alleen delen op papier (of Jira), maar echt vertellen en bespreken (‘Individuals and interactions over processes and tools)’.
2. Maak een story map
Een story map brengt de losse stories met elkaar in verband en laat zien welke gezamenlijk een oplevering kunnen vormen. Een release die bruikbaar is voor gebruikers. Een story map is een fantastische manier om samen met het team en andere stakeholders een prioritering en fasering aan te brengen in de realisatie. Opdrachtgevers en gebruikers gaan opeens ook weer begrijpen hoe het project verloopt.
3. Stel de feedbackloop in
De logische volgende stap is om het iteratieve aspect weer terug te brengen. Het verhaal van het project speelt zich niet af buiten de werkelijkheid van alledag. De gebruiker wordt er dagelijks of wekelijks weer in getrokken om mee te doen. Met deze informatie kan de koers bijgesteld worden, zodat de naam ‘agile’ weer verdiend is.
Trots op je verhaal
Ben jij trots op de projecten die je doet? Denk er dan over na als een verhaal, vertel dat verhaal en organiseer het als een verhaal. Dan ben jij niet lang meer de enige die enthousiast is.
Comments