In 7 stappen naar een tijdige oplevering

Valkuil binnen de Agile werkwijze is de gedachte “de klant weet precies wat hij wil” en dat verfijnen we wel gedurende het Agile proces, vaak met de product owner. Patrick: “In grote lijnen is dat zo, maar er is ook voortschrijdend inzicht. Zo groeit het aantal sprints en schuift de einddatum naar achteren. Soms wordt het Agile proces daarbij belangrijker dan de te behalen doelstelling en de tijdige levering.” Deze whitepaper gaat dieper in op de 7 stappen waardoor de voordelen van Agile werken worden benut en het project op de afgesproken datum opgeleverd wordt.

Stap 1: Zorg voor goede kwaliteitsborging

Een Agile en tijdig geleverd project begint natuurlijk met het leveren van een kwalitatief goed product. Op tijd een product leveren dat niet voldoet aan de kwaliteitsverwachting, zorgt naast ontevreden eindgebruikers voor software die uiteindelijk niet in productie gaat en rework. Dit vertraagt het hele project. Kwaliteit heeft drie aspecten: de subjectieve perceptie van kwaliteit, de meetbare dimensie en de security.

Voor de subjectieve perceptie van kwaliteit voorziet Agile werken via demo’s in het stroomlijnen van de (kwaliteits)verwachting van de gebruikers. Patrick: “Demo’s laten aan gebruikers zien wat er in de afgelopen sprint gerealiseerd is. Maar dat blijft toch een momentopname. Stel de functionaliteit gewoon open voor gebruikers in een demoomgeving en laat hen de software uitproberen, waardoor het gevoel van kwaliteit groeit.”

Voor de objectieve kant van kwaliteit zijn de productkwaliteitsitems van ISO25010 (https://nl.wikipedia.org/wiki/ISO_25010) een mooi uitgangspunt. Tooling als Tiobe en Visual Studio on-line helpen ook om kwaliteit transparant te maken.

Het derde kwaliteitselement is de veiligheid. Security-eisen worden steeds strenger. Toets daarom gedurende de ontwikkeling van de software al tegen de meest recente security bedreigingen, zodat de geleverde software voldoet aan de recente veiligheidseisen. 

Stap 2: Maak voortgang objectief inzichtelijk en transparant

Storypoints is in een standaard Agile manier om de omvang van werk uit te drukken. Het Agile team geeft de hoeveelheid werk aan ten opzichte van het referentie-item, vaak via pokersessies. Een backlogitem dat bijvoorbeeld twee keer zoveel werk is als het referentie item, krijgt dan twee storypoints. Op basis van de velocity uit het verleden, bepaalt het team wat er in de komende sprint past.

Een belangrijk voordeel van deze manier van werken, is het commitment binnen het team. Een belangrijk nadeel is dat de omvang van de sprint pas na een sessie met het team bekend wordt. Dan is de sprintomvang duidelijk, maar niet de omvang van het totale project. Bovendien is deze omvang-indicator subjectief doordat teamleden bij het inschatten vooral gebruik maken van hun recente ervaringen. Een team dat in een positieve flow zit, schat werk anders in dan een team dat te kampen heeft met tegenvallers.

Vanuit een projectperspectief is er behoefte aan een objectieve en eenvoudige eenheid voor de omvang, zodat al vroeg de totale backlog omvang van het project helder is. Een bruikbare maatstaf hiervoor zijn functiepunten. FPA-i (Functiepunt Analyse - indicatieve telling) is een genormeerde telmethode waarmee eenvoudig en snel de totale omvang van een backlog wordt bepaald. 

Stap 3: Definieer vooraf goede DoR en DoD

Om maximaal effect uit een team te halen, is het noodzakelijk dat het zelfstandig kan werken. Heldere definities over starten en finishen creëert die ruimte voor het team. Door duidelijk te maken waaraan werk moet voldoen om te kunnen starten (Definition of Ready), verliest het team tijdens de sprint geen tijd aan zaken als het duidelijk krijgen van requirements.

Een goede Definition of Ready voldoet aan deze criteria:

• De userstory is uitgewerkt volgens het ontwerp format

• Het aantal functiepunten van de user story is bekend

• De impact op het datamodel is bekend

• Een tester heeft aangegeven dat de functionaliteit SMART genoeg is om te testen

• Een architect heeft aangegeven dat de functionaliteit “bouwbaar” is

• De product owner is akkoord met de inhoud

Hetzelfde geldt uiteraard voor het eindcriterium: wanneer is werk klaar en wanneer voldoet het aan de Definition of Done. 

Stap 4: Borg juiste competenties en werkhouding in het team

Een goed proces is belangrijk voor tijdige levering van een project, maar nog belangrijker zijn goede mensen. Besteed voldoende aandacht aan de juiste opbouw van competenties en cultuur in een team en start niet voordat het juiste team er is. Minimale rollen in een Agile team zijn een product owner, business analist, solution architect, lead developer, developer(s), scrummaster en een tester. De projectmanager is geen onderdeel van het Agile team. Hij/zij stuurt zeker geen teams aan maar bewaakt het totale project op basis van de voortgang.

In het team is gemeenschappelijk gevoeld commitment voor zowel de sprint als het totale project cruciaal. Zo is ook de stap naar verantwoordelijkheid nemen en daarop aangesproken worden voor iedereen duidelijk.

Stap 5: Houd het doel scherp voor ogen

Een valkuil van ieder Agile project is voortschrijdend inzicht, ook wel “scope creep” genoemd. Binnen Agile projecten manifesteert zich dit door een oneindig aantal sprints. De theorie van Agile schrijft voor dat een product owner continue zorgt voor maximale business waarde bij elke sprint. Waarbij elke sprint ook in productie wordt genomen. Helaas is dat niet altijd realiteit. Een te klein ‘minimal viable product’ kan net zo veel schade berokkenen als een te groot ‘minimal viable product’. Maak dus expliciet wat het project precies bereikt, bij voorkeur met de business case en bij alle stakeholders van het project. De kick-off is hier een goed moment voor. Gedurende het project kan ‘scope creep’ voorkomen worden door iedereen te focussen op het projectdoel en daar met elkaar kritisch op te blijven.

Stap 6: Zorg voor een effectief releaseproces

Software heeft alleen waarde als de oplossing in productie staat. Een goed releaseproces brengt de ontwikkelde software snel in productie, zonder afbreuk te doen aan de kwaliteit. Dit klinkt simpel, maar is in de praktijk lastig. Zet een project vanaf de start goed op; dit vergemakkelijkt een geautomatiseerde uitrol. Randvoorwaarde is dan wel dat er een geautomatiseerde OTAP straat is.

Stap 7: Manage risico’s actief

Geen enkel project staat op zichzelf en geen enkel team kan volledig zelfstandig een product opleveren. In de omgeving van het Agile project ontstaan allerlei risico’s, die zich vertalen naar impediments in de sprint. Zeker in complexe omgevingen zijn deze impediments vaak niet snel op te lossen. Focus actief op het vermijden van risico’s in het project, nog voordat ze optreden.

Deze 7 stappen helpen om Agile projecten op tijd en met de juiste kwaliteit op te leveren. Het is echter geen magisch recept wat overal en altijd werkt. Door met common sense bovenstaande stappen toe te passen op de eigen omgeving, worden er stappen gezet richting voorspelbaarheid en betrouwbaarheid. Die laatste twee zijn nodig om ook tijdig te kunnen leveren. Vervolgens blijft het natuurlijk belangrijk om het toegepaste te evalueren en aan te passen.