Organisaties voelen voortdurend de druk om zich snel aan te passen aan de snel veranderende (economische) omstandigheden. Met name de “vraagzijde” van de organisatie, zijnde de directie, sales en marketing ervaren dit direct. Vaak voelen zij zich niet gesteund door de rest van de organisatie en eventuele leveranciers (aanbodzijde) als aanpassingen gewenst zijn. Zeker geldt dit ook vaak voor de IT-afdelingen en -leveranciers. Verandering wordt door hen meestal als een verstoring van het proces ervaren. Toch zullen vraag en aanbod zich beter in elkaar moeten inleven om samen succesvol te zijn. Wij zijn er van overtuigd dat een meer Agile aanpak hierbij kan helpen.

Recent organiseerde Goyello een kennismiddag voor haar klanten. Graag wilden wij onze klanten laten ervaren wat het effect kan zijn van een op Agile gebaseerde werkwijze. Al weer ruim drie jaar geleden hebben wij tot grote tevredenheid Scrum geïntroduceerd en een toenemend aantal van onze projecten werkt nu conform Scrum. Graag zouden we al onze projecten, inclusief het proces van de klant hierop aan laten sluiten.

Onbekend maakt ook hier echter vaak onbemind.

[slideshare id=13123958&doc=agilesoftwareontwikkelingmetscrum20120523-120529145758-phpapp01]

Te vaak is er sprake van een kloof tussen vraag en aanbod

Nog steeds zien we vaak dat de vraagzijde, de klant, tracht om al zijn eisen en wensen te specificeren. Soms gaan ze hierbij zelfs zo ver dat ze al in oplossingen denken. Op basis van een goed gesprek blijkt echter vaak al snel dat eigenlijk helemaal niet zo duidelijk is wat het ECHTE probleem is en wat er ECHT nodig is om dit probleem op te lossen. In de praktijk denkt echter ook de aanbodzijde, de (interne) leveranciers, vaak direct in oplossingen op basis van de verstrekte specificaties. Een mismatch tussen de echte vraag en het aanbod ligt dan al snel op de loer.

De ontwikkelaars bij de leverancier gaan dan dus maar aan de slag en bouwen wat zij denken dat goed is. Op de traditionele manier wordt hierbij de zogenaamde watervalmethodiek toegepast. Er wordt gerealiseerd in fases wat aanvankelijk gespecificeerd is. Dit proces kan maanden duren, de klant is niet betrokken en ondertussen is de markt al weer verandert. De kans dat de klant krijgt wat hij nodig heeft is dan nihil.

En dan ontstaat worst case een gevecht door de klant die zich niet begrepen voelt en de leverancier die vindt dat hij z’n best heeft gedaan.

Het nadeel van waterval in de praktijk, een praktijk case

Recent bezochten wij een klant, een grote verzekeraar, waar al twee jaar lang gewerkt werd aan het beschrijven van de werkprocessen van een complex klantproces. De vraagzijde had inmiddels geen vertrouwen meer in deze analyse, want de businesswerkelijkheid zou inmiddels al weer voor minimaal 40% gewijzigd zijn. Ondertussen had de IT-leverancier de procesanalyses al wel gebruikt om een systeem te ontwikkelen. Een systeem dat dus maar voor een zeer klein deel aan de wensen van vandaag voldoet. En de klant had tot overmaat van ramp dit systeem nog nooit gezien. De leverancier wilde het systeem op basis van de aangepaste procesanalyses gaan herbouwen. Maar dat leek ons niet zo’n goed idee.

We hebben voorgesteld het vervolg van het proces interactief en middels iteraties aan te lopen door de business gewoonweg de huidige versie te laten zien en te evalueren wat goed is, wat moet worden aangepast en wat echt ontbreekt. Aansluitend kan dan een roadmap worden gemaakt met alle nog te ontwikkelen functionaliteit. De nog te realiseren functionaliteit kan worden verdeeld over maandelijkse releases, die dan weer aan de klant worden getoond. Ook zal de klant aan het begin van een release nauw betrokken worden bij de definitie van te ontwikkelen functionaliteit, om te zorgen dat ze echt krijgen wat ze nodig hebben.

De leverancier vond dit aanvankelijk een moeilijke stap. Die was bang om zich bloot te geven. Het is gelukkig toch gelukt om hen te overtuigen. Een project wat helemaal vast zat en waar het wederzijdse vertrouwen weg was, lijkt inmiddels weer goed op de rit.

10 indicatoren dat een project dreigt te mislukken

Hoe kun je een dergelijke situatie als hierboven nu voorkomen? Kun je dit zien aankomen? Ja, dat kan. En vreemd genoeg is het eigenlijk best wel eenvoudig om te voorspellen dat een software-ontwikkelproject dreigt te mislukken. John S. Reel beschrijft in “Critical Succes Factors In Software Projects” de 10 signalen waaruit je kunt opmaken dat een project zomaar kan mislukken:

1. Het projectteam begrijpt de gebruikersbehoefte niet
2. De project scope beschrijving is zeer beperkt (of ontbreekt)
3. Slecht management van wijzigingen
4. Tussentijdse wijziging van de verkozen technologie
5. Veranderende businessbehoeftes
6. Onrealistische deadlines
7. Weerstand bij gebruikers
8. Ontbreken van een duidelijke projectsponsor
9. Projecteam mist juiste kwalificaties
10. Managers negeren best practices en leren niet van verleden.

Bovenstaande punten zijn in principe stuk voor stuk eenvoudig op te lossen.

Samenwerken levert een beter resultaat op

Agile betekent flexibiliteit en lenigheid en dat is feitelijk wat we nodig hebben. Vandaag de dag zijn strakke plannen vaak niet zinvol. Een meer Agile aanpak lijkt een betere werkwijze. En daarmee is het ook meteen een nieuwe “hype” of “trend” geworden. In toenemende mate duikt de term op als de Heilige Graal, de oplossing voor alle problemen. En datzelfde geldt dan voor Agile methodes als Scrum.

De werkelijkheid is echter iets weerbarstiger. Deze methodes implementeren, zonder ze echt te begrijpen, zonder de onderliggende filosofie te voelen, zal niet lukken. Dan verwordt het tot een nieuwe tool, waarvan de implementatie gedoemd is te mislukken.

Wij zien regelmatig IT-afdelingen Scrum introduceren. En na enig doorvragen blijkt dat er bijvoorbeeld helemaal geen product owner is, de vertegenwoordiger van de klantvraag aan de klantzijde. De implementatie heeft dan dus geïsoleerd binnen de IT-afdeling plaatsgevonden en geloof me, dat wordt geen succes.

Van onder tot boven, door de hele organisatie heen, moet begrepen worden, liefst gevoeld en beleefd worden, wat Agile werken inhoudt.

De basisgedachte achter Agile vereist vertrouwen

Jaren geleden is het zogenaamde Agile Manifesto opgesteld. Dit manifesto verwoord in slechts 4 hoofdpunten waar het precies om draait:

• Mensen en hun onderlinge interactie boven processen and tools
• Werkende software boven allesomvattende documentatie
• Samenwerking met de klant boven contractonderhandelingen
• Inspelen op verandering boven het volgen van een plan

Het is daarbij niet zo dat de rechterkant niet belangrijk is, maar de linkerkant is gewoonweg belangrijker als je effectjef wilt samenwerken.

Om zover te komen is onderling vertrouwen tussen vraag en aanbod nodig. De klant wil namelijk bijvoorbeeld wel graag weten wat iets gaat kosten. En dat is met een Agile werkwijze dus niet exact af te dekken. Binnen Scrum bijvoorbeeld is de deadline heilig, kan het budget gelimiteerd worden, maar is vooraf niet volledig te garanderen wat er exact opgeleverd zal worden. De kans dat een werkend product wordt opgeleverd, dat voldoet aan (gewijzigde) wensen neemt echter significant toe.

Scrum om stap voor stap samen een werkend product te realiseren

Zoals eerder gemeld hebben wij Scrum verkozen om ons werk te organiseren. Scrum is er op gericht om complexe projecten (niet alleen software-ontwikkeling) gerealiseerd te krijgen. Het werk wordt binnen Scrum gerealiseerd in iteraties, zogenaamde sprints, van 2-4 weken. Aan het begin van iedere sprint wordt een pakket van werkzaamheden vastgesteld op basis van een (al eerder) samen met de klant geprioriteerde lijst van eisen en wensen, de zogenaamde user stories. De functionaliteit die als eerste wordt ontwikkeld heeft dus de hoogste waarde voor de klant. Aan het eind van iedere sprint dient een werkend product opgeleverd te worden.

De klant is nauw betrokken bij het vertalen van eisen en wensen in zogenaamde user stories. Een user story vertelt wat een gebruiker onder bepaalde condities moet kunnen doen met het systeem en wat daarvan het resultaat is. Deze user stories kunnen door het team begroot worden. Bij voorkeur is dit een begroting op basis van story points. Middels het zogenaamde story points poker wordt met elkaar de complexiteit bepaald.

Er wordt dus door het team niet aangegeven hoeveel tijd de realisatie van een user story kost. Gedurende het project wordt wel het gemiddelde werktempo duidelijk en kan het gemiddelde aantal uren per story point worden bepaald, waardoor het proces steeds voorspelbaarder wordt.

Essentiele rollen binnen dit proces zijn:

1. Product owner: dit is de vertegenwoordiger van de vraagzijde. Dit is iemand die zelfstandig kan beslissen als het team vragen stelt over de te realiseren user story. Hij dient dus over veel domeinkennis te beschikken en snel toegang te hebben tot relevante stakeholders.
2. Scrum master: dit is de facilitator van het teamproces. Dagelijks houdt de scrum master samen met het team een zogenaamde standup meeting, in principe staat men ook, om te bespreken 1) Wat iemand gisteren heeft gedaan, 2) Wat hij vandaag gaat doen en 3) Wat hem eventueel blokkeert. De scrum master heeft als taak om alle blokkades z.s.m. op te lossen, zodat het team gewoon door kan werken.
3. Team members: Binnen Scrum verdeelt het team geheel zelfstandig het werk. Alle verantwoordelijkheid voor het realiseren van het afgesproken werk voor een sprint ligt bij het team. Onderling stemmen zij af wie wat zal doen en helpen ze elkaar.

Het bovenstaande is een ruwe samenvatting van mijn presentatie. Deze dekt zoals zo vaak maar het topje van de ijsberg af. Over de implementatie van Agile werken en een methode als Scrum valt nog veel meer te zeggen/schrijven. Doen is echter nog altijd het beste. Omdat Agile het omarmen van verandering betekent, is de beste manier om te beginnen het gewoon doen. Pas de werkwijze gerust continue aan, want verandering is nu eenmaal de regel. Het voornaamst is dat de aanpak door de hele organisatie wordt gedragen, want als dat niet het geval is, dan is Scrum opnieuw niet meer dan een tool, die z’n kracht niet zal tonen.

Wat zijn jouw ervaringen met Scrum? Of zou je wel graag volgens Scrum willen werken en twijfel je nog? Heb je vragen? Deel je gedachten gerust hieronder!