Kan indholds-produktion være agil?
Kan kommunikation og marketing få mere ud af indholdet ved at tænke processer mere agilt. Kan man oversætte metoder til software-udvikling til den måde, vi arbejder med indhold. Jeg er langt om længe stødt nogen, der tror på sagen og viser os, hvad der skal til.
Kender du det, man har det på fornemmelsen, (altså i dette tilfælde at agil metode kan bruges til meget mere end at udvikle funktionalitet og sikre kvalitet og relevans i softwareudvikling.) Og så dukker den op; artiklen, der går i dybden med hvordan. Den kan læses hos mckinsey.com, og det er pænt interessant. Deres fokus er at marketing kan få værdi ud af at tænke processer og samarbejde agilt.
Uden at tage mere ære for det, end at jeg synes, at det er en blændende god idé, tillader jeg mig at ridse nogle af artiklens pointer op. Fordi jeg tror at det kan tænkes bredere end i en marketingskontekst. Vi kan som virksomheder og organisationer få mere ud af det indhold, vi producerer, hvad enten det kommer fra Marketing, Kommunikation, Web, Social Media eller fra fagmedarbejdere i virksomheden. Og det kan vi ved at lære af de agile metoders framework.
Agil metode tilbyder værktøjer til:
at prioritere opgaver
at holde fokus på produktets værdi og kvalitet
at definere rollerne i samarbejdet mellem forskellige fagligheder
at give et format og sprog til samarbejdet og samarbejdsprocesserne
at sikre fremdrift og tempo i udviklingsprocesser
Kan vi bruge det i arbejdet med indhold, ja det tror jeg nok vi kan. Hvem kender ikke til langtrukne diskussioner om, hvem der ved bedst om hvad der virker og ikke virker. Konflikter der opstår når fagligheder mødes og at verden når at løbe forbi os, inden vi er udkommet med indhold, der rent faktisk får målgruppen i bevægelse?
"using data and analytics to continuously source promising opportunities or solutions to problems in real time, deploying tests quickly, evaluating the results, and rapidly iterating"*
Det agile Team
McKinsey-artiklen beskriver, hvordan det agilt arbejdende Team sammensættes, og hvilke opgaver Teamet løser. Her oversat (af mig) i en lidt bredere kontekst, hvor opgaven er indholdsproduktion generelt.
Teamet bør have:
8-12 deltagere. Kompetencerne bør være inden for indsamling og fortolkning af data/analytics, indholdsproduktion og dybt kendskab til kanalers kendetegn og udvikling af disse.
Et klart mål for indholdsproduktionen. Målet bør etableres omkring Kundens møde med virksomheden og være meget konkret: Flere abonnenter til nyhedsbrevet, mindre frafald i købsprocessen, højere tilfredshed med ydelsen eller lign.
Klare kommunikationslinjer til interne interessenter og bidragydere.
Klart definerede roller - inden for SCRUM arbejder man med såkaldte artefakter: faste møder, tavler, roller og måder man byder ind med løsninger i processen.
En Scrum Master, hvis rolle det er at lægge planen, sikre at den overholdes og rydde hindringer af vejen. (Artiklen nævner det ikke, men min erfaring er, at det kan være en fordel også at have en Product Owner; én der kender forretningens prioriteringer og har det endelige ord i beslutninger.)
Teamets arbejde er bygget op omkring en fast cyklus (der kører over f.eks. 2-3 uger), den består altid af:
At sætte et klart mål og sikre mandatet i organisationen
Analysere data og viden og identificere potentielle udviklingsområder
Opsætte hypoteser og teste det nødvendige
Udkomme med MVPs (minimum viable products) og iterere videre derfra på baggrund af brugerfeedback og yderligere test
Skalere (f.eks. ved at automatisere håndholdte flows, der virker) og sikre at organisationen lærer fortløbende.
Kan man gradbøje agil?
Selvom jeg i reglen er tilhænger af pragmatiske løsninger, som i: "Prøv det nu bare og se hvad der virker." Så har artiklen en vigtig pointe i, at hvis man ikke får indført agil metode rigtigt, så høster man heller ikke den værdi, man kan få ud at at tænke det konsekvent. Min erfaring med agil metode er, at det skal gøre lidt ondt før det virker. Ondt fordi vi bliver nødt til at forandre måden vi arbejder på.
"Simply put: if you’re not agile all the way, then you’re not agile"*
*Alle citater, kommer fra artiklen her
Læs evt også den fine introduktion til Scrum, hvor alle artefakter beskrives. Herunder hvor vigtigt det er at vide, hvornår man er gris, og hvornår man er kylling i et udviklingsprojekt.
Eller se indtroduktion til Leading SAFe, en anden måde at arbejde agilt på tværs af organisation og forretning: https://youtu.be/WZzeNQm7L0w (Bodil Brøndum Kirkelykke har været sød at gøre opmærksom på denne)