Werkende Software – Agile Manifesto

Tijdens de trainingen Agile/Scrum die ik mocht verzorgen kreeg ik geregeld de vraag. Verliezen we de documentatie niet uit het oog? Werkende Software

Werkende software over Allesomvattende documentatie

In traditionele projecten zien we veelal nog dat de mensen veel (onnodig) papier produceren. Nog korter door de bocht, analisten en ontwerpers hebben het project al verlaten voordat er een stuk code of test wordt geschreven. Analisten zien niet wat het Team bouwt tot dat het product werkelijk in productie wordt genomen.

Werkende Software - Agile manifesto

In Agile wordt er geacht dat alle disciplines samen werken. Ook de analisten en ontwerpers. Bij mijn laatste opdracht hebben wij deze discipline onderdeel gemaakt van het team, aangezien zij domein expertise hebben. De klant/gebruikers waarvoor we het doen worden ook vaak vergeten. Deze dienen we in een zo vroeg mogelijk stadium te betrekken.

De uitdaging zit hem dan ook in het vinden van de optimale manier van documenteren. Werkende software is dan wel belangrijk, maar documentatie is nog steeds nodig. Agile Teams documenteren net genoeg. Bijvoorbeeld net genoeg om de architectuur vast te stellen, testen te kunnen schrijven, maar ook net genoeg documentatie om de software in beheer te kunnen nemen.

Bij mijn laatste opdracht kregen we een lijst met meer dan honderd acceptatie criteria waar alles aan moest voldoen voor de software in beheer genomen kon worden. Veel overlap van de verschillende afdelingen waren aanwezig in deze lijst. Veel acceptatie criteria waren niet van toepassing of we leverden documenten op die alleen waren om ergens een vinkje te halen om verder te kunnen in het proces.

Zorg er dan ook voor dat beheerders en stakeholders zo vroeg mogelijk betrokken worden bij het project. En niet komen met dergelijke lijstjes, maar actief deelnemen aan het project om ervoor te zorgen dat we als Team een minimale set kunnen opleveren. En niet de hele wereld erbij halen om een soorten van schijnzekerheid te creëren.

Stop niet met documenteren, maar denk eerst na als Team met je klant/gebruikers over het belang ervan. Wordt de documentatie echt wel gebruikt? Wij hadden de documentatie op een SharePoint site staan en konden monitoren hoe vaak deze nu echt bekeken werd en door wie. Dit was confronterend. We zijn bijvoorbeeld gestart met stoppen…. Stoppen met schrijven van de documentatie die niet gelezen werd, maar enkel gebruikt werd om een vinkje ergens te halen (bv. Master Test plannen). Vervolgens met de documentatie die nauwelijks gelezen werd. Hier hebben we onze klant/gebruikers mee geconfronteerd en in goed overleg zijn we samen tot een set gekomen die voldoende is om de software in beheer te nemen. En nog steeds kunnen we stappen maken…. Wees kritisch op wat je doet en waarvoor/waarom je het doet. Durf het ten discussie te stellen.

Value Stream Map (VSM) Proces optimalisatie

Om processen te kunnen verbeteren is het van belang om deze eerst in kaart te brengen. Wij hebben hiervoor gebruik gemaakt van een Value Stream Map, ook wel de waardestroom analyse genoemd. Hiermee kan de stroom (flow) van producten, diensten en informatie geanalyseerd worden, om daarna verbeteringen door te voeren. Een Value Stream Map (VSM) is een diagram of schematische weergave van een proces. Deze is onder ander bekend vanuit LEAN.

De waardestroom is een verzameling van activiteiten die nodig zijn om het product of de service te produceren en uiteindelijk te bezorgen bij de klant/gebruiker. In de waardestroom analyse worden de activiteiten die waarde toevoegen aan het proces, en de activiteiten die zorgen voor verspillingen gescheiden. Dit geeft een helder overzicht van het totale proces en waar verbeteringen mogelijk zijn voor een betere doorstroming. VSM volgens Wikipedia

Het resultaat van Value Stream Mapping is een een Value Stream Map. Deze geeft inzicht in verspillingen en overbodige processtappen.

Met Value Stream Mapping wordt altijd eerst de huidige situatie in kaart gebracht (Current State Map). Na het analyseren van deze wordt een VSM geproduceerd van de ‘ideale’ situatie (Future State Map). Om de ‘huidige’ situatie om te zetten naar deze ‘ideale’ situatie wordt vaak een plan gemaakt om dit te bereiken.

Wij zijn gestart in een kleine groepjes van drie mensen met het inkaart brengen van de VSM. Deze gemaakt vanaf het moment dat het idee ontstaat t/m dat het in beheer wordt genomen. bij twijfel hebben we dit getoetst bij de diverse domein experts. Tijdens deze sessies kwam ook navoren dat we veel documentatie opleveren die niet gebruikt wordt en geen waarde toevoegt.

Dit alles heeft de nodige tijd gekost, maar het Team levert nu sneller dan voorheen en de kwaliteit is omhoog gegaan, omdat men meer tijd heeft om goed werkende software op te leveren. Naast de documentatie hebben we door de organisatie heen diverse voorstellen erdoor heen gekregen om het proces te verbeteren. Het is niet iets wat we zomaar even gedaan hebben. Het heeft zeker de nodige tijd gekost. Ja… er zijn ook fouten gemaakt, maar daar hebben wij juist veel van geleerd. Cultuur was en blijft een belangrijke factor. Dit was toch wel een omslag om anders te gaan denken dan we gewoon waren, maar het resultaat mag er wezen. En hebben zo een cultuur ingang gezet van Continuous Improvement.

Werkende Software – Agile Manifesto

Daan Wagner on LinkedinDaan Wagner on TwitterDaan Wagner on Wordpress
Daan Wagner
Daan Wagner
Consultant at LEANIG
Enthousiast Agile Consultant/Coach.  Help Teams en haar omgeving met het adopteren van Agile. Agile is meer dan alleen werk. Het is één van mijn passies naast reizen en fotografie.

Daan Wagner

Enthousiast Agile Consultant/Coach.  Help Teams en haar omgeving met het adopteren van Agile. Agile is meer dan alleen werk. Het is één van mijn passies naast reizen en fotografie.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Verplichte velden zijn gemarkeerd met *