BLOG

Het begin van onze zoektocht naar relevantie

Stel je voor, je bent kapitein Jan. Je bent de leider van een marine opsporings- en reddingsteam. Er zijn zware weersomstandigheden en je krijgt veel oproepen voor hulp. Mensen vechten met de elementen op zee en jij moet beslissen wie je gaat helpen. Je hebt beperkte middelen en je moet de efficiëntie van je team maximaliseren. Om te kunnen beslissen waar je het meest nodig bent, moet je de positie en de behoeften van je doelen kennen. Anders kan het zijn dat je je doel volledig mist. Of je kunt niet echt helpen als je er eenmaal bent. En als je dat wel doet, moet je je richten op het verbeteren van de situatie, terwijl je continue de situatie van andere targets in de gaten houdt. Zodra de situatie voldoende is verbeterd, kan het zijn dat je naar een doel moet gaan met een hogere prioriteit.

Digitaal innovatiemanagement is als Search and Rescue

Digitale innovatie lijkt veel op de situatie hierboven. Als je er iets mee te maken hebt, moet je je vaak voelen als Jack… in 1850. Misschien is het soms meer een ontdekkingsreis dan een levensreddende missie, maar de principes zijn hetzelfde. Je moet beslissen waar je je middelen inzet en het is alleen het resultaat dat telt. Maar terwijl digitale innovatie iets van de moderne tijd is, zijn de hulpmiddelen dat zeker niet.

De kans is groot dat je bij het lezen van het verhaal hierboven dacht aan Jan als de kapitein van een snel schip met radar, radio, kaartplotter en misschien zelfs meer geavanceerde tools. Misschien zelfs wel een deel van een vloot met strikte procedures voor besluitvorming op het gebied van leven en dood en samenwerking. En zo denk je misschien ook over je innovatieteam. Veel innovatieteams zijn inderdaad behoorlijk krachtig en wendbaar geworden, maar hun middelen om zich in de juiste richting te bewegen zijn beperkt. En de samenwerking met andere teams heeft zijn uitdagingen. Moderne teams zijn meer als snelle RIB’s met semafoorcommunicatie tussen de brug en de machinekamer. En met nog slechtere communicatiemiddelen voor het contact met andere RIBs en het controlecentrum.

Veel ontwikkelingswerk gaat verloren

Al vele jaren ben ik betrokken bij digitale innovaties. Ik geloof dan ook sterk in Agile projectmanagement en ‘failing fast’ om snel te kunnen leren. Maar hoewel deze dingen de effectiviteit van de innovatie flink hebben verbeterd, zie ik nog steeds veel inspanning verloren gaan. Ik ben er van overtuigd dat we die verspilling verder kunnen terugdringen. En dat is ook nodig. Ten eerste is het lastig om goede mensen te vinden om de capaciteit te kunnen vergroten. Daarnaast heeft schaalvergroting met meerdere teams zijn grenzen. Daarom is het veel beter om eerst te onderzoeken wat er gedaan kan worden om de efficiëntie van je team te maximaliseren.

Om efficiënt te zijn, hebben we hulpmiddelen nodig die ons helpen om ons te richten op relevantie.

We blijven even bij de SAR-boot metafoor. Stel je dan eens voor hoe je zou kunnen profiteren van beter gereedschap. Dingen zoals radar en transponders, radio en een kaartplotter. Naar mijn mening zijn deze dingen de perfecte metafoor voor de dingen die vandaag de dag ontbreken in digitale innovatie en inefficiënties veroorzaken. Laten we daar eens op inzoomen:

1. We hebben digitale radar nodig om waarde te zien

Veel innovatieteams lijden aan een gebrek aan overzicht. Als je de efficiëntie van jouw team wilt maximaliseren, moet je weten waar je je op moet richten en wanneer je de aandacht moet verplaatsen. Ik denk dat dit de ontbrekende zaken zijn die samen een soort radarfunctie voor jouw team zouden kunnen vormen:

a. Waardemodel

Een universeel waardemodel maakt het mogelijk om requirements op een consistente manier te koppelen aan waarde (het WAAROM-deel van een requirement).

b. Waardegegevens

Als er eenmaal een model is, is het belangrijk om te proberen de doelwaarde zo SMART mogelijk te identificeren en te verwoorden. Net zoals boten radarreflectoren en actieve transponders nodig hebben, hebben bedrijven middelen nodig om gezien te worden door besluitvormers. Hiervoor zijn gegevens nodig. Gegevens die ons vertellen wat er verbeterd moet worden door de mate waarin een bepaald deel van het bedrijf er baat bij heeft.

c. Bredere context

Om suboptimalisaties te voorkomen, moeten we de requirements in een grotere context bekijken. Om te zien wanneer de voordelen voor het hele bedrijf het grootst zijn, moeten we een breder model creëren. Anders is een backlog slechts een lange waslijst en is het niet duidelijk of we alles hebben afgedekt. Uiteindelijk zijn we natuurlijk op zoek naar relevante innovatie.

2. We hebben een kristalheldere radio nodig om de waarde te communiceren

Communicatie is moeilijk. Daarnaast leiden het vrije formaat en de procedures voor het beschrijven van de requirements in de innovatieketen vaak tot miscommunicatie. Deze miscommunicatie tussen het bedrijfsleven en de ontwikkeling leidt tot verspilde ontwikkelingsinspanningen. Wat mij betreft zijn dit de vier belangrijkste factoren die bijdragen aan deze miscommunicatie:

a. Onvolledige requirements

Ten eerste hebben de requirements regelmatig geen betrekking op de drie essentiële onderdelen WIE, WAT en WAAROM.

b. Eigendomskwesties

Ten tweede is de beschrijving van WAT er ontwikkeld moet worden vaak niet afdoende beschreven door degene WIE vindt WAAROM het ontwikkeld zou moeten worden.

c. Overdragen

Ten derde vertroebelt het overdragen van de requirements in de organisatie en in de tijd, het WIE en WAAROM deel van de requirement. Hierdoor ligt de nadruk uiteindelijk vaak alleen op WAT.

d. Terugkoppelingsproblemen

Tot slot worden er vaak eenmalig voorafgaand aan de ontwikkeling prioriteiten gesteld. Vervolgens wordt pas voor het eerst geëvalueerd wanneer de functionaliteit helemaal is gebouwd en klaar is om te testen. Als tijdens die evalutie blijkt dat de functionaliteit geen effect heeft, zijn schaarse middelen verkeerd ingezet. Een proces met meerdere ontwikkelingsfasen die eindigen met een evaluatie voor elk van de aparte onderdelen zou meer controle geven en toch ‘agile’ zijn.

3. We hebben een chartplotter nodig om de waarde te wegen

Radar en radio leveren nuttige gegevens om op te navigeren. We kunnen andere hulpmiddelen toevoegen en gegevens uit verschillende bronnen op verschillende momenten bijhouden om onze besluitvorming te vergemakkelijken. En met iets om het allemaal samen te voegen in een visuele vorm, kunnen we data omzetten in inzichten en zal onze besluitvorming een stuk beter zijn. We hebben het equivalent van een chartplotter nodig om datagestuurde besluitvorming te ondersteunen. De tools die vandaag de dag in agile ontwikkeling worden gebruikt, hebben echter meer weg van een telex, met veel tekst en geen ondersteuning voor multidimensionale data.

Agile ontwikkelmethodes gebruiken de volgorde van de items op de backlog als een mechanisme om prioriteiten te stellen. Meer dan twee inputparameters voor de sortering zijn niet praktisch. In de praktijk wordt meestal alleen gesorteerd op basis van waarde, naar het oordeel van de product owner. We zien dan ook een gebrek aan grafische tools, waarmee op basis van meerdere parameters geprioriteerd kan worden.

En zo begon onze zoektocht naar tools voor relevante innovatie

Met deze dingen in gedachten zijn we begonnen met de ontwikkeling van BackLogic. We willen zeker de efficiëntie van ons team maximaliseren, en we willen je graag helpen om hetzelfde te doen. Ons doel is om agile teams te helpen zich te focussen op relevantie, door het leveren van de hierboven genoemde ontbrekende bits, om agile ontwikkelteams efficiënter te maken door te focussen op relevantie. In toekomstige blogs zal ik uitleggen hoe we dit aanpakken, waar we staan en voor welke uitdagingen we staan.

Wil je meer weten over onze BackLogic methodiek en tool en kan je niet wachten tot de volgende blog? Bekijk alvast onze teaser video.

Share on facebook
Share on twitter
Share on linkedin

Meer te ontdekken

Om de gebruikerservaring op de site te verbeteren en de website goed te laten functioneren maken we gebruik van cookies. Meer informatie hierover? Bekijk ons privacyverklaring.