Sådan får du Agile til at fungere med Metagility (med David Bishop fra Agile Worx)

Læs transskriptionen:

Vi prøver at transskribere vores podcasts ved hjælp af et softwareprogram. Bær over med eventuelle stavefejl, da botten ikke er korrekt 100 % af tiden.

Ben Aston: Så lad mig gætte: Du arbejdede med vandfaldsmetoden, og det virkede ikke, hvorefter du prøvede Agile, men det fungerer heller ikke rigtigt.

Så nu blander du tingene. Du har en skefuld Agile og en portion vandfald, og du forsøger at finde lidt krymmel til toppen. Bliv ved med at lytte til dagens podcast om metagility. Så lærer du måske en ting eller to om, hvordan en agil drejebog kan bruges til at kombinere det bedste fra begge verdener.

Tak, fordi du lytter med. Jeg hedder Ben Aston og er grundlægger af The Digital Project Manager. Velkommen til DPM-podcasten. Vi har som mission at hjælpe projektledere med at få succes og hjælpe mennesker, der leder projekter, med at levere bedre resultater. Vi er her for at hjælpe dig med at tage dine projektkompetencer til næste niveau. Besøg thedigitalprojectmanager.com for at lære mere om den undervisning og de ressourcer, vi tilbyder gennem medlemskab. Denne podcast er bragt til dig af Clarizen, den førende software til styring af virksomhedsprojekter og -porteføljer. Besøg Clarizen.com for at læse mere.

I dag har jeg besøg af David Bishop. Dr. David Bishop er teknolog, konsulent, forskningsiværksætter og underviser med mere end 25 års erfaring inden for telekommunikation, transport, offentlig administration og forsyningsvirksomhed. Han er administrerende direktør og grundlægger af Agile Worx, LLC. Du kan besøge Agile-worx.com. Det er en virksomhed, der leverer softwareværktøjer til program- og projektledelse samt undervisning og konsulentydelser. Han er også forfatter til Metagility: Håndtering af agil udvikling for konkurrencemæssige fordele. Mange tak, fordi du vil være med i dag, David.

David Bishop: Tak, fordi jeg måtte komme.

Ben Aston: Jeg vil gerne dykke ned i hele idéen om at opbygge en ramme fra bunden. Kan du fortælle lidt om din baggrund, og hvordan du nåede frem til, at verden havde brug for en ny ramme? Hvilke erfaringer førte dig til det punkt?

David Bishop: Jeg har arbejdet med teknologiudvikling i omkring 25 år, primært som systemarkitekt og systemingeniør, hvor jeg har udviklet løsninger med nye teknologier. Det har været inden for IT, IATA, mobiltelefoni og telekommunikation. Som du nævnte tidligere, begyndte jeg for omkring 10 år siden at arbejde med en virksomhed, der var dybt involveret i industriel IoT. En af de ting, de desperat forsøgte at gøre, var at indføre agile metoder.

Ben Aston: Okay.

David Bishop: Årsagen var, at deres kunder efterspurgte det. De befandt sig i en ny teknologibranche – eller rettere sagt en relativt ny teknologi, for det var ikke en ny industri, men en ny teknologi, som de forsøgte at integrere i industrien. Der var mange konkurrenter, som udviklede denne nye teknologi til intelligente elnet med alle de forskellige former for RF-kommunikation.

Det var baggrunden for hele teknologien. De forsøgte flere gange at indføre Agile, fordi det var afgørende for dem at kunne få deres produkter på markedet så hurtigt som muligt. De prøvede hårdt flere gange, brugte mange højt betalte konsulenter og mislykkedes fuldstændigt – igen og igen. Jeg var selv en del af det. Jeg hjalp organisationen med at udvikle produkterne og med at forsøge at indføre Agile undervejs. Jeg tænkte, at der måtte være en anden måde at gøre det på.

Hvorfor havde så mange meget dygtige konsulenter, som vi hentede ind, så store problemer? Det, jeg indså, var, at Agile ganske vist har haft stor succes og bestemt er en god idé, men også har nogle begrænsninger. En af dem er udfordringer med distribuerede teams, store teams samt meget komplekse udviklingsmiljøer og komplekse eller komplicerede produkter. Det kan være store udfordringer for mennesker, der forsøger at indføre agile metoder i deres reneste form.

Ben Aston: Helt sikkert. Fortæl os lidt om din erfaring med de projekter. Jeg er nysgerrig efter at høre, hvordan det så ud i praksis. Jeg forstår det overordnede billede af udfordringerne ved en agil implementering, men hvordan så det ud fra dag til dag? Hvordan var det problematisk i det daglige projektarbejde? Hvilke advarselstegn lagde du mærke til, som fortalte dig, at noget ikke var helt rigtigt?

David Bishop: Der var massiv modstand fra nogle af teamsene. Det var ikke bare lidt modstand; det var virkelig hård modstand og klager over, at processen ganske enkelt ikke fungerede og ikke kunne fungere. Årsagen var, at dette var et miljø med indlejrede systemer. Fordi de udviklede IoT- eller industrielle IoT-produkter, var produkterne ikke kun software – de var enheder. Enheder består typisk af indlejrede systemer, hvor hardware, firmware og software udvikles i forskellige spor, af forskellige teams, afdelinger eller nogle gange forskellige virksomheder.

På et tidspunkt skal alle tre komponenter dog testes og udgives som ét samlet produkt. Det var det, virksomheden arbejdede med. Det er også det, der gør denne kontekst interessant, for det er her, en stor del af innovationen foregår i dag. For mange år siden, da manifestet først blev udgivet, handlede det primært om software. I dag handler det ikke kun om software.

Det handler om enheder, intelligente enheder, intelligente målere, intelligente biler og din mobiltelefon. Næsten alt er en indlejret systemenhed i dag. Derfor har virksomheder, der udvikler den slags produkter, de største problemer med agilitet på grund af kompleksiteten. I det daglige forsøgte vi sammen med konsulenterne at sige: Okay, jeres softwareteams arbejder i tougersforløb og holder daglige standups, men vi kan ikke få hardwarefolkene til at gøre det samme. De synes ikke, det er nødvendigt.

Ben Aston: Okay.

David Bishop: Firmwarefolkene havde det samme problem. De sagde, at det ikke fungerede særlig godt for dem, og at det ikke gav mening. Og det var rigtigt, for softwareteamsene arbejdede meget hurtigere. De kunne udvikle i iterationer. Det fungerede ikke særlig godt med hardwareteamsene, der ikke arbejdede på den måde. Deres produkter havde en udgivelsescyklus på 12 til 18 måneder.

Det tog lang tid at integrere et chipsæt i hardwaren og teste det grundigt. Desuden befinder de fleste organisationer, der udvikler indlejrede systemer, sig i brancher med langt mere regulering, lovgivningsmæssig overholdelse, offentligt tilsyn og lignende.

Hvis du tænker på intelligente målere i forsyningssektoren, intelligente biler eller et flyelektronisk system i et fly, kan du forestille dig hvorfor. Risikoen er meget større, når der er mulighed for tab af menneskeliv eller katastrofale fejl, og når omkostningerne ved fejlene kan være så høje. Derfor skal de typisk leve op til en langt højere standard for kvalitet, ydeevne og succes end en almindelig softwareapplikation eller en e-handelswebside.

Ben Aston: Det giver mening.

David Bishop: Det var primært de brancher, der tog de agile metoder til sig hurtigst og tidligst.

Ben Aston: Hvis du vil læse mere om Metagilitys oprindelse, kan du besøge indlægget på thedigitalprojectmanager.com. Her beskriver han, hvordan idéen udviklede sig gennem arbejdet med at skabe bogen. I stedet for at gå længere ned i den historie vil jeg gerne se på selve rammen og finde nogle pointer, som vi kan anvende i vores projekter. Jeg tror, det er meget relevant, fordi mange af os har prøvet elementer fra vandfaldsmetoden.

Vi arbejder sekventielt, fordi det virker mest logisk ud fra vores interessenter og den måde, vores samarbejder er struktureret på. Men vi prøver også agile elementer i form af de principper, vi anvender. Vi arbejder kollaborativt og iterativt. Vi tager forskellige dele med os. Vi har købt ind på idéen om at iterere og levere værdi ofte.

Vi bygger, tester og lærer. Men i praksis er vi nødt til at arbejde sekventielt. Derfor vil jeg tale om metagility, og hvordan vi kan anvende det i vores projekter. Agile metoder er populære og bredt anerkendt som den bedste måde at håndtere softwareudvikling på, men hvad agile metoder faktisk betyder, er åbent for fortolkning.

Som vi har talt om, udgør det en reel udfordring for mange virksomheder. Denne hybride tilgang bliver ikke altid fremhævet som den bedste løsning, men den er i praksis resultatet for mange, der forsøger at sammensætte forskellige rammer og arbejdsformer inden for organisationens begrænsninger. Hardware har en længere udviklingscyklus end software, mens middleware ligger et sted midt imellem.

Det skaber en udfordring, når vi forsøger at udgive ting i samme takt. Det gælder også nogle gange webudvikling, hvor UX og design kan behandle ting hurtigt, mens udviklingen tager meget længere tid. Jeg vil gerne tale om det problem, du ser, og dykke ned i de resultater og begrænsninger ved agile metoder, som du beskriver i din bog.

David Bishop: Når man taler om rammer som Scrum, Kanban og mange andre, forsøger de at løse problemet fra forskellige vinkler. Der er DSDM, LeSS og DA eller Disciplined Agile, som PMI for nylig købte. Det bliver interessant at se, hvordan det udvikler sig.

De forsøger alle at angribe problemet på forskellige måder. Mange mennesker misforstår ofte årsagen til at indføre agile metoder. Der har været stort fokus på at indføre Agile, fordi det får teams til at arbejde bedre sammen, gør dig til en bedre leder eller øger effektiviteten. Det er alt sammen godt.

Men Agile handlede oprindeligt om konkurrence og om at blive nummer ét på sit marked. Agile-manifestet var inspireret af lean-produktion og anvendte lean-produktionsteknikker i software. Det udsprang af Toyotas produktionssystem og et forskningsarbejde fra 1979 af to japanske forskere. Hvad gjorde det for Toyota? Det tog Toyota fra at være en producent af dåser på hjul til at blive en af verdens førende – måske den førende – bilproducent.

Hele idéen med agilitet er at forsøge at gentage den form for succes og blive nummer ét på sit marked. Mange af disse rammer har efter min mening glemt dette. Når man ser på SAFe, fokuserer den på virksomhedsniveauet og på at agilificere alle dele af organisationen, uanset om det er HR- eller juridisk afdeling.

Idéen er at gøre alle dele af virksomheden og driften agile i håbet om, at det giver gradvise forbedringer over tid. Den fokuserer også i nogen grad for meget på processer og analyser. Før brugerhistorier og levende dokumentation via samarbejdsværktøjer havde vi lange standardprocedurer, som blev brugt til mainframesystemer og ældre systemer. På nogle måder minder SAFe mig om det, fordi den producerer lange og dyre procedurer for at håndtere forskellige dele af virksomheden agilt.

Der er ikke nødvendigvis noget galt med det, men det er på mange måder det modsatte af, hvad Agile grundlæggende handler om.

Ben Aston: Okay.

David Bishop: Scrum fokuserer på teamniveauet. Det er et sæt ritualer, der hjælper dig med at styre dine teams. De forskellige rammer kan faktisk bruges sammen og behøver ikke at være i konflikt. Du kan bruge Scrum, Kanban, metagility og SAFe i den samme organisation.

Metagility fokuserer på produktudviklingsmotoren. Den fokuserer på produktet, produktledelsen, projektledelsen samt udviklings- og testteamsene. Den ser på, hvordan krav udvikles og fortolkes af teamsene, hvordan produktet testes, hvordan det kommer på markedet, og hvordan du samarbejder med kunden, så produktet lever op til forventningerne og har den højest mulige kvalitet.

Hvis du vil vinde et kapløb, skal du fokusere på det, der er afgørende. Hvis du bygger en bil til et dragrace, fokuserer du på motoren, transmissionen og drivlinjen. Du bekymrer dig ikke om elruder eller aircondition. På mange måder fokuserer nogle af de andre rammer for meget på periferien i stedet for præcis det, der er nødvendigt for at blive nummer ét på markedet.

Det er det, metagility gør. På baggrund af den forskning, vi har gennemgået, var der en række casestudier, hvor virksomheder opnåede det, jeg kalder en superagil tilpasning. De udnyttede agilitet til at blive nummer ét på markedet. Metagility samler alt det, disse virksomheder gjorde rigtigt, og forsøger at gøre det til et produkt, så andre organisationer kan opnå de samme resultater.

Ben Aston: Du beskriver det som en omfattende tilgang til håndtering af en ny og meget effektiv form for identitet. Hvad er metagility egentlig? Er det en leveringsramme eller en metode? Jeg har også set det beskrevet som en drejebog. Hvordan vil du beskrive det?

David Bishop: Jeg vil beskrive det som en ramme. Den fører dig gennem processen. Det første trin i metagility er for eksempel at fastslå, hvilken type agil tilpasning du ønsker. Faktisk vil jeg tage et skridt tilbage. Bogen begynder med at lære dig at tænke anderledes ved at bruge forskningsbaserede og videnskabelige metoder til at træffe forretningsbeslutninger.

Der er et helt afsnit om dette samt et afsnit om, hvordan Agile-manifestet er blevet ændret på baggrund af forskningsresultater. Når du når til den agile transformation, er et af de første spørgsmål, hvilken type agil tilpasning og implementering du skal bruge. Skal det være en ren agil implementering, en hybrid tilgang, eller skal du fortsætte med vandfaldsmetoden? I nogle tilfælde bør du måske gøre det sidste.

Der findes meget forskningsbaseret erhvervsforskning, som kan hjælpe med at besvare det spørgsmål. En forsker ved navn Barlow offentliggjorde en artikel om, hvordan man træffer beslutningen. Jeg har inkluderet den i min bog som en figur, der viser, at valget af agil implementering bør baseres på kompleksiteten af afhængighederne og de indbyrdes afhængigheder i produktet og organisationen samt på teamenes størrelse.

Det er vigtigt. I mange casestudier med indlejrede systemer har man komplekse produkter og store distribuerede teams med mange afhængigheder og indbyrdes afhængigheder mellem de forskellige komponenter. Den kompleksitet betyder, at man må gøre noget anderledes. En ren agil tilgang på tværs af organisationen vil typisk ikke fungere. En bevidst hybrid tilgang kan derimod give fantastiske resultater.

Hybride tilgange har ofte et negativt omdømme i branchen, fordi vi forbinder hybrid med en mislykket implementering. Men det er kun tilfældet, hvis tilgangen opstår ved et tilfælde. Hvis du har en bevidst tilgang til en hybrid agil implementering og baserer den på videnskabelig argumentation og forskning, ved du, at organisationen bevæger sig i den rigtige retning.

Ben Aston: Kan du beskrive, hvordan rammen fungerer, og hvilke komponenter den består af, for dem der ikke har læst bogen?

David Bishop: I bogen har jeg en stor figur, der viser alle delene. Grundlæggende starter metagility med beslutningen om, hvilken transformationsmetode du skal vælge.

Ben Aston: Og hvordan får man adgang til betalingen?

David Bishop: Det sker ved at bruge Barlows diagram, som jeg nævnte tidligere. Det er en forskningsartikel, der beskriver, hvordan man træffer beslutningen. Det er grundlæggende en funktion af teamenes størrelse, produkternes kompleksitet og graden af samspil eller indbyrdes afhængighed mellem teamsene.

Den hybride tilgang består af trin til at kombinere agile metoder. Softwareteams kan for eksempel have tougerssprints og daglige standups, mens firmwareteams kan have 30-dages sprints og standups én gang om ugen.

Hardwareteams, der arbejder med en langsommere og længere cyklus på typisk 12 til 18 måneder, bruger måske ikke Scrum eller sprints i egentlig forstand. De kan arbejde efter vandfaldsmetoden, men anvende teknikker som hurtig prototyping for at holde trit med de andre teams og levere de platforme eller testmaterialer, der er nødvendige for at undgå blokeringer. Målet er at opretholde flowet gennem hele processen.

Metagility beskriver, hvordan de forskellige teams kan anvende agile eller vandfaldsbaserede principper. Stage gates fra vandfaldsmetoden kan tilpasses den hybride metode som en form for kontrol og balance. De kan sikre, at de forskellige spor, som bevæger sig med forskellig hastighed, stadig er synkroniserede.

Metoden beskriver også de forskellige målepunkter og typer af interaktioner, der bør anvendes. Vi hører ofte om mennesker og interaktioner frem for værktøjer og processer, men ingen fortæller, hvad interaktioner konkret skal være. I metagility opdeler vi dem i seks veldefinerede kategorier baseret på vores mest succesfulde casestudier og beskriver, hvordan de implementeres og håndteres.

Det bliver dermed en detaljeret drejebog til håndtering af en hybrid agil implementering.

Ben Aston: Hvordan afgør man den rette blanding af agile egenskaber? Folk reagerer ofte negativt på forandringer. Hvordan fastlægger man blandingen, og hvornår er status quo acceptabel, mens der andre gange er behov for udvikling eller en revolution i processen?

David Bishop: Det går tilbage til brugen af videnskabelige metoder og engageret forskning. Det er sådan, du får det bedste svar. Når folk forsøger at løse den slags problemer, bruger de ofte intuition, bedste praksis, interviews eller konsensus.

Der er ikke nødvendigvis noget galt med det, men en agil transformation, DevOps-transformation eller digital transformation kræver ofte stærkere medicin. Det var netop årsagen til, at jeg tidligt så et mønster af fiasko. Mange konsulenter forsøgte at håndtere problemet som ethvert andet forretningsproblem: Det, der virkede i min tidligere virksomhed, må også virke her.

Forretningsforskning viser imidlertid, at computerinformationssystemer og informationsmiljøer er meget kontekstafhængige. De varierer betydeligt fra virksomhed til virksomhed. Det, der fungerer ét sted, fungerer ikke nødvendigvis alle andre steder.

Hvis du anvender videnskabelige metoder, for eksempel et fortolkende casestudie, kan du generalisere inden for bestemte rammer. Du kan finde ud af, hvad der kan overføres fra én organisation til en anden. Det kræver flere casestudier og brug af fortolkende casestudier, etnografier og lignende metoder.

Ben Aston: Det er altså ikke en standardløsning, men en tilpasningsbar ramme. Udfordringen er så, hvordan man ved, om en implementering reelt er metagility, og hvordan man vurderer dens succes.

David Bishop: Det er et godt spørgsmål. Metagility omfatter også teorien om agil vorticitet. Ud over den hybride agile tilgang og resultaterne om interaktioner og forskellige teams indeholder metagility teorien om agil vorticitet, som udsprang af forskningen.

Begrebet agil vorticitet besvarer spørgsmålet om, hvor agil du eller din organisation er. Det er et centralt spørgsmål i branchen. Vi kan gennemføre en agil transformation, men hvordan ved vi, om den har hjulpet os? Hvordan ved vi, hvor vi står, og hvordan vi bliver bedre?

Der har længe ikke været nogen reel måde at måle agilitet på. Det er det, agil vorticitet gør. Det er et komplekst begreb, som jeg beskriver detaljeret i bogen, og det er baseret på forskningsartikler. Det giver en måde at måle succes på.

Ben Aston: Hvilken effekt har du set hos de organisationer, du har arbejdet med, som har implementeret din ramme?

David Bishop: Mange af vores casestudier var inden for markedet for indlejrede systemer, fordi det efter min mening er det mest spændende og udfordrende marked. Virksomheder, der har anvendt metagility, er i de fleste tilfælde blevet markedsledere – enten nummer ét eller tæt på.

Det betyder typisk større markedsandel og flere enheder på markedet end konkurrenterne. Når du befinder dig på et nyt marked, er nøglen til lang levetid at opnå den afgørende markedsandel tidligt, før konkurrenterne gør det. Det kræver, at du tager innovativ teknologi til dig og får den på markedet før alle andre.

Agile er en god måde at gøre det på, og specifikt mener jeg, at metagility er effektiv. De mest succesfulde casestudier har reduceret cyklustiderne så meget som muligt, samtidig med at de har fastholdt kvalitet og kundetilfredshed og fået innovative produkter på markedet tidligt.

Ben Aston: Hvor har du set metagility mislykkes, og hvorfor? Hvilke udfordringer har du set ved implementeringer?

David Bishop: Jeg vil pege på to specifikke områder. Det første gælder alle agile rammer: Hvis du ikke har opbakning fra ledelsen, kommer du ikke langt. Det starter fra toppen. Ledelsen skal forstå målet og den effekt, transformationen har på bundlinjen. Det handler ikke kun om at gøre medarbejderne glade, men om konkurrenceevne og bedre indtjening.

Den anden årsag er dårlig kravhåndtering. Når organisationer gennemfører en agil transformation, fokuserer de ofte på udviklings- og testteamsene. De sikrer, at Scrum-teamene er organiserede, at de arbejder i to uger, og at standups fungerer. Men der er for lidt fokus på kravene og på forretningsanalytikerne eller produktejerne.

I en agil verden udvikler du krav; du indsamler dem ikke. Det er en stor forskel. I vandfaldsverdenen har du et veldefineret scope og en jerntriangel med scope og omkostninger. Du er bekymret for scope creep og forsøger at identificere alle krav på forhånd.

Forretningsanalytikere forsøger ofte at brainstorme krav i stedet for at arbejde tæt sammen med kunden om at definere og udvikle dem. Resultatet bliver flere og flere krav, som bliver umulige at prioritere. Udgivelserne fyldes, funktioner bliver underudnyttede, og den tekniske gæld kommer ud af kontrol. Det er sådan, agile transformationer mislykkes. Enhver ramme, også metagility, kan mislykkes, hvis man ikke ændrer måden, krav udvikles på.

Ben Aston: Hvis man er ny inden for metagility, hvad er så det første skridt, en organisation kan tage?

David Bishop: Det første, man bør gøre, er at etablere nye kunderelationer. Agile-manifestet taler om kundesamarbejde frem for kontraktforhandling, men vores forskning viser, at kontraktforhandling og kundesamarbejde i virkeligheden er det samme. Forhandlingen er en løbende proces mellem interessenter i hele virksomheden: produktchefer, produktejere, projektledere, udviklingsteams, Scrum-teams og en lang række interessenter hos kunden.

Du skal etablere et samarbejdsbaseret forhold til kunden. Kunden skal hjælpe dig med at teste, især hvis du vil have et innovativt produkt hurtigt på markedet. Kunden skal være en del af processen.

Når vi arbejder med metagility, siger vi til ledere, at det ikke handler om en plan, men om en vision. De mest succesfulde casestudier havde en klar vision for, hvor de ville hen på markedet, og de traf strategiske valg om, hvilke kunder de ville arbejde med.

De tog ikke bare imod enhver kunde for at tjene så mange penge som muligt. Nogle kunder måtte afvises, fordi de ikke ville deltage i processen og være samarbejdende kunder. Derfor er det første skridt sandsynligvis at finde de rigtige kunder, etablere et stærkt samarbejde og afklare visionen for, hvor du vil hen.

Ben Aston: Det er gode råd. Vi kan ofte vælge at tage alt ind ad døren, men hvis vi vil levere reel værdi til slutbrugere og kunder, har vi brug for den rigtige samarbejdsmodel. Tillid gør samarbejdet muligt, så vi sammen kan opnå det bedste resultat.

Mange tak, David, fordi du ville tale med os om metagility. Det har været meget hjælpsomt.

David Bishop: Mange tak.

Ben Aston: Jeg vil gerne høre, hvad du synes. Har du læst bogen metagility ? Fortæl os, hvad du synes, i kommentarerne. Vi indsætter et link i transskriptionen, så du kan finde den. David, hvis folk vil vide mere om metagility og din bog, hvor kan de så læse mere om dig?

David Bishop: Du kan naturligvis Google ordet metagility, hvor du finder alle mulige ressourcer. Du kan også besøge Agileworx.com (Agile-worx.com) og læse om virksomheden og det, vi forsøger at gøre. Vi tilbyder også kurser. De foregår normalt fysisk, men de er blevet udskudt til efteråret.

Fra august til november håber vi stadig at kunne afholde dem fysisk, men vi kan gå over til nogle virtuelle kurser. Du kan finde den seneste tidsplan på metagility.technology og tilmelde dig kurserne. Du kan også kontakte mig på David@agileworx.com (Agile-worx.com). Jeg er altid interesseret i at høre fra folk og tjekker min e-mail hele tiden.

Ben Aston: Godt. Mange tak, David. Hvis du vil lære mere og komme foran i dit arbejde, kan du slutte dig til os. Bliv en del af vores fællesskab med DPM-medlemskab på thedigitalprojectmanager.com/membership. Du får adgang til vores Slack-team, hvor vi diskuterer emner som dette, samt skabeloner, workshops, AMA-sessioner, kontortid, e-bøger og meget mere. Hvis du kunne lide det, du hørte i dag, så abonnér og hold kontakten på thedigitalprojectmanager.com. Indtil næste gang: Mange tak, fordi du lyttede.