Meer en meer bedrijven zien de voordelen van Agile. Voordelen voor het bedrijf maar ook voor de gebruikers van de software. Maar helaas is dat gezichtspunt vaak onderbelicht. Daarom deze bijdrage waarin ik kort en bondig uitlegwaar op te letten bij het toepassen van Agile-ontwikkelen.
Als user experience-expert is het voor mij heel gebruikelijk om gebruikers te betrekken bij het designen en ontwikkelen van digitale oplossingen. Luisteren en analyseren van de gebruikersbehoefte aan functionaliteit en ondersteuning is iets wat toch nog steeds te weinig gedaan wordt. Zeker als bedrijven Agile willen gaan implementeren. Want een sprint van twee tot vier weken geeft die ruimte toch niet…
Uiteraard ben ik het daar niet mee eens. Als je de gebruiker centraal wilt zetten kan dat altijd! In Agile kan je kiezen door het opzetten van een Ready-team. Een team wat werkt op dit vlak en dan een sprint later het binnenbrengt bij het development team. Maar je kan ook gebruikers behandelen als stakeholders die minimaal aan het begin en het einde van de sprint betrokken worden.
De technologische wereld van de gebruikers verandert snel. Agile biedt de mogelijkheid om die veranderingen te volgen, zonder dat de gebruiker erom vraagt. Denk aan het implementeren van een live stream data/video naar aanleiding van Meerkat. Zo kan je actueel en relevant blijven voor de gebruiker.
Maar Agile kan ook een belangrijk nadeel opleveren. Omdat je kleine werkende stukjes functionaliteit oplevert is de valkuil dat je ook deze stukjes elke keer live brengt. De gebruiker kan dat als chaotisch ervaren. Belangrijk is om dit te onderzoeken. Oplossing kan zijn om meerdere sprints te bundelen in één release. Maar test en toets dit.
Agile is de methode die ervoor zorgt dat een gebruikersgerichte organisatie ook snel de juiste functionaliteit kan leveren aan zijn doelgroep. Daarom is het niet de vraag of je het gaat doen, maar wat de specifieke Agile kenmerken zijn voor jouw organisatie. Start volgens het boekje en laat je teams met optimalisatie komen.
haha “meerdere sprints te bundelen in één release”
Als de gebruiker krijgt waar die om vraagt ervaart die dat als chaotisch.
Ik weer er nog een. Deel het ontwikkel ontwikkel proces op in fasen en besteed veel tijd aan requirements en design, pas daarna dan ga je implementeren. Perfectionisten kunnen er zelfs voor kiezen om de requirements op te stellen zonder dat de eindgebruiker er om vraagt.
Ja, de technologishe wereld verandert snel.
Agile kan je ook tegenwerken als je als besluitloze organisatie maar door blijft scrummen en minimale vooruitgang boekt omdat elke keer de plannen totaal worden omgegooid. Maar dat soort organisaties (oftewel overheden) zal met elk alternatief soortgelijke resultaten boeken.
Ha ha, die Felix, jij hebt het over de waterfall aanpak? nee dan doe je niet meer mee. Het agile manifesto zegt toch: als het maar werkt? Wat moet je dan met requirements en design? Daar hebben we toch userstories voor? Ik ben er wel voor een tijdje op je handen zitten en heel goed nadenken, een beetje in die zitzak hangen of wat voetbalbakken. Programmeren is altijd al een agile activiteit geweest, als agile tenminste staat voor wendbaar en ruimte voortschrijdend inzicht. Alleen is geloof ik agile een synoniem voor scrum. Ik ben wel voor de agile waterfall aanpak.
@Johan Of het alleen bij de overheid zo werkt betwijfel ik maar agile lijkt wel eens een synoniem voor het adhoc van de hak op de tak kunnen springen, maar zo werkt dat niet met ICT systemen. Denk wel eens, scrum is automatiseren met je neus op de grond en oogkleppen voor van sprintje naar sprintje waarbij ook de nog de verkeerde mensen aan de touwtjes trekken. Oh nee, daar heb je tegenwoordig het zelfsturende team voor. Samen, als team.
Een aantal jaar geleden heb ik in een Agile project gezeten waarin we beide voorgestelde methodes hanteerden: bij de start van het project was een UX designer betrokken die vooraf en met gebruikers samen de wireframes opstelde en prototypes valideerde. Toen we pakweg 15 van de 35 schermen hadden gerealiseerd, zijn we als team verder gegaan op de ingeslagen weg, zonder de UX man. Onze aanpak was stuitend simpel: wij tekenden de schermpjes op wit A4 met potlood, en dan per scherm meerdere varianten. Vervolgens mocht de gebruiker daaruit kiezen en dat werd gerealiseerd. Simplicity first!
jaja, epische user stories over BDUF, maar als je ze meteen geeft wat ze vragen is het weer niet goed. Vroeger had je nog vakmannen. Waren hun tijd ver vooruit met hun discontinuous integration. Lekker in je zitkuil Application Delivery Gappen nog voordat dat chill was. Wat was de vraag ook alweer ?