Agile development en Blue Coded
Of je nu aan het begin staat van een transitie naar Agile werken, of je bent bezig met Kaizen je kunt altijd uitdagingen tegen komen in het toepassen van Agile. Op dat moment is het goed te weten wat goed werkt en wat niet, wat zo belangrijk is aan Agile development en wat het je kan opleveren als je Agile werkt.
We geven je daarom graag een inkijkje in het Agile proces vanuit onze ervaring:
Focus binnen Agile
Als je Agile invoert, of je sleutelt aan je Agile proces, dan is het belangrijk om de kernwaarden niet uit het oog te verliezen. Natuurlijk moet je dan denken aan het Agile Manifesto https://agilemanifesto.org/ en de principes achter het Manifesto https://agilemanifesto.org/principles.html.
Vanuit onze ervaring bij Blue Coded met het invoeren en verfijnen van Agile, willen we een aantal zaken belichten die in onze projecten extra aandacht krijgen.
Focus op Return On Investment (ROI)
Het ontwikkelen van software is een investering die zich pas kan uitbetalen op het moment dat de software in productie is. Dan pas kan er rendemenent zijn door verkochte producten, geleverde diensten of een grotere klanttevredenheid. En dan pas, wanneer de software in productie is, kan er feedback komen van de gebruikers om de applicatie te verbeteren. Om deze reden hebben we een focus op vaak en efficiënt releasen van de software.
De return
De return van een investering moet de investering terugverdienen. Dit klinkt allemaal logisch, maar is een element dat eenvoudig uit het oog kan worden verloren. Bij Blue Coded kijken we daarom kritisch naar de gewenste oplossing in het licht van het budget. Wanneer we doorvragen en komen tot de kern van het probleem, blijkt bijvoorbeeld automatisering van een bepaald proces helemaal niet de oplossing is.
Met de juiste prioriteiten
Wanneer er veel functionaliteit is om te realiseren, is het belangrijk om de features met het hoogste rendement als eerste op te pakken. Het is dan zaak om prioriteiten te stellen, maar het stellen van prioriteiten is alleen mogelijk als je voldoende inzicht hebt in de totale hoeveelheid werk. Bij Blue Coded helpen we je om een backlog[2] op te stellen, zodat je inzicht krijgt in de totaal te realiseren functionaliteit en daarmee de juiste prioriteiten kunt stellen. Hierdoor zijn wij altijd bezig met het realiseren van jouw hoogste prioriteit!
Feedback als input voor verbetering
Wanneer je een wijziging aanbrengt om bijvoorbeeld een proces te verbeteren, maar je weet niet of het gewerkt heeft, ga je dan door met de volgende aanpassing? Neem je dan de volgende stap? Het risico bestaat dat je eerste stap niet de juiste richting had en dat je nu verder afdwaalt. Wat je nodig hebt is feedback. Je moet weten wat het resultaat was van je wijziging, zodat je de richting kunt bepalen van je volgende stap.
Feedback is een belangrijke factor in het bepalen van richting. Het kan helpen de groei richting te geven.
Feedback is niet alleen essentieel voor de groei en verbetering van het software proces, het grijpt in op veel meer plaatsen, bijvoorbeeld:
- De ontwikkeling van de software met nieuwe features en nieuwe versies
- De ontwikkeling van een teamlid in zijn rol als bijvoorbeeld developer, stakeholder of interactie-expert
- De planning en voortgang van het project
Bij Blue Coded omarmen we feedback!
Focus op lange termijn succes
Bij Blue Coded zitten we erin voor de lange termijn. We willen dat de klant succesvol is, op de korte (het huidige project), maar ook op de langere termijn. Dat betekent onder andere:
- dat we altijd realistisch zijn over inschatten en risico’s
- dat we actief scopen en regelmatig kritische vragen stellen
- dat we actief goedkopere alternatieven aandragen
- dat we niet denken dat automatisering altijd de oplossing is
We geloven namelijk dat een klant alleen een terugkerende klant zal zijn als deze zelf succesvol is in haar projecten.
Lange termijn succes
Daarnaast speelt budgetbewaking een belangrijke rol. Bij Blue Coded zijn we gedreven om de klant hierin te ondersteunen en te faciliteren.
Grip op software ontwikkeling
In een Agile project maak je een afspraak over een fixed-budget of een fixed-scope, maar niet over beide. Het betekent dat we een afspraak maken of het budget vaststaat of de te realiseren functionaliteit (de scope) van het project. Een Agile project kan bij een klant daarom nog wel eens de associatie geven met het uitschrijven van een blanco cheque. Hoe kan een klant ervoor zorgen dat hij binnen tijd en budget de functionaliteit krijgt die hij nodig heeft?
Als we naar de praktijk kijken, hadden de klassieke projecten met een dik uitgewerkt functioneel ontwerp, een fixed scope en een fixed budget uiteindelijk evenveel of zelfs meer onzekerheden. Het zou naïef zijn te denken dat, wanneer het budget bereikt is, de scope niet onder druk zou komen te staan.
Het grote verschil met Agile projecten is dat deze onzekerheden benoemd worden en dat er een proces staat om met deze onzekerheden om te gaan. Je kunt hierbij bijvoorbeeld denken aan:
- regelmatig opleveren (iedere drie weken), zodat de afwijking van de verwachting van de klant ten opzicht van het opgeleverde minimaal kan zijn
- opstellen van een backlog, zodat er inzicht komt in de totale hoeveelheid te realiseren functionaliteit
- opstellen van een backlog, zodat we de verschillende features realiseren in de volgorde van de prioriteit van de klant
- plannen zien als een activiteit die voortdurend wordt uitgevoerd, omdat het project dynamisch is en we willen inspelen op feedback vanuit het proces, de eindgebruiker en de klant
Wanneer we Agile invoeren, zien we in de praktijk dat er veel grip onstaat op het ontwikkelproces. Het ontwikkelproces wordt beheersbaar binnen een sprint[3], maar juist ook daarbuiten. Het proces geeft veel mogelijkheiden om te sturen en doordat de ingerichte feedback loops informatie verzamelen over het proces, het product, etc, kunnen we met de juiste informatie de juiste beslissingen maken.
Er is zodoende veel inzicht en grip in de voortgang van het ontwikkelproces en het resultaat, terwijl er tegelijkertijd ook veel ruimte is om in te spelen op verandering.
Door het toepassen van Agile wordt de kans op een succesvol project veel groter.
De praktijk
Dan vraag je je misschien nu af hoe deze zaken zich vertalen naar de praktijk bij Blue Coded?
Sprint
Voordat een sprint begint, wil je al weten wat er zal worden opgeleverd, terwijl je in de sprint flexibel om wil kunnen gaan met veranderingen. Maar waar komen die veranderingen eigenlijk vandaan en hoe ga je daarmee om?
Inspelen op verandering tijdens de sprint
Die veranderingen in een sprint komen onder andere vanuit het voortschrijdend inzicht (feedback) dat logischerwijs ontstaat tijdens een sprint. Denk dan bijvoorbeeld aan het volgende:
De klant ziet voor het eerst het scherm en realiseert zich bijvoorbeeld dat:
- er functionaliteit ontbreekt
- het niet intuïtief werkt
- er een betere manier is voor de eindgebruiker om zijn doel te bereiken
De developer realiseert zich dat:
- er op deze manier een performance probleem kan optreden
- er efficiëntie kan worden behaald door vergelijkbare functionaliteit in te zetten
Het realiseren van de functionaliteit in de sprint zien we als een dialoog waarin samen wordt gezocht naar de optimale oplossing binnen het bepaalde budget.
Focus:
Grip op de sprint
Wanneer je, wanneer veranderingen zich voordoen tijdens de sprint, het Agile proces juist hanteert, kun je op een heel gecontroleerde bewuste manier de ruimte maken in de sprint om op de veranderingen te anticiperen. Dit komt onder andere doordat, door de juiste tooling en het juiste inzicht, de informatie beschikbaar is om de juiste beslissing te maken.
Onze insteek is daarom:
Discipline op het proces, flexibiliteit op de inhoud
Focus:
Maintainable pace
Een goede discipline op het proces zorgt ervoor dat er rust is bij de zowel de klant, de developers als de overige teamleden. Hierdoor kun je zorgen voor een maintainable pace, waarin features worden gerealiseerd (en snelheid waarmee software wordt opgeleverd). De maintainable pace is weer erg belangrijk voor het goede functioneren van alle teamleden, alsmede de langetermijnplanning.
Focus:
Efficiëntie
Bij Blue Coded zijn we altijd op zoek naar efficiëntie. Efficientie beperkt de benodige kosten en dus de investering.
Dit kun je bijvoorbeeld terugvinden in onze drive om “grote” vergaderingen te voorkomen. Ten eerste is een vergadering in een grotere groep mensen als strikt noodzakelijk natuurlijk zonde van de resources en dus het budget. Ten tweede zien we dat er uit kleinere vergaderingen betere resultaten kunnen komen, omdat het makkelijker is een sfeer te creëren waarin men zich kwetsbaar op durft te stellen, die zorgt dat de juiste feedback (op bijvoorbeeld een idee) kan worden gegeven.
Efficiëntie vind je bij Blue Coded ook in de “the art of maximizing the amount of work not done”[4]. Een voorbeeld hiervan is onze uitwerking in “grove stories” (Zie paragraaf “Grove Stories”).
Focus:
De review meeting
Om optimaal te leren van een sprint, en dus alle feedback te behandelen van een sprint, houden we aan het eind van iedere sprint een review meeting. In de review meeting lopen we integraal door de sprint heen en kijken we naar de opgeleverde functionaliteit, de gebruikte uren en de planning voor de komende sprints. Afwijkingen in functionaliteit of uren worden op deze manier goed zichtbaar en zorgen voor waardevolle feedback over het ontwikkelproces voor de klant, de developers en de stakeholders.
De review meeting is het moment om te valideren of Blue Coded en de klant nog op dezelfde golflengte zitten. Mocht dat niet zo zijn, dan bespreken we deze zaken en zorgen we ervoor dat we weer op de zelfde golflengte komen. In de praktijk kan dit betekenen dat er soms wat “wrijving” is in een review meeting, maar de wrijving is nodig om ervoor te zorgen dat we verderop niet botsen. Het is de feedback van het het project naar de klant en het developmentteam (en de input) om te sturen in bijvoorbeeld de planning of de scope.
Feedback uit de reviewmeeting als input voor sturing om op koers te blijven
Focus:
Release naar productie
Na iedere sprint is de software klaar om in productie te nemen. We zien in de praktijk dan ook gebeuren dat er iedere drie weken een release is waarbij er snel rendement is en feedback kan worden verzameld van de eindgebruikers.
Focus:
Planning
Grip op een sprint is belangrijk, maar natuurlijk is het uiteindelijke doel om het hele product of project binnen budget op te leveren. Om dit voor elkaar te krijgen, is het samenstellen van de backlog essentieel. We zien dat dit een belangrijk instrument is om “lange termijn” te plannen en daarin prioriteiten te bepalen.
Focus:
Refinement
Refinement is het bepalen en uitwerken van nieuwe features of aanpassingen op bestaande features.
We zijn natuurlijk niet uniek in het feit dat we hier zien dat de samenwerking van disciplines zorgt voor het beste resultaat. Een samenwerking tussen bijvoorbeeld een domeinexpert en een developer kan ervoor zorgen dat in een hoog tempo wordt gerefined en ideeën in korte tijd worden getoetst, zodat er efficiënt het maximale resultaat, dat past bij het beschikbare budget, uit gehaald kan worden. Door vroegtijdige toetsing kun je voorkomen dat er langere tijd aan een story[5] wordt gewerkt in een oplossingsrichting die suboptimaal is, vanwege bijvoorbeeld interactie of performance.
Onze focus ligt er dan ook op om de refinement zo goed mogelijk te faciliteren. Dat betekent bijvoorbeeld:
- dat we inregelen dat er voldoende tijd is voor de refinement
- dat er beschikking is over de juiste kennis
- dat er beschikking is over de juiste materialen
- dat er beschikking is over, en kennis van, de juiste tooling in het refinement proces (denk dan bijvoorbeeld aan de technieken zoals het schrijven van User stories of Userstory Mapping)
*Voorbeeld van laagdrempelige tooling is het veelvuldig gebruik maken van schetsen, zoals bijvoorbeeld deze schermen en flow
Grove stories
Verder zien we dat, wanneer je de story niet te ver uitwerkt voor de sprint, maar voldoende om deze in te schatten, dat er dan in de sprint ruimte is voor de dialoog die software ontwikkeling kan zijn. Dit voorkomt dat we zaken uitwerken in detail, die later, vanwege nieuwe inzichten, moeten worden aangepast. Of erger nog: dat eventuele nieuwe inzichten niet worden verwerkt in de software.
We gaan hier natuurlijk verantwoordelijk mee om zodat voor de sprint wel een duidelijk commit gegeven kan worden op de sprint en haar verwachte resultaat.
Focus:
Kritisch op de oplossing
Bij het automatiseren van een proces kijken we kritisch naar de gewenste oplossing. De oplossing zal moeten gaan renderen, zal meer moeten gaan opleveren dan de investering, en het liefst zo snel mogelijk. Bij Blue Coded zal je deze drive terugvinden tijdens onder andere het refinementproces, waarin wij kritisch zullen zijn op de oplossing en zullen zoeken naar een manier om zo vroeg mogelijk rendement te krijgen uit de investering in software ontwikkeling.
Een voorbeeld hiervan is de Feedback feature in een SAAS applicatie van 1 van onze klanten. De feature is een manier om feedback te vragen op je functioneren. Op basis van een template kan een organisatie medewerkers de mogelijkheid geven om een feedback formulier in te richten met bijvoorbeeld organisatiebrede vragen, maar ook medewerkerspecifieke vragen.
Om zo vroeg mogelijk rendement te bieden hebben we het mogelijk gemaakt dat deze feature op basis van een default template al door klanten werd gebruikt, terwijl de admin interface om het template te beheren in een latere release is gerealiseerd.
Focus:
Afsluiting
Uiteindelijk is een project een samenwerking tussen opdrachtgever en klant met een gezamelijk doel. Het is belangrijk om daar focus in aan te brengen. Zoals je hebt kunnen lezen doen wij dat specifiek op een aantal zaken.
Samenwerking als de basis voor een succesvol project
Het is onze overtuiging dat het allemaal begint met de samenwerking. Kun je goed samenwerken, dan kun je veel uitdagingen het hoofd bieden. Zo’n samenwerking begint bij een gezamelijk doel, de wil om dit doel te bereiken en wederzijds respect. Dit geldt voor de samenwerking op management niveau, maar is net zo belangrijk op peer-to-peer niveau.
In de samenwerking zul je ook onze focus weer terug vinden zoals:
- Feedback (Om te leren van elkaar)
- Lange termijn succes (Kritisch zijn op de korte termijn voorkomt uitdagingen op de lange termijn)
Samenwerking met Blue Coded
Zoals je misschien al tussen de regels door hebt kunnen lezen zit Agile inmiddels bij ons in het bloed. We passen het toe in al onze development projecten.
Wij zijn ervan overtuigd dat software ontwikkeling een gecontroleerd proces kan zijn waarin grip is op het proces, het product, en het budget terwijl er een natuurlijke ruimte is om in te spelen op verandering. Kom dat ook ervaren als klant in een project van Blue Coded of als organisatie die ondersteuning kan gebruiken in het invoeren/verfijnen van het Agile proces!
Sjoerd is Software Architect bij Blue Coded.
Meer informatie over bovenstaande onderwerpen? Neem contact op met Wouter Olde Weghuis om te horen hoe wij kunnen helpen bij het Agile development proces voor software ontwikkeling. Bel 079 - 330 1600
[1] “Kaizen”: https://nl.wikipedia.org/wiki/Kaizen
[2] “Backlog”: overzicht van de te realiseren features (stories)
[3] “Sprint”: Een tijdsperiode, bijvoorbeeld 3 weken, waarin een afgesproken hoeveelheid werk wordt verricht
[4] “the art of maximizing the amount of work not done”. Onderdeel van “Twelve Principles of Agile Software” https://agilemanifesto.org/principles.html
[5] “Story”: Een beschrijving van een te realiseren feature https://en.wikipedia.org/wiki/User_story