Agile Delivery voor niet-IT projecten

Hoe kun je Agile en Scrum implementeren binnen jouw organisatie? Hoe creëer je draagvlak en ontdek je de voordelen van Agile werken? 

De eerste praktische vraag is hoe weet je of een project überhaupt geschikt is om Agile uit te voeren? Bijvoorbeeld eenvoudige projecten kun je beter niet met de Agile methode uitvoeren. Met het Agile Readiness Assessments (ARA) kun je met vier parameters beoordelen of een project de complexiteit bezit, die Agile werken vereist.
1. Hoe goed kennen de stakeholders hun eisen?
2. Kennen de stakeholders de technologie?
3. Zijn er tegenstrijdige belangen tussen de verschillende stakeholders?
4. Is er een hoge kans op mislukking?

Een meerderheid van de strategie, productontwikkeling en verander projecten zal worden beoordeeld met hoge risico’s op al deze vier punten. Dit vereist bijna altijd een hoge zichtbaarheid, vroegtijdige risicobeperking, voortdurend aanpassingsvermogen en inzicht in de ROI. Hierbij is het gebruik van het Agile gedachtegoed of de Scrum methode, zeer waardevol. Misschien is de meerwaarde van Agile voor ‘normale’ projecten nog wel groter als voor ICT projecten.

De volgende vraag is: “Hoe pak je dit aan?”
Het is belangrijk om je te realiseren dat het Agile manifest een verklaring is van utopische idealen. Alle praktische tools die hieruit voort zijn gekomen, zoals Scrum en Kanban, zijn geen doel maar middel. Het belangrijkste is dat mensen, teams en de organisatie, de ruimte hebben om flexibel te opereren.

Om non-software projecten met behulp van Agile succesvol uit te voeren is een vijf punten agenda gedefinieerd. Deze agenda helpt om duidelijke verwachtingen met stakeholders te creëren en draagvlak voor de voordelen van Agile werken. Hoewel deze agenda vergelijkbaar is met de principes gevolgd bij de uitvoer van een Agile IT project, is de praktijk bij de uitvoering van niet-software projecten, anders.

1. Definieer ‘Werkende product’
   Datgene er wordt afgeleverd waarmee waarde voor de klant wordt gecreëerd. Dit kan gaan om een verbetering van de roadmap, een architectuur prototype, een strategisch document of een kosten-baten analyse.
2. Definieer ‘Klant’
   Bij niet-software projecten kan het identificeren van de klanten, lastig zijn. Stakeholders kunnen directe of indirecte belangen hebben in het initiatief. In tegenstelling tot de eindgebruikers van een systeem, kunnen stakeholders tegenstrijdige prioriteiten, interne vooroordelen of vooroordelen hebben. Bovendien zijn veel van deze stakeholders van het senior management of C-level executives, dat maakt deze taak nog moeilijker. Het kiezen van de ‘juiste’ Product Owner, die kan in toom te houden deze complexiteit, is cruciaal.
3. Definieer ‘Done’
   Voor elk oplever-moment moet de product eigenaar vaststellen wanneer iets klaar ‘done’ is. Bij gebrek aan een formele kwaliteitsborging, is het belangrijk de omstandigheden van succes bepalen. Het kan zijn dat de stakeholders de goedkeuring uitstellen totdat het te leveren product met succes wordt gebruikt in een toekomstige ontwikkelingsproject. Hiervoor moet je waken omdat je hiermee fout op fout kunt gaan stapelen.
4. Meetbaar maken ‘Business Value’
   Het meten van de Business Value is essentieel voor elk project. Het product dat je na een iteratie oplevert bestaat veelal uit een document of prototype. Daarom is het belangrijk om te starten met het maken van een business case. De wijze waarop je de resultaten monitort moet worden vastgelegd en worden geïnstitutionaliseerd. Zo kun je kiezen voor meetwaarden zoals Total Cost of Ownership (TCO), de kostenbesparing of een due diligence-onderzoek.
5. Verwacht het onverwachte
   Strategie of consulting projecten zijn berucht om hun veranderlijkheid. Dit is normaal omdat de sponsors en het management steeds in de brainstorm modus blijven staan. Project scope, doelstelling en doelen zijn onderhevig aan vaak en drastisch veranderingen. Kies daarom voor kortere iteraties, gezamenlijke workshops, paired development, continue deskundige en peer reviews, overweeg de inzet van senior consultants en een goede socialisatie van de theorieën en ideeën.

Zodra de agenda is vastgesteld, kun je jouw project gaan uitvoeren met behulp van Scrum of een andere methode gebaseerd op het Agile gedachtegoed. Het is opvallend hoe perfect je standaard agile technieken zoals pair-programmering en test-driven development, relevant zijn voor niet-software projecten. Met de bovenstaande 5 punten agenda kun je eenvoudig verschillende soorten non-software projecten succesvol realiseren. Denk hierbij aan het opstellen van een strategie, het bouwen van een startup bedrijfsstructuur, het optimaliseren van bedrijfsprocessen en de ontwikkeling van nieuwe producten en concepten.

Conclusie
Binnen een multidisciplinair kader is Agile zeer effectief. Agile werken en opleveren is absoluut noodzakelijk voor niet-software projecten als gevolg van intrinsieke risico’s en complexiteit. Modellen kunnen variëren, maar de concepten van Agile niet. In plaats van het strikt uitvoeren van voorgeschreven Agile methodieken, is het zaak om vooral het gedachtegoed van het Agile manifest, te omarmen.

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

ACTUEEL: lees meer over de Scrum training op 26 en 27 januari 2017.

Vertaling en bewerking door Frismakers Company. Het bronartikel werd in 2015 gepubliceerd op InfoQ door Dipanjan Munshi, senior process and quality consultant at Tata Consultancy Services (TCS) met een Masters Degree in Computer Applications from Utkal University, Orissa, India.