Pratiche agili: come evitare gli errori realizzati dal nostro team di marketing

Il segreto è svelato. La gestione agile dei progetti è un punto di svolta e gli sviluppatori e il personale IT non sono più gli unici a saperlo.

Come marketer, hai sicuramente sentito parlare di Agile. Il tuo team potrebbe utilizzare alcune pratiche Agile, come gli sprint di progetto e le riunioni in piedi. Se è così, sei in minoranza. I vantaggi di Agile sono ancora in gran parte inutilizzati dai team di marketing. Secondo un nuovo rapporto di Workfront e MarketingProfs, solo il 30% dei team di marketing utilizza un approccio Agile per gestire i propri processi. L'altro 70% probabilmente sperimenta le stesse frustrazioni provate dal mio team prima che ci impegnassimo a far funzionare Agile.

Il nostro team di marketing di sette persone in Emplify pratica Agile da quasi un anno. Ci sono voluti sei mesi per arrivare al punto di praticarlo bene: produrre un lavoro migliore, più velocemente e con più energia e impegno.

Quando abbiamo iniziato a praticare l'Agile, abbiamo commesso molti errori. Tanti errori, infatti, che un giorno abbiamo rinchiuso metà del nostro team in una sala conferenze e non ce ne siamo andati fino a quando non abbiamo identificato e risolto alcune carenze significative nel nostro approccio. Per fortuna c'era la birra ed era venerdì. Tuttavia, è stato doloroso e ci è voluto del tempo per scavare da alcuni profondi buchi orientati al processo.

In questo articolo condivido questi errori in modo che tu possa evitare un doloroso lock-in come il nostro. Agile può rivoluzionare la capacità del tuo team di marketing di collaborare e fornire lavoro più velocemente, se ti impegni a far funzionare il processo per te.

Prima di iniziare, esaminiamo alcune nozioni di base:

Cosa sono le pratiche Agile?

Le pratiche agili (spesso denominate "Agile") enfatizzano la consegna continua di porzioni più piccole di lavoro su progetti con attività interconnesse più ampie che possono durare settimane o mesi (che è tradizionalmente chiamata gestione a cascata).

Le basi dell'agile includono:

• Scrum team: questo team altamente collaborativo, organizzato sotto uno scrum master, risolve problemi complessi e fornisce soluzioni in iterazioni di durata fissa chiamate sprint, che possono durare da una settimana a 30 giorni. Un team di scrum che lavora sui contenuti, ad esempio, potrebbe iniziare uno sprint di due settimane impegnandosi a creare una nuova infografica o scheda tecnica.
• Prodotto minimo realizzabile (MVP): quando si pianifica un deliverable, i principi Agile enfatizzano la diffusione del progetto il più rapidamente possibile in modo che il team possa rispondere tempestivamente ai problemi reali. Per ottenere un modello di consegna continua, i master di scrum incoraggiano i team a definire l'MVP e a individuare i modi più creativi per completare il prodotto entro i confini dello sprint. Ad esempio, se avvii uno sprint di due settimane per creare un e-book come tuo MVP e il tuo designer si ammala, potresti decidere di ridefinire l'MVP di quello sprint come una serie di post sul blog e progettare l'e-book nel prossimo sprint.
• Riunione quotidiana in piedi: i membri del team stanno in cerchio per circa 15 minuti ogni mattina per discutere i compiti svolti dal team di Scrum, le aree di interesse e i blocchi che potrebbero impedire loro di completare il lavoro di sprint assegnato. Alla fine dello sprint, i team Agile forniscono una serie definita di progetti, che vengono poi valutati e migliorati nello sprint successivo. Alcuni team di scrum incorporano anche riunioni retrospettive, in cui discutono le carenze del processo che possono essere affrontate nello sprint successivo.

Perché i professionisti del marketing dovrebbero utilizzare Agile?

National Public Radio utilizza metodologie Agile per creare e testare la nuova programmazione. Pensaci durante il tuo prossimo "momento di strada privata". Sebbene le radici di Agile siano nella gestione IT, questa forma di consegna del progetto può essere applicata a molte funzioni di un'azienda, incluso il marketing.

L'adozione di un modello Agile di iterazione continua consente al team di marketing di testare rapidamente nuovi messaggi o campagne, reagire più rapidamente agli aggiornamenti dei prodotti e definire le aspettative con le parti interessate che richiedono il lavoro del team.

Il momento brillante del mio team è arrivato quasi nove mesi dopo che abbiamo iniziato il nostro viaggio Agile, quando abbiamo aggiornato il contenuto del nostro sito Web per apportare alcuni cambiamenti nella nostra messaggistica di prodotto. Abbiamo definito ciò che avremmo potuto realizzare in una settimana e abbiamo svolto il lavoro nei tempi previsti. Il contenuto che non abbiamo avuto il tempo di aggiornare in quello sprint, lo abbiamo nascosto alla navigazione. Abbiamo continuamente aggiunto e aggiornato i messaggi su quelle pagine durante i nostri sprint successivi.

Quali errori dovrebbero essere evitati?

Se stai pensando di adottare Agile nel tuo team, anche se stai semplicemente cercando di semplificare i processi all'interno del tuo team di marketing, ti consigliamo di evitare questi quattro errori di marketing Agile che il nostro team ha fatto:

1. Ci siamo definiti Agile senza fare i compiti.
2. Non siamo riusciti a designare i proprietari del problema.
3. Ci siamo concentrati sui risultati piuttosto che sui problemi.
4. Abbiamo stipato invece di dare la priorità (e abbiamo fatto finta di poter fare tutto).

Errore 1: ci siamo definiti Agile senza fare i compiti

Quando ho iniziato con il mio team di marketing, ho rapidamente istituito stand-up giornalieri per fornire un modo rapido e indolore per controllare i progetti. Ho pensato di aver condotto stand-up e organizzato sprint in ruoli precedenti, quindi ho avuto esperienza con Agile, giusto? Sbagliato.

Non entrare al lavoro un lunedì e annunciare che stai "diventando Agile" come ho fatto io. Solo perché lavori in sprint di due settimane e fai stand-up giornalieri non significa che sei un team Agile. La bellezza di Agile è che dà al tuo team il potere di impegnarsi in progetti insieme e di definire un prodotto di qualità entro un periodo di tempo prestabilito. Se stai solo cercando di stipare più lavoro possibile in due settimane e sacrificare la qualità per arrivare al traguardo, quella bellezza è negata.

Prima di istituire processi Agile nel tuo team di marketing, fai i compiti. Apri un libro o due. Consiglio di iniziare con Scrum di Jeff Sutherland (noto a molti come uno dei padri di Agile) e Hacking Marketing di Scott Brinker. Inoltre, leggi alcuni degli eccellenti articoli di CMI sul marketing agile.

Dopo aver svolto i compiti, dai la priorità ad alcune semplici modifiche al processo esistente per iniziare a creare un approccio Agile che funzioni per il tuo team.

Errore 2: non siamo riusciti a designare i proprietari del problema

Se il seguente scenario non si è verificato, puoi saltare questa sezione; hai raggiunto una qualche forma di nirvana del processo di marketing che devo ancora scoprire.

Il resto di voi, immagina questo: sei al 98% attraverso un importante progetto di squadra con una scadenza chiara e uno stakeholder a sorpresa interviene all'ultima ora con dozzine di revisioni. Quindi, il tuo team è costretto a prolungare il progetto di altre due settimane per affrontare questi cambiamenti perché nessuno può sostenere che questa parte interessata abbia torto.

Stai ancora leggendo? Così ho pensato.

La mancanza di una titolarità definita del nostro team è stata il più grande ostacolo al nostro progresso come reparto di marketing Agile. Siamo stati sopraffatti dal lavoro. Siamo stati frustrati quando più parti interessate hanno valutato la qualità del progetto. E non stavamo ottenendo nulla dalla porta a causa delle modifiche e delle correzioni dell'ultimo minuto.

Se il tuo team di marketing è qualcosa come il nostro, fai fatica a sapere chi sia il proprietario finale di un progetto. Chi è la persona direttamente responsabile del successo di un deliverable? Chi stabilisce risultati misurabili per un'attività a cui il team può allinearsi? Chi ha bisogno che questo progetto abbia successo in modo che anche lui o lei possa alla fine avere successo?

Per evitare rilavorazioni dell'ultimo minuto, ora assegniamo una persona del genere - un proprietario del problema - a ogni progetto.

Ogni trimestre, stabiliamo un obiettivo di lead qualificato per le vendite per ciascuno dei nostri principali canali di marketing: pubblicità, eventi, lead di siti Web organici e così via. Quindi, a ciascuno di questi canali viene assegnato un proprietario nel nostro team e tale proprietario diventa la persona di riferimento per tutti i risultati che rientrano in quel canale.

La proprietà del problema ha avuto un particolare successo per il nostro team per diversi motivi:

• Mette l'onere del successo su una persona , che è ritenuta responsabile se gli obiettivi non vengono raggiunti.
• Costringe il proprietario del canale a far emergere i problemi in anticipo in modo che il team possa affrontarli in modo proattivo.
• Consente all'intero team di essere coinvolto nel brainstorming di una soluzione e nell'implementazione di una correzione.
• Consente a una persona di guidare la qualità di un determinato progetto.

Se al tuo team non è chiaro chi ha l'ultima parola sui tuoi progetti di contenuto, siediti con il tuo dipartimento e poni una domanda incredibilmente semplice ma impegnativa: "Chi possiede cosa?" Rispondere a questa domanda - e registrare le tue risposte affinché tutti possano vederle - creerà un'incommensurabile responsabilità.

Errore 3: ci siamo concentrati sui risultati piuttosto che sui problemi

Un altro momento rivoluzionario per il nostro team Agile è stato quando abbiamo smesso di considerare il nostro lavoro come un insieme di risultati da realizzare e abbiamo iniziato a pensare al nostro lavoro come un insieme di problemi da risolvere.

Pensa ai singoli collaboratori del tuo team: sviluppatori, copywriter, designer e altri ruoli di implementazione simili. Quante volte viene chiesto loro di "progettare questa diapositiva" o "scrivere questo e-book" con poco contesto sul motivo per cui lo stanno facendo?

Assegnare semplicemente un'attività in una lista di cose da fare senza aiutare il tuo team a capire il vero scopo dietro il progetto porta a un lavoro poco brillante senza investimenti personali da parte del tuo team.

In effetti, la mancanza di un lavoro orientato allo scopo può avere gravi implicazioni non solo sulle tattiche di marketing. In un sondaggio tra i membri di LinkedIn, oltre il 60% degli intervistati che non svolgevano lavori mirati ha pianificato di lasciare la propria azienda entro tre anni o meno.

Nel nostro team, abbiamo una regola forte contro l'avvio di qualsiasi progetto con un deliverable prescritto in mente. Ammettiamolo, gli stakeholder non sempre sanno cosa vogliono. La risoluzione dei problemi aiuta a promuovere la collaborazione per ottenere risultati migliori.

Invece, iniziamo ogni progetto con una dichiarazione del problema, che segue un formato chiamato regolarmente user story nel mondo Agile di sviluppo. Quel formato ha un aspetto simile a questo:

Quando __________ accade, voglio ________, in modo da ottenere questo risultato misurabile: ___________.

Ecco un esempio di questo tipo di dichiarazione del problema (o user story) da un progetto ipotetico:

Il proprietario del problema di ogni progetto determina quali problemi il team affronterà per quel progetto. Ad esempio, il proprietario potrebbe considerare un problema se il sito Web non si classifica per una determinata parola chiave o se la messaggistica deve essere aggiornata per una fiera imminente. Indipendentemente dal problema, la dichiarazione del problema non include mai una soluzione. Dopo aver deciso di dare la priorità a un problema particolare, il nostro team analizza il problema insieme, alla fine individuando una soluzione che possiamo eseguire nel nostro prossimo sprint.

Risolvere un problema come una squadra consente a tutti di avere un interesse nel risultato.

Inoltre, questo approccio costringe il team a scoprire i punti deboli dietro il problema di livello superficiale per arrivare a una soluzione che soddisfi le esigenze fondamentali piuttosto che le richieste vanity.

Ad esempio, il nostro team di vendita ha riferito che alcuni potenziali clienti non si erano presentati alle riunioni dimostrative programmate e non rispondevano alle richieste di riprogrammazione. Il nostro vicepresidente delle vendite voleva che il team di marketing creasse un video esplicativo animato che sarebbe stato migliore per i potenziali clienti per il loro incontro, anche se per farlo sarebbero stati necessari mesi.

Dopo aver posto alcune domande sul processo di vendita, ci siamo resi conto che i problemi principali del team di vendita potevano essere risolti con una migliore messaggistica e-mail prima della riunione dimostrativa. Abbiamo istituito una campagna di gocciolamento di tre e-mail attivata non appena è programmato un incontro. La realizzazione di questa soluzione ha richiesto al team solo due giorni. Da quando abbiamo creato questa campagna, abbiamo ridotto di oltre la metà il numero di persone che hanno bisogno di riprogrammare le riunioni.

Prima di assegnare un compito a un membro del team, chiedetevi perché quel lavoro è importante. Creando una dichiarazione del problema e collaborando a una soluzione, siamo stati in grado di identificare una soluzione rapida che ha pagato i dividendi per il nostro team. Se avessimo creato un video animato, il team di vendita avrebbe potuto affrontare lo stesso problema per mesi in attesa della nostra soluzione.

Errore 4: abbiamo stipato invece di dare la priorità (e abbiamo fatto finta di poter fare tutto)

Se cerchi di inserirti il ​​più possibile in ogni sprint di marketing Agile, come abbiamo fatto noi, stai sbagliando.

Senza un senso di priorità condiviso, non hai idea di dove concentrare il tuo tempo. E senza concentrarti, ricorri a dire di sì a tutto. E quando dici di sì a tutto e non hai proprietari di problemi per i tuoi progetti, ti ritrovi nel bel mezzo di un trimestre stressante con molti risultati finali a metà.

Molti team Agile utilizzano la stima per dare priorità al lavoro e aumentare la velocità come team. Approssimano la quantità di impegno che un progetto richiederà o discutono di quante ore potrebbero essere necessarie alle persone per completare le loro attività. Nel tempo, molti team Agile arrivano a un senso dell'output medio per sprint, che li aiuta a pianificare nuove attività.

Nei nostri primi mesi come team Agile, abbiamo deciso di fare questo tipo di stima. Sfortunatamente, abbiamo finito per manipolare le nostre stime per far sembrare che avremmo potuto fare tutto. Abbiamo immaginato quanto lavoro avrebbe richiesto un progetto, quindi abbiamo contrattato i requisiti per fare spazio ad altre tre richieste. Alla fine, abbiamo negato il valore della stima del lavoro, perpetuando un ambiente di stress implacabile.

Abbiamo provato due o tre metodi per monitorare la velocità (inclusa la pianificazione del poker, un modo comune di stimare il lavoro). Ci siamo concentrati sull'utilizzo della stima come un modo per dimostrare che potevamo portare a termine molto lavoro, non come un modo per diventare un team più efficiente. QUELLO è stato il nostro errore.

Di recente ho avuto una chat con il direttore tecnico della nostra azienda che gestisce il processo Agile per il nostro team di prodotto. Quando ho detto che il nostro team non aveva mai padroneggiato la stima, ha detto questo:

Se i tuoi stakeholder chiedono costantemente rapporti sulla velocità o stime migliorate dal tuo team, probabilmente stai riscontrando problemi di processo più grandi che stanno compromettendo la capacità del tuo team di consegnare loro il lavoro in tempo.

Quando il tuo team Agile ben funzionante fornisce regolarmente iterazioni rapide di un progetto e segnala le preoccupazioni alle parti interessate quando una scadenza è irragionevole, eviti naturalmente domande sull'output o sulla produttività del tuo team. Il project manager o lo scrum master ha la responsabilità di correggere il corso e comunicare quei cambiamenti quando il lavoro è in ritardo.

Non aver paura di dare la priorità solo a uno o due nuovi progetti (o problemi o storie) nel tuo prossimo sprint perché hai alcuni progetti rimanenti nel tuo sprint corrente. Assicurati solo di comunicare tempestivamente alle parti interessate il lavoro avanzato e condividi i tuoi piani per completare il progetto il più rapidamente possibile.

E non aver paura di designare un leader per fare l'ultima chiamata su ciò che deve essere prioritario. Il nostro team, ad esempio, ha vietato a tutte le persone di spostare le carte Trello nella colonna dello sprint "prioritario" tranne il nostro vice presidente del marketing. Ciò ha posto la responsabilità di dare la priorità alla persona con la visione più ampia dell'intera azienda.

Conclusione

Il nostro team, come ogni team Agile, sta adattando i principi Agile in modi che funzionano per noi. Qualunque sia l'approccio Agile che il tuo team può adottare, funzionerà solo se fornisci opportunità di feedback aperto sul processo e se sei abbastanza flessibile da cambiare regolarmente il tuo flusso di lavoro. Se avessi un registro di ogni modifica apportata finora al nostro approccio Agile, sarebbe più lungo di questo post.

Quali errori hanno commesso i tuoi team durante l'implementazione dei processi Agile? Come hai affrontato quegli errori? Faccelo sapere in un commento.

Vuoi migliorare la tua struttura per l'efficacia del content marketing? Iscriviti alla nostra newsletter settimanale Content Strategy for Marketers, che presenta approfondimenti esclusivi di Robert Rose, chief content advisor. Se sei come molti altri marketer che incontriamo, verrai ad attendere con impazienza i suoi pensieri ogni sabato.

Immagine di copertina di Joseph Kalinowski / Content Marketing Institute