In 2022 werkte Dashe & Thomson samen met The American College of Chest Physicians om een interactief eLearning-kaartspel te ontwikkelen voor de diagnose en behandeling van COPD. Vanwege complexe en krappe tijdlijnen koos het Dashe-team ervoor om enkele elementen van de agile projectmanagementbenadering te implementeren om de efficiëntie en samenwerking te maximaliseren.
Na afronding van het project ging Dashe-projectmanager Samantha Romo om de tafel met Dashe-CEO Rose Benedicks om het succes en het mogelijke toekomstige gebruik van agile-strategieën bij leren en ontwikkelen te bespreken.
Voor dit project had ik geen ervaring met de agile projectmanagementmethodiek. Ik wist wat het was en dat het een gangbare praktijk was die voornamelijk bij softwareontwikkeling werd gebruikt, maar verder had ik niet echt aan agile gedacht. Ik zal zeggen dat nadat jij, Rose, het had genoemd, ik VEEL onderzoek heb gedaan naar hoe het kon worden geïmplementeerd voor een L&D-project. Ik las blogposts over hoe andere mensen het gebruikten, dacht na over het Agile Manifesto en hoe dat kon worden toegepast op ons team, en bracht vervolgens alles wat we wisten over het project in kaart met behulp van de agile-methodiek.
Agile was handig in dit project omdat onze klant een complexe game wilde die snel kon worden voltooid. Ze wilden het laten zien op een jaarlijkse conferentie en we hadden maar zes weken om een game van begin tot eind te maken. Als we de traditionele watervalprojectmanagementbenadering zouden gebruiken, zouden we geen tijd hebben voor alle beoordelingscycli of een apart ontwerp- en vervolgens ontwikkelingsproces. De agile-methodologie paste binnen het tijdsbestek en stelde ons in staat om precies te leveren wat de klant wilde, snel.
Ik wist dat agile PM ons een snellere start zou geven, ons team beter met elkaar in contact zou houden en het starten en stoppen van beoordelingscycli zou elimineren (omdat we ze live doen) die je zou hebben in een traditioneel project .
Het belangrijkste element van agile dat we hebben gebruikt, was de constante verbinding van het hele team, dus ik denk dat je scrums zou kunnen zeggen. We begonnen met het plannen van twee contactpuntbijeenkomsten en een live beoordelingssessie per week. In een traditioneel agile proces zouden we elkaar elke dag hebben ontmoet, maar dat was gewoon niet mogelijk gezien de teamstructuur. We gebruikten de stand-ups wel als scrums en bespraken wat onze sprintinhoud voor die week zou zijn. We hebben er uiteindelijk voor gekozen om sprintperiodes van één week te gebruiken in plaats van de traditionele twee weken, die enigszins afweken van de standaard agile structuur. Door deze kleine aanpassingen konden we precies aan de behoeften van de klant voldoen.
Het andere belangrijke element van het Agile-framework dat we gebruikten, waren de doorlopende ontwikkelingscycli. Na elke live-evaluatie gingen we meteen weer door met ontwikkelen en maakten we bewerkingen en updates als onderdeel van de volgende sprint.
In een traditioneel agile raamwerk zouden delen van het project worden vrijgegeven terwijl andere delen nog in ontwikkeling waren. Met Agile kun je een MVP bereiken en een achterstand aan functies onderhouden om te integreren, maar dat is met een traditioneel gebruik van agile in softwareontwikkeling, dus dat hebben we hier niet gebruikt. Nou, eigenlijk brachten we tegen het einde releases uit die voldeden aan de minimumvereisten voor juridische beoordelingen, gebruikerstests, enzovoort. Dus misschien hebben we dat gedaan, in ieder geval een beetje.
Er is nog een plaats waar we zijn afgeweken van agile: meestal leiden je ontwikkelaars bij agile de stand-ups en bespreken ze wat hun taken zijn voor de sprints, en dat hebben we niet echt gedaan. In plaats daarvan denk ik dat ik meer een managementrol speelde over wat die taken zouden zijn in plaats van het team te laten beslissen. En nam een iets sterkere rol om ervoor te zorgen dat we op het goede spoor zaten.
In wezen gebruikten we een agile aanpak met mij als projectmanager en scrummaster.
We deden nog steeds de traditionele interne en externe kick-offs en omdat de klant de inhoud voor ons had in een storyboard-formaat, gingen we snel aan de slag. Als ze dat niet hadden gedaan, hadden we een typisch watervalproces moeten uitvoeren om die inhoud klaar te krijgen. Dat is het echt.
Het was van cruciaal belang om een team te hebben dat achter het idee stond. Als we het team niet klaar en beschikbaar hadden om als één team te werken en dichtbij te blijven, weet je, klaar om snel te handelen en beschikbaar voor de stand-ups en live reviews, zou het in duigen zijn gevallen. Het werkte omdat het team beschikbaar was om dit als een gemengd agile-traditioneel proces uit te voeren.
Ook de wekelijkse sprints waren heel duidelijk. Het was leuk om een specifieke lijst te hebben van wat er in elke sprint moest gebeuren. En dat is geëvolueerd.
Standups en live reviews hielpen echt om ervoor te zorgen dat iedereen op één lijn zat en op schema lag voor de week. De live beoordelingen zorgden ervoor dat we snel vooruit konden gaan, omdat we de volgende dag vrij van de feedback konden beginnen met ontwikkelen. Omdat we het live bespraken, konden we ter plekke bruikbare beslissingen nemen en vervolgens doorgaan met de ontwikkelingslus. Het voortdurend updaten van het project was echt de sleutel tot het succes van dit project.
Ik weet niet of we dit per se zouden moeten veranderen, maar omdat we (gelukkig) inhoud kregen en omdat we onmiddellijk met de ontwikkeling van inhoud begonnen, moesten we teruggaan toen de inhoud veranderde (meestal als gevolg van juridische beoordelingen). Dit veroorzaakte veranderingen aan het einde van het project die we niet noodzakelijkerwijs hadden hoeven bijwerken als we een watervalproces hadden gehad met een poort voor inhoudsfinaliteit. Dus terwijl we nog aan het ontwikkelen waren, hadden we andere beoordelingscycli gaande (met juridische zaken) die achteraf moesten worden aangepakt.
Ik weet niet zeker of we iets zouden veranderen. Ik vond dat het heel goed ging. En dat deed de opdrachtgever ook.
We hebben onze lessen nog niet geleerd, omdat ze een aantal wijzigingen in de regelgeving voor 2023 hebben die we moeten opnemen.
Bij nader inzien, als we het opnieuw zouden doen, zouden we juridische zaken opnemen in de beoordelingscycli. Of ze dat nu echt zouden kunnen of niet, ik weet het niet.
Ja, absoluut. Het was een waardevolle ervaring, zowel in uitdagende zin als in de zin van iets anders en succesvols doen.
Als het tijdsbestek het vereiste en we het juiste team hadden zoals we deze keer hadden, heeft het het project zeker versneld en indien nodig of gewenst is het een waardevolle methode om te implementeren.
Een andere reden waarom ik het opnieuw zou doen, is omdat elke persoon in het project wist wat er aan de hand was, wat er moest gebeuren en dat hij het tijdens het hele project kon laten gebeuren.
Doe je onderzoek en zorg ervoor dat je de methodologie begrijpt. Als u eenmaal begrijpt hoe u het wilt gebruiken, weet dan dat u de agile-methode niet 100% hoeft te volgen om het te laten werken in L&D. U kunt delen van agile en waterval op een intelligente manier gebruiken om te bereiken wat nodig is. Gebruik uw team om u te helpen begrijpen wat er nodig is, wat u moet toevoegen en wanneer u dit moet doen. Laat ze je helpen bij het definiëren van de sprints. Zorg ervoor dat je klaar bent om een snelle starter te zijn en in staat bent om continue aandacht te geven tijdens sprints. Je moet klaar zijn om te weten hoe de geschiedenis van het project de rest van het project informeert erg snel omdat je die continue ontwikkelingscycli hebt en niet veel pauzes.
