Meer businesswaarde door continu ontwikkelen

Opdrachtgevers zijn bijna altijd erg enthousiast over het product dat een Scrumtraject oplevert; net als over de hechte samenwerking in een team tijdens het traject. Door de constante focus is er snel en met vast budget een bruikbare app of website gerealiseerd. Maar wat gebeurt er met de user stories die door die focus het eindproduct in eerste instantie niet hebben gehaald? En wat als er na de livegang nieuwe inzichten ontstaan die om nieuwe features vragen?

Scrum-pauze-Scrum

Uiteraard kun je altijd een nieuw Scrum project plannen om je website, software of app een stap verder te brengen. Het nadeel van deze Scrum-pauze-Scrum aanpak is echter dat je de lenigheid, de reden waarom je voor een Agile werkwijze als Scrum kiest, eigenlijk voor een groot deel kwijtraakt. Als je in de eindfase van een Scrum project bedenkt dat je extra wensen hebt, realiseer je ze pas in het volgende traject. Dat kan zomaar meer dan een half jaar later zijn. Bovendien kost het iedere keer weer extra moeite om een project op te starten en moet een team telkens weer op elkaar ingespeeld raken.

Continu ontwikkelen

Als een product nog in ontwikkeling is (‘moving target‘) en de uiteindelijke 'feature set' nog niet vaststaat, is een aanpak van continu ontwikkelen beter. Je laat de Scrum projecten elkaar dan direct opvolgen, met iedere keer een nieuwe versie van de software, app of website. Of je denkt alleen nog maar in sprints en zorgt iedere twee, drie weken voor een nieuwe release. Je kunt op die manier niet alleen eerder gebruikmaken van de extra functionaliteiten, het rendement van je investeringen wordt ook hoger.

Minder projectmanagement

Als je met een vast team aan software, een app of website blijft werken, zijn allerlei projectmanagement taken niet meer nodig. Denk bijvoorbeeld aan het maken van een projectvoorstel, offerte en een planning. Of het vinden van een ruimte, kennismakingen en meer. Dit lijken misschien allemaal kleine taken, maar als je deze opstart en afbouw overhead kunt schrappen, levert dit bij elkaar veel extra tijd voor daadwerkelijke ontwikkeling op.

Meer user stories per sprint

Een ander groot voordeel is dat mensen die langer samenwerken steeds beter op elkaar ingespeeld raken. Zeker bij teams waarvan de leden uit meerdere organisaties komen, is dat goed te merken. Het duurt een tijdje voordat iedereen hetzelfde bedoelt met een bepaald woord. Bovendien blijft de energie in een team als je 'dedicated' met een app, website of software bezig blijft. Stop je eerst om later weer te starten, dan moeten mensen er eerst weer even inkomen. Als het je al lukt om dezelfde mensen bij elkaar te vinden.

Businesswaarde centraal

Continu ontwikkelen vraagt van het management wel een andere manier van denken dan de traditionele waarbij met een budget voor één release van tevoren vaste afspraken worden gemaakt over de scope en planning. Bij continu ontwikkelen stel je een budget beschikbaar zonder dat je de precieze invulling van de toekomstige features scherp in beeld hebt. Dit laatste voelt voor beslissers vaak onzeker.

Duidelijke doelen

Daar staat tegenover dat continu ontwikkelen zeker geen carte blanche is voor de product owner en zijn team om er maar wat op los te experimenteren. De product owner moet zorgen voor een duidelijke productvisie waar alle stakeholders achterstaan. Vervolgens is het de taak van de product owner deze visie te vertalen naar een duidelijke roadmap met feature sets en user stories. Hierbij hoort telkens inzichtelijk te zijn hoe de verschillende functionaliteiten bijdragen aan de businesswaarde van het product.

Meten van de voortgang

Als je weet wat de businesswaarde van nieuwe features of user stories moet zijn, kun je vervolgens meten of ze dat in de praktijk ook waarmaken. Dat kan bijvoorbeeld met analytics, multivariate testen of met kwalitatief onderzoek als bijvoorbeeld online surveys of user testing. Het voordeel van continu ontwikkelen is daarbij dat als je merkt dat bepaalde zaken binnen de software, app of website niet of minder bijdragen aan de businesswaarde dan gedacht, je direct kunt bijsturen en niet pas een half jaar later. Dat is lenig en effectief.

Goed gevulde backlog

Continu ontwikkelen heeft uiteraard alleen nut als een team in de sprints voldoende businesswaarde aan een product kan toevoegen. De product owner moet dus een goed gevulde backlog hebben. Deze manier van werken is dan ook vooral geschikt voor apps, websites of software die complexe businessprocessen ondersteunen of bedoeld zijn voor een markt die snel verandert. Dit hoeven overigens geen compleet nieuwe oplossingen te zijn. Iquality heeft een uitgekiend boarding proces om de verdere ontwikkeling van je huidige software, apps of websites lenig en iteratief op te pakken.