Slimmer Werken met Generatieve AI als Way of Working Professional

Generatieve AI speelt een steeds grotere rol in softwareontwikkeling. Tools zoals Large Language Models (LLM’s) worden gebruikt om repetitieve taken te automatiseren, suggesties te doen voor probleemoplossing en processen te stroomlijnen. Hoewel deze technologie vaak wordt geassocieerd met developers, kunnen ook professionals zoals requirements engineers, product owners, projectmanagers en scrum masters veel voordeel halen uit het gebruik van LLM’s. Maar hoe zet je generatieve AI effectief in binnen deze rollen?

Recap: Wat zijn LLM’s?

Voordat we hierop ingaan, is het belangrijk te begrijpen hoe LLM’s werken. Simpel gezegd voorspellen deze modellen het volgende woord in een zin, gebaseerd op enorme hoeveelheden data. Dit maakt ze bijzonder goed in het genereren van vloeiende en goed geformuleerde teksten. Het is belangrijk te beseffen dat LLM’s geen echte intelligentie hebben en geen nieuwe of innovatieve ideeën kunnen bedenken, omdat de output altijd gebaseerd is op veelvoorkomende patronen in de trainingsdata. Voor een uitgebreidere uitleg zonder jargon(!) check: A jargon-free explanation of how AI large language models work – Ars Technica

De kracht van LLM’s ligt in het presenteren van bestaande informatie in nieuwe vormen, het opsporen van inconsistenties en het versnellen van repetitieve taken. LLM’s kunnen bestaande content in andere vormen presenteren, repetitieve taken minder tijdsintensief maken en inconsistenties en onduidelijkheden opsporen. Dit zijn eigenschappen die erg nuttig kunnen zijn voor rollen als requirements engineer, product owner, projectmanager of scrum master.

Om dit te testen hebben mijn collega’s en ik een paar weken geëxperimenteerd met het gebruik van LLM’s. In deze blog deel ik onze ervaringen en inzichten. Ik bespreek zowel de succesverhalen als de situaties waarin het minder goed werkte en waar je voorzichtig mee moet zijn.

Genereren van Stories, Acceptance Criteria en Taken met ChatGTP

Ten eerste hebben we vanuit de rollen van requirements engineer en PO geprobeerd stories, acceptatiecriteria en bijbehorende taken te genereren op basis van de beschrijving van een feature of scenario. Hierbij hebben we een betaalde versie van ChatGPT gebruikt, zodat input niet wordt meegenomen in trainingsdata. De kwaliteit van deze resultaten bleek vooral afhankelijk van twee factoren:

1. Beschikbare context: Als de input erg beknopt is, blijven de gegenereerde stories, acceptatiecriteria en taken vaak te algemeen. Meer gedetailleerde input waarbij de context van een story ook wordt meegenomen, resulteert in output die beter aansluit bij de specifieke situatie.
2. Mate van algemene bekendheid onderwerp: Wanneer de beschrijving erg technisch is of niche binnen een specifiek domein, blijft de gegenereerde output erg algemeen en wordt er vaak wat bij verzonnen. Hierdoor is nog zo veel verdere detaillering nodig dat het gebruik van AI zonder eigen meegegeven kennisbasis weinig meerwaarde heeft.

Voorbeeld van een mindere prompt: “Maak een user story voor het implementeren van keycloak inclusief integratie met google en Azure”

De implementatie van Keycloack is een onderwerp waar veel bronnen en documentatie voor te vinden is. De kans is dus heel groot dat deze bronnen ook onderdeel zijn van de enorme hoeveelheden data waar ChatGTP op getraind is. Hierdoor zal ChatGTP waarschijnlijk in genoeg detail kunnen gaan voor het schrijven van een user story. Maar, er wordt in de prompt weinig richting gegeven aan welke aspecten er beschreven moeten worden in de gegenereerde story en er zijn geen verdere details over hoe Keycloak moet integreren met andere services of componenten. Als je deze prompt meegeeft zal je zeker een gegenereerde user story terugkrijgen, inclusief acceptance criteria die niet van toepassing zijn op jouw specifieke situatie en verzonnen details. Hierdoor zijn er nog veel handmatige aanpassingen nodig en heb je weinig tijdswinst behaald.

Een voorbeeld van een betere prompt: ”Schrijf een user story voor het implementeren van Keycloak als authenticatiesysteem binnen [ons platform]. De story moet gericht zijn op het ondersteunen van SSO voor onze eindgebruikers, met Azure AD als identiteitsprovider. De user story moet beschrijven wat een eindgebruiker verwacht te kunnen doen, inclusief acceptance criteria. Vermeld technische vereisten zoals ondersteuning voor OAuth2 en OpenID Connect”

Met deze prompt zal je een story kunnen genereren die waarschijnlijk beter aansluit bij wat je nodig hebt, omdat er parameters gegeven worden waar de implementatie van Keycloak aan moet voldoen en welke elementen de story uit moet bestaan. Hierdoor hoef je minder aanpassingen te maken voordat het bruikbaar is, waardoor ChatGTP je echt tijd bespaart.

Met deze aandachtspunten kan het gebruik van ChatGTP je zeker. Je hoeft niet alles zelf uit te werken, maar richt je op het beoordelen en aanpassen van de gegenereerde tekst. Kritisch kijken naar de output blijft cruciaal, omdat niet alle suggesties relevant of direct bruikbaar zijn.

Analyseren van Sprints en Maken van Retrospectives met ChatGTP

Vanuit de rol van Scrum Master hebben we het analyseren van data uit verschillende sprints door ChatGPT en het genereren van retrospectives getest. Hoewel ChatGPT trends kon signaleren en nuttige grafieken kon genereren, waren deze trends vaak al duidelijk zichtbaar door zelf goed naar de data te kijken. De adviezen die ChatGTP genereert voor de scrum master op basis van de ingevoerde data zijn bruikbaar, maar soms erg voor de hand liggend. Het gebruik van ChatGTP levert dus weinig nieuwe inzichten op in deze context.

Advies van ChatGTP om productiviteit van ene team te verbeteren op basis van sprint velocity data van meerdere spints.

Bij het genereren van retrospectives lukte het om bruikbare onderdelen te maken, zoals energizers of check-ins. Toch bleek een 1-op-1 overname van de gegenereerde content voor een hele retro niet goed te werken, omdat onderdelen niet goed op elkaar aansluiten, of niet het doel berijken wat je in je prompt hebt meegegeven. Voor inspiratie kan ChatGPT waardevol zijn, maar een complete retrospective maken blijft (voor nu) mensenwerk.

Eigen GPT’s voor Specifieke Taken

Ook hebben we geëxperimenteerd met het bouwen van eigen GPT’s vanuit verschillende rollen. Dit houdt in dat je een standaardprompt en/of een kennisbasis, zoals tekstdocumenten, toevoegt. Hierdoor wordt de output afgestemd op specifieke processen of informatie.

Een voorbeeld hiervan is de Agile Coach GPT. Met de Scrum Guide als kennisbasis gaf deze GPT antwoorden die naadloos aansloten bij de bron. Hoewel dit handig was om snel uit te vinden hoe iets beschreven staat in de gebruikte bronnen, bleek het lastig om onderscheid te maken tussen antwoorden gebaseerd op de kennisbasis en andere, minder betrouwbare output.

Een ander voorbeeld is de Requirements Engineer GPT, die hielp bij het aanscherpen van acceptatiecriteria door kritische vragen te stellen. Dit was erg nuttig voor het op gang brengen van het denkproces, maar vereiste een zorgvuldige beoordeling van de relevantie van de vragen. Soms zaten er vragen tussen die buiten de scope van de user story vielen. Als je zonder nadenken alle output zou overnemen, loop je het risico op scope creep.

Interface waarin je een custom GTP kan instellen.

Genereren en Analyseren van Documenten in Office

Ten slotte is er vanuit de rol van projectmanager geëxperimenteerd met Copilot in Microsoft Office. Dit bleek handig bij het opstellen, bewerken en analyseren van documenten.

Ten eerste is Copilot in staat tekst in een document te genereren op basis van bestaande documenten door de relevante informatie te extraheren. Dit is bijzonder nuttig bij het maken van bijvoorbeeld projectinitiatiedocumenten. Hoewel de invulling nog steeds handmatig gecontroleerd moest worden om eventuele hallucinaties te verwijderen, bespaarde het aanzienlijk veel tijd.

Ook bleek Copilot binnen MS-office sterk en tijdbesparend in het interpreteren van grote datasets in Excel. Dit is vooral efficiënt bij berekeningen of inzichten die je eenmalig nodig hebt.  Zonder veel context mee te hoeven geven en zonder complexe formules te hoeven maken is Copilot in staat nauwkeurig berekeningen uit te voeren, tijdregistraties te analyseren en waardevolle inzichten genereren. Dit bleek vooral nuttig bij het analyseren van urenregistraties en het berekenen van verbruikte tijd per activiteit of per persoon. Iets waarvoor al snel draaitabellen nodig waren zonder het gebruik van Copilot.

Ten slotte presteert Copilot wisselend bij het creëren van PowerPoints. Het lukt om automatisch slides te genereren op basis van invoer uit andere documenten. Deze slides vragen nog wel wat kleine aanpassingen voor je ze kan gebruiken in een presentatie, maar het scheelt zeker tijd in een begin maken aan slides. Het genereren van slides met complexe informatie uit veel verschillende documenten, zoals een presentatie waarin de voortgang van verschillende projecten wordt getoond, lukt met Copilot (nog) niet . Ook werkt slide generatie niet goed samen met eigen templates.

Key takeaways

Zoals blijkt uit onze bevindingen kun je ook als requirements engineer, product owner, scrum master of projectleider veel voordelen halen uit het gebruik van LLM’s zoals ChatGPT en Copilot. Maar, het is zeker niet geschikt voor alle toepassingen.

LLM’s zijn vooral goed in het in het presenteren van data in een andere vorm of voortborduren op gegeven input. LLM’s zijn uitstekend in het transformeren van bestaande informatie naar een nieuwe vorm of in het verder uitwerken van gegeven input. Dit kan bijvoorbeeld betekenen dat je met een ruwe beschrijving van een feature snel een set user stories, acceptatiecriteria of taken kunt genereren. De kracht van de technologie ligt vooral in het herstructureren van informatie op een manier die aansluit bij jouw specifieke behoeften. Denk bijvoorbeeld aan het vertalen van projectdoelen naar een duidelijke PowerPointpresentatie of het samenvatten van grote hoeveelheden data in een begrijpelijk document. Het is echter belangrijk om de output altijd kritisch te bekijken, omdat er fouten of hallucinaties in kunnen insluipen.

Kwaliteit van je output is sterk afhankelijk van je input. Het bekende principe van “garbage in, garbage out” geldt ook hier. Hoe beter en gedetailleerder de input, hoe relevanter en nauwkeuriger de gegenereerde output zal zijn. In de experimenten bleek dat een specifieke en goed in de context geplaatste beschrijving vaak resulteerde in bruikbare user stories en taken, terwijl generieke of te beknopte input output opleverde die niet toereikend was. Ook bij business context specifieke of technische details stuitten we op beperkingen en zijn gegenereerde antwoorden vaak te algemeen. Dit is in lijn met andere

Resultaten zijn nooit 1 op 1 te gebruiken. Hoewel LLM’s  je goed kunnen helpen met bepaalde taken, is het nooit helemaal zeker of alle informatie in gegenereerde antwoorden klopt. Daarom is het aan te raden om resultaten als een startpunt te zien, en niet als een eindproduct. In praktijkexperimenten bleek dat zowel de inhoud als de structuur vaak aanpassingen vereisten om bruikbaar te zijn. Het risico van blindelings vertrouwen op de output is dat je fouten overneemt of onnodige informatie toevoegt, wat kan leiden tot inefficiënties, scope creep of verkeerde keuzes. Door kritisch te blijven en gegeven informatie te verifiëren, kun je optimaal profiteren van de mogelijkheden van LLM’s zonder kwaliteit en betrouwbaarheid op te offeren.

Naarmate LLM’s zich verder ontwikkelen, verwacht ik dan ze steeds beter worden in het uitvoeren van complexe taken op het gebied van herstructureren van bestaande informatie, tekstverwerking of repetitieve taken. Voor Way of Working professionals opent dit de deur naar een toekomst waarin sommige taken steeds meer geautomatiseerd worden. LLM’s zullen daarentegen waarschijnlijk nooit creatief, en strategisch denkwerk kunnen overnemen. Doordat LLM’s sommige taken deels kunnen overnemen zullen we meer tijd hebben om te besteden aan andere werkzaamheden.

Fun fact: Ik heb de eerste versie van deze blog op spelling en grammatica laten controleren door ChatGPT. Daarna heb ik er samen met een collega nog minstens 15 fouten uitgehaald. Spellingscontrole is dus ook zeker iets waarvoor ik geen ChatGPT ga gebruiken in de toekomst.