Organisaties merken steeds vaker dat hun oude IT-systemen een belemmering vormen voor innovatie. Om aan de veranderende wensen van klanten te voldoen, is het belangrijk dat ze zich snel kunnen aanpassen en innoveren. Elke organisatie die met de beste beschikbare nieuwe technologie wil werken, staat daarom voor een moeilijke uitdaging. Hoe test je welke technologie waardevol is?

Op het gebied van IT worden organisaties vaak geconfronteerd met een dilemma; terwijl de systemen die zijn gebaseerd op oude technologie zorgen voor lange ontwikkeltijden, vereist de overgang naar nieuwe oplossingen een investering. Daarom moet een organisatie eerst de grootste knelpunten in het huidige IT-landschap identificeren. Meer dan eens zullen deze niet alleen IT-gerelateerd zijn, maar ook de business (processen) betrekken.

Een Proof of Concept (PoC) kan binnen enkele weken aantonen hoe moderne technologie de knelpunten van organisaties wegneemt en (vaak) werk reduceert. Het is een kans voor de hele organisatie – inclusief het bedrijfsleven en IT – om te ervaren hoe het is om met nieuwe technologie te werken voordat er een uiteindelijke beslissing genomen moet worden. Als gevolg hiervan zal de nieuwe technologie logischer en aangenamer zijn om mee te werken. Na goedkeuring kan de oude technologie in kleine stappen worden afgebouwd.

 Wat is een Proof of Concept?

Organisaties kunnen een PoC gebruiken om een ​​tijdrovend selectieproces met maandenlange doorlooptijden te verkorten. Door in korte tijd met nieuwe technologie te experimenteren, zijn concrete resultaten direct zichtbaar. Ook maakt de organisatie kennis met de voordelen van een nieuwe werkwijze, wat het interne draagvlak vergroot.

Drie aspecten zijn cruciaal om te bepalen of nieuwe technologie bij de organisatie past:

  1. Functionaliteit: Waarvoor wordt het nieuwe platform uiteindelijk ingezet? Komen de functionaliteiten overeen met de business- en klantwens?
  2. IT-architectuur: Past het nieuwe platform binnen het bestaande IT-landschap en de Cloud-omgeving? Heeft het genoeg mogelijkheden, zoals security en schaalbaarheid?
  3. Werkbaarheid: Is het platform voor een ontwikkelaar fijn om in of mee te werken? Dwingt de technologie de digitale transformatie af zodat business profiteert?  Wordt de organisatie wendbaarder en ondersteunt het een Agile-werkwijze en DevOps?

Op basis van deze drie aspecten wordt er door de organisatie een lijst met ‘epics’ opgesteld. Het is gebruikelijk om deze te formuleren vanuit de huidige pijnpunten. Zo wordt voorkomen dat een organisatie bijvoorbeeld problemen ervaart met bepaalde rekenregels of een systeem de huidige bulk/aantallen niet goed aankan. Door middel van een PoC kan het nieuwe platform zich bewijzen op deze punten.

Een fulltime dedicated team wordt als volgt opgebouwd:

Wanneer organisaties advies aan de slag gaan met PoC’s, is het het beste om het ontwikkelingsproces op de meest realistische manier te implementeren. Dit geeft de organisatie een duidelijk beeld van de technologie.

Een fulltime toegewijd team is als volgt opgebouwd:

  • Een Scrum-meester die het PoC-team faciliteert.
  • Ervaren ontwikkelaars voor productontwikkeling, die ook zullen dienen als trainers voor onervaren ontwikkelaars.
  • Enkele enthousiaste ontwikkelaars (eigen organisatie) voor productontwikkeling, die kennis kunnen opdoen die binnen de organisatie is opgedaan.

Optioneel:

  • Een producteigenaar voor productkwalificatie, die ook gebruikersverhalen kan schrijven en testen.

Als er binnen het bedrijf nog weinig kennis aanwezig is over het desbetreffende platform, dan wordt er eerst een passende bootcamp georganiseerd. Op die manier heeft iedereen voldoende basiskennis om vanaf de start mee te kunnen helpen met de ontwikkeling van het product. Zodra het team compleet en gereed is kan de PoC beginnen.

Bepaal vervolgens in een planningssessie welke User Stories als eerste worden opgepakt. Werk hierbij volgens de Agile-methode; in sprints. Aan het einde van deze periode wordt het gedeeltelijke product (of MVP; Minimal Viable Product) aan het grotere publiek getoond. Deze zijn vaak wat uitgebreider dan de normale sprint demo’s. Een goed demo zorgt voor begrip binnen de organisatie. Ze hebben een duidelijke introductie en er wordt uitgebreid stilgestaan bij het gebruik van het platform, onder andere door ervaringen vanuit de ontwikkelaars te delen. Dit zal uiteindelijk leiden tot meer vrijheid in de productinnovatie.

Na elke sprint vindt er een ‘retrospective’ plaats. Dit is het moment om de samenwerking en technologie te evalueren. Door open en eerlijk naar elkaar te zijn kan de PoC nog effectiever gemaakt worden. Als toevoeging op de bootcamp en de demo’s worden er ook deepdives georganiseerd. Door middel van een of twee sessies wordt ervoor gezorgd dat de ontwikkelaars, IT-architecten en andere geïnteresseerden het platform en alle mogelijkheden volledig begrijpen. Tijdens zo’n bijeenkomst kunnen alle vragen worden gesteld en alle zorgen geuit (bv. interfaces, testen en integratie).

Periode na de PoC

Na de laatste demo begint de besluitvormingsfase. Het besluit om een nieuw platform te introduceren is lastig, maar is door deze methode gefundeerd vanuit de verschillende lagen van de organisatie en tastbare resultaten uit de PoC. Uiteindelijk zal afstemming en commitment van belangrijke stakeholders en afdelingen bepalen wat de totale doorlooptijd zal zijn.

Ervaring leert dat de ontwikkelaars niet zullen wachten op een besluit. In de periode dat ze hebben kunnen proeven aan het platform, hebben ze flinke stappen gemaakt. Daardoor ontwikkelen ze vaak een enorme drive om verder te gaan en dat maakt een PoC ook zo gewild. Daarnaast wordt ook de toegevoegde waarde voor de eindklant snel duidelijk, wat veel werknemers uitdaagt. In andere woorden, het is gebouwd voor succes!

Florentine Roerink

Author Florentine Roerink

More posts by Florentine Roerink