Agile Marketing: hoe je de methodiek begint toe te passen

Na mijn vorige week gepubliceerde tutorial over Trello, leek het me nuttig om uit te leggen hoe ik de Agile-methodiek in mijn projecten toepas.

Misschien zeggen agile methodieken je nog niet zoveel.

Of misschien denk je dat ze alleen voor softwareontwikkeling en digitale producten bedoeld zijn.

Niets is minder waar: ze kunnen eigenlijk op elk proces, project of elke afdeling worden toegepast.

En dit artikel bestaat uit twee heel duidelijk verschillende delen:

• In het eerste vertel ik je een beetje wat agile methodieken zijn en hoe het allemaal begon. De theorie erachter en de bijbehorende concepten.
• In het tweede deel leg ik je uit hoe ik de onderdelen van deze methodiek die ik goed vind toepas in marketingteams, zodat je ze, als je interesse hebt, vanaf vandaag in je eigen team kunt gebruiken. Het praktische en operationele deel.

Als je het eerste deel al kent, kun je direct hierheen springen.

Laten we bij het begin beginnen.

Deel 1: Waar de Agile-methodiek uit bestaat

Het is een benadering van besluitvorming in projectmanagement die de nadruk legt op het ontwikkelen van functionaliteit incrementeel en iteratief, waarbij elke cyclus meer waarde oplevert voor de gebruiker / klant.

Ze ontstond eerst in softwareontwikkeling en werd kort daarna toegepast op andere gebieden, zoals het beheer van allerlei projecten (niet alleen software), productontwikkeling, UX en marketing.

Ze verzet zich tegen watervalmodellen -waarbij een deel van het project eerst af moet zijn voordat het volgende kan beginnen- omdat die te bureaucratisch worden gevonden, en legt veel nadruk op communicatie tussen de betrokken partijen, boven documentatie.

Klinkt goed, toch? Maar misschien vraag je je af hoe dit allemaal is ontstaan.

Dat ga je nu zien.

Geschiedenis van de Agile-methodiek

In het midden van de jaren 90 ontstond een stroming die zich verzette tegen gestructureerd projectmanagement, wat in 2001 uitmondde in een bijeenkomst in Snowbird, Utah.

Daar werd voor het eerst de term “Agile Methodology” gebruikt, werd de “Agile Alliance” opgericht en werd het “Agile Manifesto” gepubliceerd, waarin de principes van de methodiek staan.

Het Agile Manifest

Je kunt het originele document hier lezen:

http://agilemanifesto.org/

De vier waarden van het Manifest

Zoals je in de bovenstaande link hebt kunnen zien, staat in het document:

“We ontdekken betere manieren om software te ontwikkelen door het zelf te doen en anderen daarbij te helpen. Door dit werk zijn we gaan waarderen:

• Individuen en interacties boven processen en tools
• Werkende software boven uitgebreide documentatie
• Samenwerking met de klant boven contractonderhandeling
• Reageren op verandering boven het volgen van een plan

Dat wil zeggen: hoewel de zaken rechts waarde hebben, hechten we meer waarde aan de zaken links.”

En deze vier waarden worden uitgewerkt in deze twaalf principes.

De twaalf principes van het Agile Manifest

Je vindt ze hier:

http://agilemanifesto.org/principles.html

Maar ik kopieer ze voor je:

1. “Klanttevredenheid. Dat is de basis van alles. Die bereik je door waardevolle producten te leveren die in een behoefte voorzien.
2. Nieuwe eisen zijn welkom. Onderweg veranderen is geen stap terug. Elke suggestie of oplossing is welkom als die het product verbetert.
3. Wekelijkse opleveringen. Het opdelen van werk in productieve fasen is de basis van de methodiek. Voer er waar mogelijk elke week één uit.
4. Vooruitgang is meetbaar. De ontwikkeling van processen is niet subjectief. Ze kan met concrete indicatoren worden gemeten.
5. Duurzame ontwikkeling. De manier waarop projecten worden uitgevoerd moet op zichzelf de continuïteit ervan garanderen. Het gaat niet om bezig zijn om bezig te zijn.
6. Nauw samenwerken. Projectleiders moeten hun werk doen op de plek waar de taken plaatsvinden, niet vanuit hun kantoor.
7. Gesprek van aangezicht tot aangezicht. De verantwoordelijke manager moet boodschappen effectief overbrengen, liefst persoonlijk. Regelmatige bijeenkomsten met zowel de klant als medewerkers worden aanbevolen.
8. Motivatie en vertrouwen. Processen slagen alleen als de mensen die ze uitvoeren gemotiveerd zijn en samenwerken in een klimaat van vertrouwen en solidariteit.
9. Technische excellentie en goed ontwerp. De vorm mag nooit verloren gaan, net zo min als de kwaliteit van het werk. Alles vormt één geheel.
10. Eenvoud. Taken moeten zo eenvoudig mogelijk zijn. Als een taak niet in die vorm kan worden uitgevoerd, moet ze in iteraties worden opgesplitst totdat de complexiteit is verminderd.
11. Zelfsturing van teams. Hoewel er iemand moet zijn die de teams monitort, moeten die zichzelf kunnen organiseren. Te veel hiërarchie creëert afhankelijkheid tussen medewerkers.
12. Aanpassen aan veranderende omstandigheden. Projecten eindigen meestal niet op dezelfde manier als ze begonnen. Het is essentieel dat degenen die ze uitvoeren zich kunnen aanpassen aan de verschillende omstandigheden die kunnen ontstaan.”

Ik weet niet wat jij ervan vindt, maar als je ooit betrokken bent geweest bij de ontwikkeling van digitale producten, is het moeilijk om het er niet mee eens te zijn met werkelijk alle punten.

Heel moeilijk.

Zozeer zelfs dat deze methodiek tegenwoordig, gezien het nut in haar oorspronkelijke domein, zoals gezegd is overgeheveld naar het beheer van allerlei projecten en zelfs sectoren.

Er wordt gesproken over “Agile Product Design”, “Agile Marketing” en “Agile Management”, waarbij steeds de nadruk wordt gelegd op:

• Communicatie van aangezicht tot aangezicht.
• Transparantie.
• Klanttevredenheid.
• Eenvoud.
• Incrementele ontwikkeling en voortdurende verbetering.

Begin je de methodiek al aantrekkelijk te vinden?

Laten we naar de onmisbare elementen gaan.

Basiselementen en concepten van de Agile-methodiek

Goed. Alles wat tot nu toe is uitgelegd klinkt prachtig, maar om ermee te beginnen moeten we de theorie naar de praktijk brengen en de verschillende elementen uitleggen die planning en uitvoering mogelijk maken.

Het framework

Hoewel alle agile methodieken dezelfde principes en waarden delen, past elke methodiek ze op een andere manier toe.

En die verschillende manieren om dingen te doen zijn de verschillende frameworks of referentiekaders.

Er zijn er meerdere, elk met eigen regels, voordelen, aanbevelingen en nadelen. De twee meest voorkomende en bekende zijn Kanban en Scrum.

Kanban

Het ontstond in Japan na de Tweede Wereldoorlog, die het land in een economische en technologische ramp had gestort.

In de jaren 50 ontwierp Toyota een productiesysteem “just in time” (JIT) waarin elk onderdeel precies op het juiste moment werd gemaakt, niet eerder en niet later, en dat het omschreef als “zeer effectief en efficiënt”.

Om dit uit te voeren, werkten ze met kaarten die de materiaalbehoeften in de productieketen aangaven.

Deze methodiek neemt dus het idee van kaarten over en stelt elke kaart gelijk aan een taak.

Er wordt een bord met één kolom per status gemaakt waar een taak doorheen moet, bijvoorbeeld:

• Gedefinieerd.
• In uitvoering.
• Afgerond.
• Gecontroleerd.

Dit is een voorbeeld van een eenvoudig bord, maar het kan zo complex worden gemaakt als het project vereist. Een complexer bord zou bijvoorbeeld kunnen zijn:

• Definitie.
• Analyse.
• Ontwikkeling
• Tests.
• Naar productie.
• Documentatie.

Het bord verschilt per bedrijf of team, afhankelijk van de behoeften, en is toepasbaar op zowel nieuwe ontwikkelprojecten (“de blog lanceren”, “een TikTok-kanaal openen”) als onderhouds taken (“de banners van de website controleren”) of terugkerende taken (“affiliatecommissies controleren”, “wekelijkse ecommerce-reporting”).

Het bord kan fysiek zijn (dat wordt aanbevolen zodat het zichtbaar en transparant is voor het hele team) of digitaal, en daar komt Trello in beeld.

Scrum

Het lijkt op de vorige aanpak omdat, zoals ik al zei, de principes en filosofie waarop ze zijn gebaseerd hetzelfde zijn.

De naam kun je vertalen als “scrum” en komt uit rugby, wanneer het hele team samenkomt.

Ze verschillen in kleine nuances, misschien omdat Scrum als restrictiever wordt gezien en in mijn ervaring meer gericht is op digitale productontwikkeling:

• Beveelt multidisciplinaire teams aan. Bij Kanban zijn gespecialiseerde teams toegestaan.
• Specifieke rollen: Scrum Master, Product Owner en het ontwikkelteam zijn in Scrum verplicht; in Kanban kun je ze wel of niet hebben
• Iteraties met een vaste duur (tussen 1 en 4 weken): de sprints (hier wordt veel nadruk op gelegd).
• Wijzigingen: wat in een sprint zit, staat vast en gewenste wijzigingen worden uitgesteld tot de volgende sprint om het burnproces of Burndown te kunnen meten (zo simpel is het niet helemaal). In Kanban zijn wijzigingen eenvoudiger uit te voeren, omdat een functionaliteit met lagere prioriteit kan worden vervangen door de nieuw gewenste.
• Ceremonies met een vaste duur.
• Nieuw bord in elke sprint versus het blijvende Kanban-bord.

Om al deze redenen geef ik persoonlijk voor Agile Marketing de voorkeur aan Kanban, en die ga ik in dit artikel uitleggen.

Sterker nog, het is niet het meest gebruikelijk, maar ik heb hybride modellen gezien en ermee gewerkt:

• Scrum gebruiken voor nieuwe ontwikkelingen en Kanban voor terugkerende taken binnen hetzelfde team. Dat hadden we bij Lowi.
• De “Scrumban”-methodiek, die onderdelen van beide leent.

User stories

Misschien wel de kern van de methodiek.

Het is een eenvoudige manier om een beknopte taak te beschrijven die waarde oplevert voor de gebruiker of klant.

Ze worden meestal op kaarten geschreven (met de hand op post-its of digitaal) en bevatten:

1. Titel: kort, om ernaar te kunnen verwijzen.
2. Beschrijving: Als [gebruikersrol] wil ik [functionaliteit] zodat [Doel van het verhaal]. Voorbeeld: "Als bloggebruiker wil ik aan het einde van het artikel gerelateerde artikelen zien, zodat ik verder kan lezen over onderwerpen die me interesseren“.

Daarnaast moeten ze deze kenmerken hebben:

1. Onafhankelijk: van elkaar. Ze moeten afzonderlijk kunnen worden aangepakt, ook als ze samenhangen. In een advertentiecampagne wordt bijvoorbeeld de ontwerptaak gescheiden van de copywritingtaak, hoewel beide natuurlijk wel met elkaar te maken hebben.
2. Onderhandelbaar: bereik en details worden tussen beide partijen afgesproken en zo nodig opnieuw onderhandeld, bijvoorbeeld door de taak in twee delen te splitsen.
3. Waardevol: ze moeten echte, tastbare waarde voor de klant opleveren.
4. Schatbaar: dat wil zeggen dat de benodigde inspanning voor uitvoering kan worden geanalyseerd. In tijd of ontwikkelpunten.
5. Klein: als ze te groot zijn en niet kunnen worden geschat, moeten ze worden opgesplitst.
6. Verifieerbaar: testbaar, met binaire acceptatiecriteria (geslaagd of niet geslaagd).

Zodra de taak is opgesteld, wordt ze in de begin kolom van het bord geplaatst en bij elke statuswijziging tussen de kolommen verplaatst.

De Backlog

Dit is de verzameling projecttaken die al zijn opgesteld en nog moeten worden aangepakt.

Het Team

Afhankelijk van de methodiek is het wel of niet noodzakelijk om bepaalde rollen in het team te hebben.

In Scrum heb je bijvoorbeeld doorgaans:

• Product Owner: bedrijfsmatig verantwoordelijke voor het product.
• Scrum Master: probleemoplosser en facilitator van de ontwikkeling. Die kan wel of niet de teamleider zijn.
• Ontwikkelteam / specialisten (UX, designers, SEO…): in feite de mensen die het grootste deel van de taken uitvoeren.
• Tech lead: technisch verantwoordelijke van het team. Dit kan dezelfde persoon zijn die de rol van Scrum Master vervult.
• QA: testen.

In Kanban zijn deze rollen niet noodzakelijk, hoewel het klopt dat hoe beter de rol van ieder teamlid is gedefinieerd, hoe makkelijker het wordt om de taak te beoordelen en daarna uit te voeren.

Sprints

De duur van een iteratie, cyclus of oplevering waarin één of meer geprioriteerde nieuwe functionaliteiten of verbeteringen (features) van een digitaal product worden uitgebracht, of de relevante taken van die cyclus worden uitgevoerd (“Instagram-content maken”).

Meestal duren ze tussen één en vier weken. Bij digitale productontwikkeling vaak twee of drie, terwijl ze in marketing prima één week kunnen duren.

Het Sprintdoel

Bij productontwikkeling hebben ze een Sprintdoel, dat het grootste deel van de functionaliteiten bundelt die men wil aanpakken.

Bij andere soorten projecten is zo'n doel niet altijd nodig.

Ceremonies

Zo worden de teamvergaderingen genoemd die bij de methodiek horen.

Dit zijn de meest voorkomende en elke heeft haar eigen duur, frequentie en doelen:

Ze dienen om ontwikkeling en processen iteratief te analyseren en te verbeteren

• Daily: dagelijks vertellen de teamleden heel kort wat ze die dag gaan doen en of iets een eerdere taak blokkeert, zodat kan worden besproken welke stappen nodig zijn om de blokkade weg te nemen. Dit zou ongeveer vijf minuten moeten duren.
• Sprint plan: aan het einde van de lopende sprint komt het team bijeen om te bespreken hoe de volgende sprint wordt aangepakt en om de taken te schatten.
• Refinement: dit is de stap vóór de vorige ceremonie. Bij refinement moet elke story duidelijk en begrijpelijk genoeg zijn voor het team en moet de scope zijn gedefinieerd zodat ze in de Sprint plan kan worden geschat.
• Retrospective: na afsluiting van de sprint wordt bekeken hoe het is gegaan, welke problemen we zijn tegengekomen en welke verbeterpunten voor toekomstige sprints kunnen worden meegenomen.

Als we het over marketing hebben: zijn al deze ceremonies noodzakelijk?

Later geef ik je mijn antwoord, want hier eindigt de theorie.

Nu leg ik uit hoe ik dit vanaf nul in verschillende teams en projecten heb toegepast.

Je zult bovendien zien dat de aanpak heel eenvoudig is en dat er geen radicale veranderingen of nieuwe tools nodig zijn om agile principes te gaan toepassen.

Deel 2: Het implementatieproces van de Agile-methodiek in Marketing

Als je nog nooit ervaring hebt gehad met agile methodieken, wil ik eerst dat je het manifest en de principes meerdere keren leest, want eigenlijk is dat al genoeg om enkele concepten te begrijpen en toe te passen.

Het gaat om een mentaliteitsverandering waarbij ik zou zeggen dat het belangrijkste is praten en afspraken maken tussen de betrokken partijen (leidinggevenden, je eigen team, externe teams…) in de wetenschap dat iedereen hetzelfde gemeenschappelijke doel nastreeft.

Ten tweede, flexibel zijn. Begrijpen dat veranderingen zullen komen en dat je ze moet accepteren. Ook als ze irritant zijn. Dat betekent niet altijd “toegeven”, maar teruggaan naar het vorige punt: praten en afspraken maken.

Ten derde en tot slot, meten. Want meten is de enige manier waarop we kunnen weten hoe optimaal onze prestaties zijn, die van ons team, en of alle acties die we uitvoeren echt de moeite waard zijn.

Goed, als dat eenmaal goed in je hoofd zit, laten we het over het systeem hebben.

Het Agile Marketing-systeem

Het idee erachter is dat je team in staat is om een beperkt aantal taken binnen een bepaalde tijd.

uit te voeren. Die periode noemen we een sprint en om te beginnen is het het eenvoudigst als die één week duurt.

Je zult dus een systeem moeten organiseren zodat elke week (sprint) het juiste aantal taken wordt uitgevoerd.

Hoeveel taken zijn dat? In het begin weet je dat niet, want je hebt geen historie. In de eerste sprints kun je dus hooguit proberen te schatten met een bepaalde foutmarge, die kleiner wordt naarmate jij en je team meer ervaring opdoen.

Bovendien hebben jullie nog geen ervaring met het formuleren van taken, wat de schatting nog een extra moeilijkheidslaag geeft.

Maar geen zorgen, die onzekerheid duurt niet lang: zodra je een aantal sprints hebt gedaan, hebt gemeten en weet hoe je taken goed formuleert, heb je gegevens waarmee je elke taak veel beter kunt schatten.

Nu je weet hoe dit zich zal ontwikkelen, is het eerste wat je nodig hebt een tool waarin je de backlog kunt maken en alle taken van de sprint kunt noteren.

De tools voor Agile Marketing

Je hebt verschillende opties, afhankelijk van of je online of offline verkiest.

Voordelen van elk type?

Online tools zijn directer en kunnen nauwelijks iets kosten, terwijl offline oplossingen in feite bestaan uit een bord en wat post-its, en voor het hele team heel duidelijk maken waaraan wordt gewerkt en dat werk zichtbaar waarderen richting de organisatie.

Mijn advies?

Behalve in gevallen waarin het absoluut noodzakelijk is om glashelder te maken waar iedereen aan werkt, begin met een online tool.

Ik raad je er twee aan, afhankelijk van hoe overtuigd je bent van het systeem: Excel als je het wilt proberen en Trello als je ervan overtuigd bent dat dit iets voor jou is.

Agile Marketing met Excel

Ik zeg Excel omdat het het meest verspreid is, maar elke spreadsheet (Google Sheets, LibreOffice…) is prima.

Het idee hier is niet zozeer om over Kanban en borden te praten, maar om agile principes vanaf nu toe te passen.

Daarvoor maak je een document waarin je alle uit te voeren taken onder elkaar toevoegt. Dat wordt je Backlog.

Daarnaast maak je een reeks kolommen die je helpen elke taak te definiëren, te plannen en de teamprestaties en de inspanning per type taak te meten:

In dit geval hebben we de volgende kolommen:

• Prioriteit: hoewel we de taken met de hoogste sprintprioriteit bovenaan zouden kunnen zetten, zouden we dan niet meer goed kunnen filteren, dus voegen we een kolom toe.
• Merk: als je met meerdere klanten of merken werkt, kun je hiermee per klant of merk segmenteren.
• Taken: hier voegen we alleen de titel toe, omdat dit over het algemeen taken zijn die we al kennen en die geen uitgebreidere beschrijving nodig hebben.
• Opmerking: als we toch meer detail nodig hebben, voegen we dat hier toe.
• Taaktype: hiermee kunnen we zien hoeveel tijd we aan elk verschillend soort werk besteden en analyseren:
• Of de geïnvesteerde tijd de moeite waard is.
• Of de uitvoeringstijd afneemt naarmate de persoon meer ervaring krijgt met hetzelfde type taak.
• Persoon: simpelweg, wie de taak gaat uitvoeren.
• Taakstatus: Niet begonnen, Begonnen of Afgerond.
• Invoerdatum: de startdatum van de sprint, waarmee we kunnen filteren wat in elke sprint wordt gedaan.
• Start: datum waarop de taakstatus verandert van Niet begonnen naar Begonnen.
• Starttijd: het tijdstip waarop een taak begint.
• Eindtijd: het tijdstip waarop een taak eindigt.
• Inspanning in uren: het verschil tussen de Starttijd en de Eindtijd.
• Week: om te weten welke week van het jaar het is en later te kunnen vergelijken of grafieken te maken.

Elke sprint zouden de nieuwe taken worden toegevoegd met hun Invoerdatum, en door op die datum te filteren zouden we de nieuwe sprint hebben ingesteld.

Als er natuurlijk nog openstaande taken uit andere sprints zijn, voegen we de datum van de vorige sprint toe aan het filter zodat de taken uit beide verschijnen.

Deze methode werkt zolang we geen taken hebben die langer dan 2 sprints blijven staan; anders stapelen ze zich te veel op en hebben we een ander systeem nodig, bijvoorbeeld een nieuwe taak in de nieuwe sprint die de niet-afgeronde taak uit de vorige sprint vervangt.

Goed, met een sjabloon als dit is meer dan genoeg om te beginnen met plannen en de drie pijlers van agility toe te passen: afspraken maken, flexibel zijn en meten.

Als je er dan een tijdje mee werkt -en ziet dat het werkt-, wil je misschien een stap verder gaan. Dan wordt het tijd om van tool te veranderen…

Agile Marketing met Trello

Om te beginnen heb je hier een tutorial om met de tool aan de slag te gaan.

Nadat je die hebt gelezen en je account hebt aangemaakt, moet je weten dat ik ook dit artikel heb gepubliceerd over hoe je Trello gebruikt om de Kanban-methodiek toe te passen in marketing, waarin ik er uitgebreider op inga, maar hier alvast een paar aanwijzingen:

1. Maak om te beginnen maar één bord. Dat is veel makkelijker te beheren als je net start.
2. Maak op dat bord 3 of 4 kolommen, niet meer. Dat kunnen zijn:
• Backlog: de backlog met alle taken, zowel die van de lopende sprint als alle andere die voor toekomstige sprints worden toegevoegd.
• To do: verplaats de taken die in deze sprint worden uitgevoerd van Backlog naar deze kolom. De taken met de hoogste prioriteit staan bovenaan.
• Doing: zodra de sprint is begonnen, verplaatst de verantwoordelijke persoon een taak bij het starten van To do naar deze kolom.
• Done: zodra een taak is afgerond, wordt ze van Doing naar deze kolom verplaatst.
3. Als een taak door iemand anders dan de uitvoerder moet worden gevalideerd, zouden we een vijfde kolom “Validated” toevoegen.
4. Zodra de sprint is afgesloten, worden alle voltooide taken gearchiveerd en beginnen we de taken van de nieuwe sprint in To do te plaatsen.

Makkelijk, toch?

Nu hoeven we alleen nog de analyselaag toe te voegen: bekijken wat er is gebeurd als iets niet afkwam, of het probleem lag bij de capaciteitsanalyse van het team, de formulering van de taak, de inschatting van de taak…

En een manier om dat aan te pakken is via de ceremonies.

Ceremonies van Agile Marketing

In het theoriedeel hebben we over vier ceremonies gesproken:

• Daily.
• Sprint plan.
• Refinement.
• Retrospective.

Elke ceremonie heeft heel duidelijke doelen, maar volgens mij zijn ze sterk gericht op digitale productontwikkeling en zijn ze in marketing niet allemaal onmisbaar.

In werkelijkheid hangt het ook af van de grootte van het team, want hoe groter het team, hoe noodzakelijker het wordt om orde te scheppen en te luisteren.

Dat gezegd hebbende, geef ik je mijn mening over elk ervan:

De daily is onmisbaar. En dat is zo omdat ze enorm helpt om het team goed te laten functioneren en blokkades op te lossen, en omdat iedereen weet waar we staan.

De sprint plan is nuttig, al is die niet noodzakelijk als het team klein is (tot 3-4 personen).

En refinement, is nog makkelijker weg te laten, want als het team al een tijd samenwerkt, is geen aparte sessie nodig om dingen te verduidelijken die met een Slack-bericht of een telefoontje van 30 seconden tussen beide partijen kunnen worden opgelost.

De retrospectives zijn vooral nuttig als er tijdens de sprint een belangrijk probleem is geweest. Door de mening van elk teamlid te horen, kunnen we goede beslissingen voor verbetering nemen.

Dat gezegd hebbende, vind ik het niet noodzakelijk om ze na elke sprint te houden (zeker niet bij wekelijkse sprints), maar wel periodiek en, zoals gezegd, altijd wanneer zich een probleem van enige betekenis heeft voorgedaan.

Kortom, ceremonies zijn volgens mij een middel tot een doel, geen doel op zich, zoals ik soms heb meegemaakt.

Teamgrootte

Hoewel ik het tot nu toe beschreven systeem in teams van 10 mensen heb gebruikt, denk ik dat bij die omvang enkele aanpassingen nodig zijn.

Voor kleinere teams van tussen de 3 en 6 personen vind ik het daarentegen perfect.

Als je team nog kleiner is, denk ik niet eens dat Trello nodig is. Excel en Slack (of Telegram) zijn misschien meer dan voldoende.

Voordelen van Agile Marketing

Het grootste voordeel is voor mij het kunnen hebben van een overzicht van alle taken in elke sprint, zodat duidelijk is welke we halen en welke moeten worden uitgesteld. Prioriteren en taken aan mensen toewijzen is heel eenvoudig.

Voor de organisatie is dit geweldig, vooral omdat het team weet wat het moet doen en zich kan concentreren daarop.

Het volgende voordeel is dat we, zodra het systeem is geïmplementeerd, elk type taak kunnen meten en analyseren. Als je de inspanning vergelijkt met de bijdrage aan de business, ontdek je misschien tot je verbazing dat je stopt met taken die je al jaren uitvoert (“Facebook-posts”).

Of ontdek je aan welke persoon in het team je elke taak het best kunt toewijzen.

Een ander voordeel is dat, vooral bij Trello in plaats van Excel, alles gedocumenteerd, waardoor we een echte repository binnen handbereik hebben.

Tot slot kan, als dat nodig is, zoals eerder gezegd, een goed gevuld bord of een goed onderhouden backlog de waarde van het uitgevoerde werk zichtbaar maken voor het team.

Tot slot zijn de kosten van dit alles laag:

• In geld, omdat de tools gratis of goedkoop zijn.
• In tijd, want hoewel de werklast iets toeneemt, hoop ik duidelijk te hebben gemaakt dat het ruimschoots de moeite waard is.

Conclusies

Hoewel het artikel behoorlijk lang is, heb ik nauwelijks aan het oppervlak van de Agile-methodiek gekrabd.

Het is een introductie zodat je kunt beoordelen of dit iets voor jou kan zijn of dat je huidige systeem beter bij je past.

Los van systemen wil ik in elk geval dat je vooral onthoudt wat voor mij de drie belangrijkste waarden:

• Praten en afspraken maken tussen de betrokken partijen.
• Flexibiliteit.
• Meten.

Ervan uitgaande dat we duidelijk hebben dat het er uiteindelijk om gaat het werk / project vooruit te krijgen.

Dat gezegd hebbende, hoop ik dat ik je heb kunnen uitleggen welke waarde het toepassen van de Agile-methodiek in Marketingteams heeft, want goed uitgevoerd levert het echt veel op. Dat zeg ik uit eigen ervaring.

Dus doe me een plezier en geef het een kans.

Hoe dan ook, hoewel ik absoluut geen Scrum Master ben, kun je me gewoon schrijven als je denkt dat je hulp nodig hebt bij het organiseren van je team voor digitale projecten.