Fish on Fire ontvangt dagelijks aanvragen om apps te ontwikkelen. Hierbij zijn vragen zoals kosten en tijdsduur belangrijke elementen die iedereen zo snel mogelijk wilt weten. Om een juiste inschatting te geven over het benodigde budget en de tijd dat nodig is voor de ontwikkeling van de app, is het belangrijk dat er duidelijkheid is over de scope (omvang) van het project.
In veel gevallen ligt de scope bij de aanvraag helaas nog niet vast. Als oplossing voor dit probleem biedt Fish on Fire de mogelijkheid om projecten via de Agile werkwijze uit te voeren. Hierbij wordt de focus gelegd op 1 variabele. Dit kan Fixed budget, Fixed Time of Fixed Scope zijn.
Voordat Fish on Fire advies kan geven welke variabele het beste bij de aanvraag past, is het belangrijk om de aanvraag inzichtelijk te maken. De eerste stap is om onderscheid te maken tussen cruciale en minder cruciale functionaliteiten. Op deze wijze is voor het hele projectteam inzichtelijk hoe de prioriteiten zijn gesteld.
Om de prioriteiten inzichtelijk te maken wordt veelal de MoSCoW – methode toegepast. De functionaliteiten worden onderverdeeld in (M)ust haves, (S)hould haves, (C)ould haves en (W)on’t of (W)ould haves. Door het toekennen van deze prioriteiten wordt inzicht verkregen in de scope van het project waarbij het realiseren van het project een stap dichterbij is gekomen.
Wanneer inzicht is verkregen in de meest cruciale functionaliteiten (M), is de volgende stap om te bepalen welk van de drie variabele, “Budget, Scope of Time” kan worden geadviseerd aan de klant. In voorgaande gesprekken met de klant is duidelijk geworden waar de focus naartoe gaat. Voor de ene klant is dit budget, maar voor de andere is dit tijd.
Het is belangrijk om aan te geven, wanneer ontwikkeling op basis van een Agile aanpak wordt uitgevoerd, het alleen mogelijk is om één van deze drie variabelen vast te zetten (fixed). De andere twee variabelen moeten flexibel blijven. Wanneer de klant alle drie de variabelen vast wilt zetten kan er geen sprake meer zijn van een Agile werkwijze. Hierdoor is het pas mogelijk om een realistische inschatting op te stellen wanneer de designs en het functioneel ontwerp vast staan.
Fixed budget
Wanneer de focus ligt op een fixed budget betekent dit dat we werken met een vooraf vastgesteld budget. Als projectgroep houden wij ons aan het vastgestelde budget en is het noodzaak om continue functionaliteiten te prioriteren. Het projectteam moet continue de afweging maken tussen (M)ust haves vs. (S)hould haves, (C)ould haves en (W)on’t / (W)ould haves, omdat een fixed budget de grens bepaald wat binnen budget kan worden ontwikkeld. De ontwikkeling van functionaliteiten worden in sprints ingedeeld. Na elke sprint is er een evaluatie zodat inzicht kan worden gegeven in de ontwikkelende functionaliteiten, het nog openstaande budget en de functionaliteiten die op volgorde van prioriteiten staan ingedeeld voor de komende sprints. In overleg zal worden besloten welke volgende stap wordt ondernomen wanneer het volledige budget is gebruikt.
Een grote misvatting is dat veel mensen fixed budget en fixed price als het zelfde zien. In werkelijkheid is er een groot verschil. Fixed price houdt namelijk in dat bij de ontwikkeling van een applicatie vooraf de prijs, de scope en de tijd vaststaat. In een agile werkwijze is dit niet mogelijk, omdat de agile werkwijze ervoor zorgt dat na elke sprint de functionaliteiten, die in deze sprint zijn ontwikkeld, worden getoond, getest, en wordt beoordeeld. Hierdoor worden risico’s tijdens de ontwikkeling beperkt en weet de projectgroep al snel of ze op de goede weg zitten. Daarnaast zie je na elke sprint de verdere ontwikkeling van de applicatie. Dit stimuleert nieuwe ideeën tijdens de ontwikkeling. Op deze manier is het mogelijk om opnieuw naar de prioriteiten van de functionaliteiten te kijken en te bepalen wat er in de volgende sprint moet worden ontwikkeld. Wanneer vooraf de prijs, scope en deadline van oplevering wordt vastlegt zal er geen ruimte meer zijn voor aanpassingen van de scope.
Fixed time
Wanneer wordt gekozen voor fixed time bij het begin van het project, betekent dit dat de ontwikkeling van de applicatie afhangt van de beschikbare tijd waarin kan worden ontwikkeld. De projectgroep bepaald op basis van prioriteit (M) welke functionaliteiten in de daarvoor bestemde sprint worden ontwikkeld. Bij fixed time moet zowel de scope als het budget flexibel zijn. De beschikbare tijd zal centraal staan in de keuzes voor de functionaliteiten die zullen worden ontwikkeld en welke worden uitgesloten van dit project.
Fixed scope
Bij de keuze voor fixed scope ligt voor de aanvang van het project de scope van het project vast. Functionaliteiten zijn door de projectgroep bijvoorbeeld uitgewerkt in user stories, zodat voor alle betrokkenen inzichtelijk is op welke wijze de functionaliteiten worden ontwikkeld. De scope neemt in alle drie de opties (Budget, Time, Scope) een belangrijke plek in. De klant wil altijd weten hoeveel er moet worden betaald voor de vastgelegde scope. Het vastzetten van de scope en het budget beperkt het projectteam om tijdens de ontwikkeling de functionaliteiten te beoordelen. Daarnaast is er weinig ruimte om nieuwe ideeën te bedenken, om verbeteringen door te voeren die de kwaliteit van de applicatie kunnen verbeteren. De beoordeling van de functionaliteiten zal pas na de oplevering van de applicatie in samenspraak met de klant worden opgepakt.
Een succesvolle samenwerking
Wanneer een contract wordt opgesteld met jou als klant, is het belangrijk dat er vertrouwen is tussen alle betrokken partijen (projectgroep). Een contract dat agile is opgesteld biedt handvatten om het vertrouwen tussen de betrokken partijen verder uit te bouwen.
Als app ontwikkelaar willen wij waarde creëren voor jou als klant. Om waarde te creëren wordt eerst aandacht besteed aan het ontwikkelen van de meest waardevolle functies, die met behulp van de MoSCoW methode zijn opgesteld. In gesprek met jou als klant, wordt duidelijk welke van de drie variabele (Budget, Time, Scope) het best past binnen het project. Door de transparante werkwijze wordt de juiste perceptie bij de betrokken partijen gecreëerd. Hierdoor is een goede basis gelegd voor een succesvol project, waarbij de klant met vertrouwen de samenwerking aan kan gaan.
