Practici agile: Cum să evităm greșelile făcute de echipa noastră de marketing

Publicat: 2020-12-22

greșeli-agil-marketing-echipă Secretul a ieșit. Managementul de proiect Agile este un schimbător de jocuri - iar dezvoltatorii și oamenii IT nu mai sunt singurii care știu despre asta.

Ca agent de marketing, cu siguranță ați auzit despre Agile. Este posibil ca echipa dvs. să utilizeze unele practici Agile, cum ar fi sprinturile de proiecte și întâlnirile stand-up. Dacă da, ești în minoritate. Beneficiile Agile sunt încă în mare parte neexploatate de echipele de marketing. Potrivit unui nou raport al Workfront și MarketingProfs, doar 30% dintre echipele de marketing folosesc o abordare Agile pentru a-și gestiona procesele. Ceilalți 70% experimentează probabil aceleași frustrări pe care le-a experimentat echipa mea înainte să ne angajăm să facem Agile să funcționeze.

Doar 30% dintre echipele #marketing folosesc o abordare #Agile pentru a gestiona procesele prin @workfront_inc @MarketingProfs. Faceți clic pentru a trimite un Tweet

Echipa noastră de marketing de șapte persoane de la Emplify practică Agile de aproape un an. Ne-au trebuit șase luni pentru a ajunge la un punct de a o practica bine: să producem muncă mai bine, mai repede și cu mai multă energie și implicare.

Când am început să practicăm Agile, am făcut multe greșeli. De fapt, atât de multe greșeli, încât am închis jumătate din echipa noastră într-o sală de conferințe într-o zi și nu am plecat până când nu am identificat și am remediat unele deficiențe semnificative în abordarea noastră. Din fericire, era bere și era vineri. Totuși, a fost dureros și a trebuit timp să ne scoatem din niște găuri adânci orientate spre proces.

În acest articol, împărtășesc acele greșeli, astfel încât să puteți evita un blocaj dureros ca al nostru. Agile vă pot revoluționa capacitatea echipei de marketing de a colabora și de a livra mai repede munca - dacă vă angajați să faceți ca procesul să funcționeze pentru dvs.

Înainte de a începe, să acoperim câteva elemente de bază:

Ce sunt practicile Agile?

Practicile agile (adesea denumite „Agile”) subliniază livrarea continuă a unor porțiuni mai mici de muncă în cadrul proiectelor cu sarcini interconectate mai mari care pot cuprinde săptămâni sau luni (ceea ce se numește în mod tradițional managementul cascadei).

Elementele de bază agile includ:

  • Echipa Scrum: Această echipă extrem de colaborativă, organizată sub un scrum master, rezolvă probleme complexe și oferă soluții în iterații cu lungime fixă ​​numite sprinturi, care pot dura de la o săptămână la 30 de zile. O echipă scrum care lucrează la conținut, de exemplu, ar putea începe un sprint de două săptămâni angajându-se să creeze o nouă infografică sau foaie de date.
  • Produs minim viabil (MVP): atunci când planificați un livrabil, principiile Agile subliniază scoaterea proiectului în natură cât mai repede posibil, astfel încât echipa dvs. să poată răspunde devreme la probleme reale. Pentru a realiza un model de livrare continuă, masteratii scrum încurajează echipele să definească MVP și să descopere cele mai creative moduri de a termina produsul în limitele sprintului. De exemplu, dacă începeți un sprint de două săptămâni pentru a crea o carte electronică ca MVP și designerul dvs. se îmbolnăvește, puteți decide să redefiniți MVP-ul sprintului ca o serie de postări pe blog și să proiectați cartea electronică în următoarea sprint.
  • Întâlnire zilnică de stand-up: membrii echipei stau într-un cerc timp de aproximativ 15 minute în fiecare dimineață pentru a discuta despre sarcinile îndeplinite ale echipei scrum, zonele de concentrare și blocanții care îi pot împiedica să-și termine activitatea de sprint. La sfârșitul sprintului, echipele Agile livrează un set definit de proiecte, care sunt apoi evaluate și îmbunătățite în următorul sprint. Unele echipe de scrum încorporează, de asemenea, întâlniri retrospective, unde discută deficiențele procesului care pot fi abordate în următorul sprint.

Greșeli de marketing agile_1

CONȚINUT RELATAT MANUAL:
30 de obiceiuri ale echipelor de conținut extrem de productiv [Infografie]

De ce marketerii ar trebui să folosească Agile?

National Public Radio folosește metodologii Agile pentru a crea și testa noi programe. Gândiți-vă la asta în timpul următorului dvs. „moment de acces”. Deși rădăcinile Agile se află în managementul IT, această formă de livrare a proiectelor poate fi aplicată multor funcții ale unei companii, inclusiv marketingului.

Adoptarea unui model Agile de iterație continuă permite echipei dvs. de marketing să testeze rapid mesaje noi sau campanii, să reacționeze mai rapid la actualizările de produse și să stabilească așteptări cu părțile interesate care solicită munca echipei dvs.

Momentul strălucitor al echipei mele a venit la aproape nouă luni după ce ne-am început călătoria Agile, când am reîmprospătat conținutul de pe site-ul nostru web pentru a face unele schimbări în mesajele noastre despre produse. Am definit ce am putea realiza într-o săptămână și am livrat acea lucrare în timp util. Conținutul pe care nu am avut timp să îl actualizăm în acel sprint, l-am ascuns de navigare. Am adăugat și actualizat continuu mesajele de pe acele pagini în timpul sprinturilor noastre ulterioare.

CONȚINUT RELATAT MANUAL:
Confuz cu privire la marketingul agil? Răspunsul la întrebările dvs. [Cu videoclip]

Ce greșeli ar trebui evitate?

Dacă vă gândiți să adoptați Agile în echipa dvs., chiar dacă doriți pur și simplu să eficientizați procesele din cadrul echipei dvs. de marketing, veți dori să evitați aceste patru greșeli de marketing Agile pe care le-a făcut echipa noastră:

  1. Ne-am numit Agile fără să ne facem temele.
  2. Nu am reușit să desemnăm proprietarii de probleme.
  3. Ne-am concentrat mai degrabă pe rezultate decât pe probleme.
  4. Am înghesuit în loc să acordăm prioritate (și ne-am prefăcut că putem face totul).

Greșeala 1: Ne-am numit Agile fără să ne facem temele

Când am început cu echipa mea de marketing, am instituit rapid stand-up-uri zilnice pentru a oferi o modalitate rapidă și nedureroasă de a face check-in la proiecte. M-am gândit că am condus stand-up-uri și am organizat sprinturi în roluri anterioare, așa că am avut experiență cu Agile, nu? Gresit.

Nu intrați la lucru într-o zi de luni și anunțați că „mergeți agil” așa cum am făcut-o eu. Doar pentru că lucrați în sprint-uri de două săptămâni și aveți stand-up-uri zilnice nu înseamnă că sunteți o echipă Agile. Frumusețea Agile este că oferă echipei dvs. puterea de a se angaja în proiecte împreună și de a defini o calitate livrabilă într-un domeniu de timp desemnat. Dacă încercați doar să înghesuiți cât mai multă muncă în două săptămâni posibil și să sacrificați calitatea pentru a trece peste linia de sosire, acea frumusețe este negată.

Înainte de a institui procese Agile în echipa dvs. de marketing, faceți-vă temele. Deschideți o carte sau două. Vă recomand să începeți cu Scrum de Jeff Sutherland (cunoscut de mulți drept unul dintre părinții Agile) și Hacking Marketing de Scott Brinker. De asemenea, citiți câteva dintre articolele excelente ale CMI despre marketingul Agile.

După ce v-ați făcut temele, acordați prioritate câteva modificări simple procesului dvs. existent pentru a începe să creați o abordare Agile care să funcționeze pentru echipa dvs.

Înainte de a institui procese #Agile în echipa ta #contentmarketing, fă-ți temele, spune @evacjackson. Faceți clic pentru a trimite un Tweet

Greșeala 2: nu am reușit să desemnăm proprietarii de probleme

Dacă următorul scenariu nu s-a întâmplat, puteți sări peste această secțiune; ați realizat o formă de nirvana de proces de marketing pe care încă nu am descoperit-o.

Ceilalți dintre voi, imaginați-vă acest lucru: sunteți 98% printr-un proiect de echipă majoră cu un termen clar și o intervenție surpriză intervine în ultima oră cu zeci de revizuiri. Apoi, echipa dvs. este forțată să prelungească proiectul cu încă două săptămâni în plus pentru a aborda aceste schimbări, deoarece nimeni nu poate argumenta că această parte interesată greșește.

Încă citești? M-am gândit eu.

Lipsa de proprietate definită a echipei noastre a fost cea mai mare piedică pentru progresul nostru ca departament de marketing Agile. Am fost copleșiți de muncă. Am fost frustrați când mai mulți actori au influențat calitatea proiectului. Și nu am scos nimic din ușă din cauza modificărilor și remediilor din ultimul moment.

Dacă echipa dvs. de marketing este ceva asemănător cu al nostru, vă luptați să știți cine este proprietarul final al unui proiect. Cine este persoana direct responsabilă de succesul unui livrabil? Cine stabilește rezultate măsurabile pentru o sarcină cu care echipa se poate alinia? Cine are nevoie ca acest proiect să aibă succes, ca să poată avea succes și în cele din urmă?

Pentru a preveni prelucrarea de ultim moment, desemnăm acum o astfel de persoană - un proprietar de probleme - fiecărui proiect.

Preveniți prelucrarea de ultim moment, atribuiți un proprietar de problemă fiecărui canal din #Agile #contentstrategy. @evacjackson Faceți clic pentru a trimite un Tweet

În fiecare trimestru, stabilim un obiectiv potențial calificat pentru vânzări pentru fiecare dintre principalele noastre canale de marketing: publicitate, evenimente, clienți potențiali de site-uri organice și așa mai departe. Apoi, fiecăruia dintre aceste canale i se atribuie un proprietar în echipa noastră, iar proprietarul respectiv devine persoana vizibilă pentru toate livrabilele care intră sub acel canal.

Proprietatea problemei a avut un succes deosebit pentru echipa noastră din mai multe motive:

  • Aceasta pune sarcina succesului pe o singură persoană , care este trasă la răspundere dacă obiectivele nu sunt îndeplinite.
  • Îl obligă pe proprietarul canalului să rezolve problemele mai devreme, astfel încât echipa să le poată aborda în mod proactiv.
  • Permite întregii echipe să fie implicată în brainstormingul unei soluții și implementarea unei soluții.
  • Împuternicește o persoană să ghideze calitatea oricărui proiect dat.

Dacă echipa dvs. nu știe clar cine are ultimul cuvânt în proiectele dvs. de conținut, stați la departamentul dvs. și puneți o întrebare descumpănitoare, dar provocatoare: „Cine deține ce?” Răspunsul la această întrebare - și înregistrarea răspunsurilor dvs. pentru ca toți să vadă - va crea o responsabilitate nemăsurată.

CONȚINUT RELATAT MANUAL:
Cum să evitați supraîncărcarea colaborativă în cadrul echipei dvs. de conținut

Greșeala 3: Ne-am concentrat mai degrabă pe rezultate decât pe probleme

Un alt moment de schimbare a jocului pentru echipa noastră Agile a fost când am încetat să ne uităm la munca noastră ca un set de livrări pe care să le punem la punct și am început să ne gândim la munca noastră ca la un set de probleme de rezolvat.

Gândiți-vă la contribuitorii individuali din echipa dvs.: dezvoltatori, redactori, designeri și alte roluri de implementare similare. Cât de des li se cere să „proiecteze acest diapozitiv” sau „să scrie această carte electronică” cu puțin context pentru motivul pentru care o fac?

Simpla repartizare a unei sarcini pe o listă de sarcini fără a vă ajuta echipa să înțeleagă scopul real din spatele proiectului duce la o muncă lipsită de lumină fără investiții personale din partea echipei dvs.

Atribuirea unei sarcini fără a ajuta echipa dvs. să înțeleagă scopul duce la o muncă lipsită de lumină, spune @evacjackson. Faceți clic pentru a trimite un Tweet

De fapt, lipsa muncii orientate spre scopuri poate avea implicații severe asupra mai multor tactici de marketing. Într-un sondaj realizat de membrii LinkedIn, mai mult de 60% dintre respondenții care nu aveau locuri de muncă orientate spre scop au planificat să-și părăsească compania în trei ani sau mai puțin.

60% + chestionați, care nu erau în locuri de muncă orientate spre scop, plănuiau să plece în 3 ani sau mai puțin. @LinkedIn @Imperative Faceți clic pentru a trimite un Tweet

În echipa noastră, avem o regulă puternică împotriva începerii oricărui proiect având în vedere un livrabil prescris. Să recunoaștem, părțile interesate nu știu întotdeauna ce vor. Rezolvarea problemelor ajută la încurajarea colaborării pentru rezultate mai bune.

În schimb, începem fiecare proiect cu o declarație de problemă, care urmează un format numit în mod regulat user stories în lumea Agile de dezvoltare. Acest format arată cam așa:

Când __________ se întâmplă, vreau să ________, astfel încât să obținem acest rezultat măsurabil: ___________.

Iată un exemplu al acestui tip de declarație de problemă (sau povestea utilizatorului) dintr-un proiect ipotetic:

Erori de marketing agile_2

Proprietarul problemei fiecărui proiect determină problemele pe care echipa le va aborda pentru acel proiect. De exemplu, proprietarul ar putea considera că este o problemă dacă site-ul web nu se clasează pentru un anumit cuvânt cheie sau dacă mesajele trebuie actualizate pentru o expoziție comercială viitoare. Indiferent de problemă, declarația problemei nu include niciodată o soluție. După ce decidem să prioritizăm o anumită problemă, echipa noastră analizează împreună problema, definind în cele din urmă o soluție pe care o putem executa în următorul nostru sprint.

Rezolvarea unei probleme ca echipă permite tuturor să aibă o miză în rezultat.

În plus, această abordare forțează echipa să descopere punctele de durere din spatele problemei la nivel de suprafață pentru a ajunge la o soluție care să răspundă nevoilor de bază, mai degrabă decât solicitărilor de vanitate.

De exemplu, echipa noastră de vânzări a raportat că unii clienți potențiali nu se prezentau la întâlnirile lor demo programate și nu răspundeau la solicitările de reprogramare. Vicepreședintele nostru de vânzări a dorit ca echipa de marketing să creeze un videoclip explicativ animat care să ofere perspective mai bune pentru întâlnirea lor, chiar dacă ar fi durat luni de zile.

După ce am pus câteva întrebări despre procesul de vânzare, ne-am dat seama că problemele esențiale ale echipei de vânzări ar putea fi rezolvate prin mesaje de e-mail îmbunătățite înainte de întâlnirea demonstrativă. Am instituit o campanie de degajare cu trei e-mailuri declanșată imediat ce este programată o întâlnire. Această soluție a durat doar două zile pentru a construi echipa. De la construirea acestei campanii, am redus cu peste jumătate numărul persoanelor care au nevoie să reprogrameze întâlnirile.

Înainte de a atribui o sarcină unui membru al echipei, întrebați-vă de ce contează acea muncă. Prin crearea unei declarații de problemă și colaborarea la o soluție, am reușit să identificăm o soluție rapidă care a plătit dividende pentru echipa noastră. Dacă am fi creat un videoclip animat, echipa de vânzări ar fi putut să se ocupe de aceeași problemă de luni de zile în așteptarea soluției noastre.

Greșeala 4: Am înghesuit în loc să acordăm prioritate (și ne-am prefăcut că putem face totul)

Dacă încercați să vă încadrați cât mai mult în fiecare sprint de marketing Agile, așa cum am făcut noi, faceți greșit.

Fără un sentiment comun de prioritate, nu aveți idee unde să vă concentrați timpul. Și fără concentrare, recurgi la a spune da tuturor. Și când spui da la toate și nu ai proprietari de probleme pentru proiectele tale, te găsești în grosul unui sfert stresant, cu o mulțime de livrări pe jumătate terminate.

Multe echipe Agile folosesc estimarea pentru a prioritiza munca și a crește viteza ca echipă. Acestea aproximează cantitatea de efort pe care o va necesita un proiect sau discută câte ore poate dura persoanele pentru a-și îndeplini sarcinile. De-a lungul timpului, multe echipe Agile ajung la un sentiment de producție medie pe sprint, ceea ce îi ajută să planifice noi sarcini.

În primele noastre luni ca echipă Agile, ne-am propus să facem acest tip de estimare. Din păcate, am ajuns să ne manipulăm estimările pentru a face să pară că putem face totul. Am ghicit cât de mult ar lucra un proiect și apoi am negat cerințele pentru a face loc pentru alte trei cereri. În cele din urmă, am negat valoarea estimării muncii, perpetuând un mediu de stres implacabil.

Am încercat două sau trei metode de urmărire a vitezei (inclusiv planificarea pokerului, un mod comun de estimare a muncii). Ne-am concentrat pe utilizarea estimării ca o modalitate de a demonstra că putem face multă muncă, nu ca o modalitate de a deveni o echipă mai eficientă. ASTA a fost greșeala noastră.

Recent am avut o discuție cu directorul de inginerie al companiei noastre, care gestionează procesul Agile pentru echipa noastră de produse. Când am menționat că echipa noastră nu stăpânise niciodată estimarea, el a spus acest lucru:

Dacă părțile interesate solicită în mod constant rapoarte de viteză sau estimări îmbunătățite de la echipa dvs., probabil că vă confruntați cu probleme de proces mai mari care afectează capacitatea echipei dvs. de a le livra la timp.

Aveți o problemă cu viteza #AgileMarketing - sau cu livrarea generală a proiectului? @evacjackson Faceți clic pentru a trimite un Tweet

Atunci când echipa Agile, care funcționează bine, furnizează în mod regulat iterații rapide ale unui proiect și semnalează preocupările părților interesate atunci când un termen limită nu este rezonabil, evitați în mod firesc întrebări despre rezultate sau productivitate în echipa dvs. Managerul de proiect sau masterul de scrum are responsabilitatea de a corecta cursul și de a comunica aceste schimbări atunci când munca este în urmă.

Nu vă fie teamă să acordați prioritate doar unul sau două proiecte noi (sau probleme sau povești) în următorul sprint, deoarece aveți câteva proiecte rămase în sprintul curent. Asigurați-vă că comunicați acele resturi în timp util părților interesate și împărtășiți planurile dvs. de finalizare a proiectului cât mai repede posibil.

Și nu vă fie teamă să desemnați un lider pentru a face apelul final la ceea ce trebuie prioritizat. Echipa noastră, de exemplu, a interzis tuturor oamenilor să mute cărțile Trello în coloana sprint „prioritară”, cu excepția vicepreședintelui nostru de marketing. Aceasta a plasat responsabilitatea de a acorda prioritate persoanei cu cea mai mare viziune asupra întregii afaceri.

Concluzie

Echipa noastră, ca orice echipă Agile, adaptează principiile Agile în moduri care funcționează pentru noi. Indiferent de abordarea agilă pe care o poate lua echipa dvs., aceasta va funcționa numai dacă oferiți oportunități de feedback deschis asupra procesului și dacă sunteți suficient de flexibil pentru a vă schimba fluxul de lucru în mod regulat. Dacă aș avea un jurnal al fiecărei modificări pe care le-am făcut până acum abordării noastre Agile, ar fi mai lung decât această postare.

Ce greșeli au făcut echipele dvs. atunci când au implementat procesele Agile? Cum ați abordat aceste greșeli? Spuneți-ne într-un comentariu.

Doriți să vă îmbunătățiți structura pentru eficiența marketingului de conținut? Înscrieți-vă la buletinul informativ săptămânal privind Strategia de conținut pentru specialiștii în marketing, care conține informații exclusive de la Robert Rose, consilier șef de conținut. Dacă sunteți ca mulți alți marketeri pe care îi întâlnim, veți veni să vă așteptați cu nerăbdare la gândurile sale în fiecare sâmbătă.

Imagine de copertă a lui Joseph Kalinowski / Content Marketing Institute