Product teams binnen traditionele organisaties
Klassieke waterfall projecten, ze komen steeds minder vaak voor. Steeds meer organisaties zien de toegevoegde waarde van het SCRUM werkproces en Agile methodes. We sprinten wat af: korte periodes van twee weken waarin je een deel van het digitale product maakt en afsluitend aan de sprint demonstreert aan alle stakeholders. Maar hoe Agile zijn we nu eigenlijk echt?
De afgelopen 10 jaar heb ik zowel Agile als waterfall gewerkt aan de ontwikkeling van de user experience voor websites en software applicaties. Wat blijkt? In de praktijk blijkt de aanpak steeds weer anders, welke afspraken we vooraf ook met elkaar maken. Hoe kan dit?
Continuous delivery
“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”
Dit is de eerste regel uit het Agile manifesto lijkt misschien niet de meest ingrijpende of meest belangrijke regel. Maar laten we hier eens goed naar kijken. Want, hoe eerder je nieuwe functionaliteiten naar de klant brengt hoe eerder je daarop feedback krijgt. Deze feedback is essentieel binnen Agile product ontwikkeling. Snel leren is snel innoveren, en dus minder fouten maken. Dat weten ze bij Amazon maar al te goed:
In 2013 schreef Josh Seiden (@jseiden) al een blog waarin hij met ons deelde dat Amazon iedere 11.6 seconde nieuwe code deployt naar productie. Dankzij deze continuous delivery weten zij precies wat wel en wat niet werkt en zijn ze in staat geweest om de concurrentie voor te blijven.
Uit ervaring weet ik dat lang niet iedere organisatie goed is ingericht op continues delivery. Maar al te vaak komt het voor dat er iedere twee weken een stukje software wordt opgeleverd en er een demo wordt gegeven, maar dat deze code vervolgens niet direct wordt doorgezet naar productie-omgeving. In de praktijk wordt er vaak maanden doorgewerkt voordat er ook maar iets wordt getest met echte gebruikers.
Het gevolg is dat er lang wordt doorgewerkt op basis van aannames, zonder feedback van klanten en gebruikers. Zonder data leer je niets en zul je nooit de maximale waarde uit je product kunnen halen. Het gaat al mis bij het eerste principe uit het manifesto.
De Agile organisatie
Steeds meer organisaties moeten wel aan de slag met Agile en SCRUM als de methode om te kunnen anticiperen op een snel veranderende markt. Niet gek, want hoe eerder je leert wat wel en wat niet werkt, hoe eerder je het product of zelfs de strategie kunt aanpassen aan de hand van nieuwe inzichten. Om dit te kunnen laten slagen is het niet voldoende om op operationeel niveau volgens SCRUM te gaan werken, de organisatie moet als geheel meeveranderen.
Traditioneel management
“Hoeveel sprints kost het om dit te maken?”
Dit is een vraag die veel traditionele managers stellen nadat zij een business case hebben gemaakt voor een nieuw idee en hier budget voor op hebben gehaald. De features zijn mooi vastgelegd in een functioneel ontwerp en het ‘grote inschatten’ kan beginnen.
Oplossingen worden opgeknipt in brokken en het team krijgt dankzij het SCRUM proces meer grip op wat ze kunnen realiseren binnen de beschikbare tijd. Het lijkt efficiënt: de opdrachtgever krijgt wat hij vraagt en ze gaan live met een product waarvan ze denken dat het goed is.
Doordat het management akkoord heeft gegeven op deze vaste scope worden er weinig tot geen feedback loops in het proces ingebouwd. Er is geen ruimte om te leren. De kans dat het product aansluit bij de behoefte van de klant is daardoor een stuk lager.
Conclusie
Om verschillende redenen wordt de kracht van het team en de waarde van gebruikersinzichten niet goed benut. Gebrek aan ruimte en tijd is vaak de achterliggende oorzaak. Terwijl juist door het ontbreken van feedback loops teams onvoldoende leren en niet in staat zijn essentiële verbeteringen door te voeren. Organisaties die geen ruimte bieden aan feedback loops zijn daardoor minder in staat om mee te bewegen in een snel veranderende markt.
Wat is een belangrijke eerste stap om het proces te veranderen? Geef product teams geen kant en klare, voorbedachte oplossingen, maar geef ze duidelijke doelen en targets. Ik adviseer product managers om eerst samen met het team aannames op te stellen en te vragen om deze gedurende het proces te valideren. Daardoor onstaat een meer transparante vorm van samenwerking met gemeenschappelijke doelen.
Gaandeweg zal het initiële product altijd veranderen op basis van wat je leert van de gebruikers, en dat is precies de bedoeling. Wanneer je als team niet de tijd en ruimte hebt om hierop te anticiperen maak je snel de verkeerde keuzes. Dat kan heel kostbaar zijn.
Met de juiste mensen aan boord en een klantgerichte (Agile) mentaliteit zul je zien dat je veel sneller in staat bent om gezamenlijke doelstellingen te behalen met onderscheidende software en hele tevreden gebruikers als resultaat.
Herken je bovenstaande situatie of heb je een aanvulling?
