Deliver value incrementally

Dit is een post in de serie over sneller betere software deliveren volgens 5 principes gebaseerd op mijn eigen ervaringen. Kijk hier voor de introductie en een overzicht van de 5 principes. Vandaag gaan we in op principe 2: deliver value incrementally.

In de post over de focus op value beschreef ik een initiatief als:

Een initiatief is de verandering van de value van niveau x naar niveau y in minder dan een voorafbepaalde maximale effort.

In deze post gaan we het hebben over waarom je zoveel sneller betere software maakt als je waarde y in stapjes opbouwt in plaats van in één big bang.

Een standaard practice in heel veel bedrijven is om, wanneer een initiatief concreet wordt, een project op te starten. Bij zo’n project wordt de maximale effort omgezet in een budget en een deadline. De doelstelling van het project wordt vanaf dat moment om niveau y te bereiken op de deadline en binnen het budget. Jammer genoeg interpreteren de meeste projecten dit als: vóór de deadline leveren we géén waarde en óp de deadline springen we in 1 klap naar niveau y.

Vanop een afstandje gezien lijkt dit ook logisch. We moeten nieuwe software bouwen. We moeten die software testen en daarna naar productie brengen. Pas op productie kan die software waarde leveren. Een big bang is dus een natuurlijk scenario.

Maar wat als we dat natuurlijke scenario omgooien? Wat als we gedurende het project niet 1 keer naar productie gaan, maar heel vaak naar productie gaan? In stapjes naar waarde y gaan brengt een aantal technische en proces uitdagingen met zich mee. Maar het levert ook veel voordelen op.

Verlaagd risico door continue integratie

Elk groot IT-project bevat verschillende stukken software waaraan veranderingen moeten plaatsvinden. In de meeste klassieke projecten worden aan de start van het project integratieafspraken gemaakt. API’s worden vastgelegd, file formaten worden afgesproken, timings worden beslist en zoveel meer. Aan het einde van een klassiek project is er dan de integratiefase waar alles samenkomt. Vaak blijkt op dat moment dat het samenwerken van alle stukken software toch moeilijker is dan gedacht. Inherent zijn tientallen kleine veronderstellingen gemaakt die in de praktijk niet blijken te kloppen. Op dat moment moeten allerlei integratieaanpassingen worden gedaan die mogelijk diepe impact kunnen hebben op het werk dat in de afgelopen maanden is gebeurd.

Deze ervaring leidt ertoe dat bij volgende projecten een langere upfront design fase wordt ingebouwd. Daar wordt langer en dieper gediscussieerd over alle integraties in de hoop de problemen in de integratiefase te vermijden. Dit kán werken. Maar een lange upfront design fase is nefast voor de wendbaarheid. Bij elke verandering gedurende het project moet immers de impact op al die upfront beslissing opnieuw geëvalueerd worden.

Gelukkig is er ook een andere oplossing. Wanneer je incrementeel waarde probeert op te leveren moeten alle betrokken stukken software heel regelmatig naar productie. Dus moeten ze de hele tijd met elkaar geïntegreerd worden. We doen de integratie niet als een fase aan het einde van het project, maar verdelen het werk over elke stap. Daardoor is het upfront design beperkt tot de inhoud van deze stap. Ook de mogelijke misverstanden, die nog steeds voorkomen, hebben een veel kleinere impact op de software. Dat leidt tot veel minder rework.

Continu integreren is trouwens een mooi voorbeeld van een bekend Agile principe: when it’s hard, do it often.

Verhoogde wendbaarheid

Een tweede groot voordeel is dat incrementeel waarde opleveren veel vroeger voor validatie zorgt. Na de eerste paar opleveringen kan je in productie zien of de features die je bedacht hebt ook werkelijk de waarde leveren die je voor ogen had.

Heel vaak blijkt dat niet helemaal het geval te zijn. De klanten gebruiken de features net anders dan jij ze had bedoeld. Met deze vroegere feedback van klanten kan je bestaande features aanpassen, maar vooral nog niet gebouwde features van een andere prioriteit voorzien of nieuwe functionaliteiten bedenken.

Als je daarenboven heel consequent de bouwvolgorde laat bepalen door de features die de meeste value opleveren voor de minste effort, dan maak je zelfs kans dat je de beoogde value ruim binnen de maximaal toegelaten effort bereikt.

Te allen tijde kunnen stoppen

In sommige gevallen helpt zelfs bovenstaande wendbaarheid niet om de beoogde value te bereiken. De bedachte oplossing is niet goed genoeg. Of klanten hebben er niet het verwachte geld voor over.

In dat geval heeft incrementeel werken een bijkomend voordeel. Je hebt niet enkel de vervroegde validatie die ertoe leidt dat je veel vroeger in het project weet dat het geen goed idee is om nog meer tijd, geld en energie in dit initiatief te steken. Je hebt daarnaast de kans om er aan het einde van elke stap mee te stoppen en de waarde in productie te behouden. Er staat immers werkende software in productie. Zo bespaar je niet enkel op de effort die nog gedaan zou worden, maar bereik je nog gedeeltelijke value op basis van de effort die je al gedaan hebt.

Vroeger waarde = extra waarde

Bovenstaande 3 redenen zijn volgens mij de meest fundamentele redenen om waarde incrementeel op te leveren. Maar er is nog een leuke extra.

Wanneer je incrementeel van niveau x naar niveau y gaat, wordt vrij snel na de start van het project al eerste waarde opgeleverd. Wanneer het om financiële waarde gaat kan dit geld dienst doen om volgende stappen in het project te financieren. Voor heel grote bedrijven is dit waarschijnlijk minder van belang. Maar voor start-ups en andere kleine bedrijven kan dit het verschil betekenen tussen stoppen of kunnen doorzetten met een initiatief.

Was deze post iets voor jou? Dan is de volgende in deze reeks dat misschien ook: Work in autonomous cross-functional teams of great people