Ho lavorato nel marketing per quasi tutta la mia vita. Prima di iniziare a promuovere canali YouTube in One2, gestivo il dipartimento del servizio clienti nell’agenzia PROMO. Le innovazioni mi hanno sempre attratto, quindi l’incontro con la metodologia Scrum è stato solo una questione di tempo.
Il mio percorso verso la gestione dei progetti
Nell’agenzia pubblicitaria, sono diventato il leader di un dipartimento composto da account manager. Non c’era alcun sistema di gestione dei progetti. Non eravamo nei tempi giusti per l’adempimento dei nostri obblighi contrattuali o svolgevamo lavori di scarsa qualità. Così sono diventato un risolutore di problemi per affrontare il feedback negativo dei clienti. Era una strada senza uscita: non riuscendo a prevenire un problema, gestivo le sue conseguenze.
Ho iniziato a cercare un insieme di strumenti per affrontare la situazione. A quel tempo, non conoscevo Agile o Scrum, per non parlare dei modi per utilizzare la metodologia Scrum in team non IT.
Sono diventato un risolutore di problemi per affrontare il feedback negativo dei clienti.
Come abbiamo scelto la metodologia di gestione dei progetti
Inizialmente, abbiamo considerato il Kanban. È particolarmente utile per problemi di flusso come risoluzione di bug o elaborazione di domande in un call center. Ma per introdurre il Kanban, hai bisogno di un team altamente motivato e ben organizzato. Non era il nostro caso.
Abbiamo anche considerato il Waterfall. È utile per i team IT perché la chiara sequenza di fasi richiede meno codici, e si è sulla strada giusta. Lo stesso progetto in Scrum apparirà completamente diverso:
una cosa funzionante —> aggiustamento —> ottimizzazione
L’affidabilità del Waterfall nasconde il suo svantaggio: un alto rischio di disattendere le scadenze. Le aziende vogliono ottenere risultati il prima possibile piuttosto che aspettare un anno intero per essere persuase che la strategia scelta non funziona. Anche Scrum non è esente da questo “problema”.
Quali strumenti Scrum si adattano a un’agenzia di marketing
Scrum offre molti strumenti per aumentare la motivazione:
- tabelle Scrum. Le tabelle Scrum mostrano gli stati dei compiti e possono guidarti verso i punti problematici (ad es. troppi compiti sono in fase di discussione con i clienti). Abbiamo reso disponibili le tabelle Scrum per i nostri clienti per permettere loro di tracciare gli stati dei compiti. Ciò ha profondamente alleviato il carico dei nostri account manager.
- riunioni settimanali. Tutti i membri del team si alternano nel presentare i risultati dell’ultimo giorno, fare una promessa per la giornata attuale e condividere problemi. Grazie a queste riunioni quotidiane, puoi capire cosa sta accadendo nell’azienda e trovare il modo per rendere il lavoro più efficiente.
- pianificazione. Rende il processo lavorativo trasparente per il manager e per il cliente. Abbiamo invitato clienti specifici e deciso insieme quali compiti impostare per i prossimi sprint.
- retrospettiva. Possiamo capire gli errori che abbiamo commesso e i modi per correggerli (ad es. come aumentare il numero di compiti simultanei in corso senza compromettere la qualità).
- dimostrazione del prodotto. Presenta i progressi del team ottenuti durante lo sprint. Ogni membro del team mostra la propria parte del prodotto. La dimostrazione del prodotto consente di apportare modifiche rapidamente, migliorare il prodotto e non sprecare tempo con presentazioni premature del prodotto finito.
Il mio lavoro consisteva principalmente nell’analizzare il feedback negativo dei clienti. Dopo l’introduzione di Scrum, abbiamo iniziato a sondare le opinioni dei clienti per capire se la direzione del nostro movimento fosse corretta. Abbiamo migliorato l’indice di supporto al consumatore (NPS).
Quali sono gli svantaggi di Scrum per team non IT?
Scrum ha tre principali carenze:
- I processi aziendali diventano più costosi. Abbiamo introdotto la posizione di product owner, poiché nessun membro del team sarebbe in grado di gestire un ruolo così importante. Un tale specialista è costoso. Né il product owner né il Scrum master creano valore direttamente; sono al di fuori del team e, in sostanza, appartengono alla categoria delle spese generali.
- Non c’è un servizio di gestione dei progetti conveniente in Scrum per team non IT. In passato utilizzavamo Jira, ma la sua configurazione spesso richiede il coinvolgimento di uno specialista.
- La terminologia IT in Scrum non è adattata per le aziende non IT. Per le aziende IT, ci sono linee guida dettagliate che delineano i modi per rendere Scrum funzionante. Spiegano la terminologia: incremento è un prodotto funzionante, demo è dimostrare i modi in cui il prodotto funziona. Nel nostro caso, era poco chiaro come la scrittura di contenuti influisse sulle operazioni del prodotto. E cos’è un incremento in SEO? Se abbiamo scritto un testo e pubblicato sul sito – è un prodotto funzionante? Ci sono voluti più di tre mesi per adattare la terminologia IT alle nostre esigenze.
Come abbiamo fallito nell’introdurre Scrum
Abbiamo iniziato a introdurre Scrum con la formazione del team. E subito abbiamo fatto due errori.
Errore n. 1. Abbiamo incluso specialisti di pubblicità contestuale e SEO in un unico team. La logica è la seguente: fanno tutti traffico verso i siti web dei clienti e aumentano le vendite, il che significa che è opportuno lavorare insieme. Il team è unito attorno a un cliente.
Come abbiamo risolto il problema: dopo un po’ di tempo, abbiamo diviso gli specialisti per valori e prodotti. Alcuni clienti hanno avuto più account manager e team contemporaneamente.
Cosa abbiamo capito: un team dovrebbe essere unito attorno a un obiettivo aziendale. Tale team è autosufficiente e in grado di creare valore per il cliente da solo.
Errore n. 2. Non siamo riusciti a definire subito chi dovesse fungere da Scrum master e product owner.
Come abbiamo risolto il problema: abbiamo integrato la posizione del contabile di gruppo esistente con la funzione di Scrum master. Prima di ciò, era responsabile della produttività del team e dell’erogazione continua di valori al cliente. Abbiamo assunto una persona separata per essere il product owner.
Spesso incontro due errori nelle aziende che introducono anche Scrum:
- I team sono combinati attorno a una sola funzione. Un dipartimento è semplicemente rinominato in team. Il problema è che se un cliente ha bisogno di un sito web, il team deve avere un programmatore, un designer e un manager. Nessun dipartimento marketing composto da brand manager creerà un sito web.
- Le aziende hanno paura di distruggere la struttura esistente. Il seguente esempio era reale. Un account manager gestiva diversi progetti, ognuno dei quali era supportato da diversi specialisti SEO. I progetti erano distribuiti a seconda del carico di lavoro degli specialisti SEO. Supponiamo che uno specialista abbia ottenuto 10 progetti da gestire con priorità diverse. Le priorità vengono stabilite dal project manager, e questa azienda né aveva diversi. Nel migliore dei casi, lo specialista SEO soddisfaceva il compito più comprensibile, nel peggiore – il compito dell’account manager che urlava di più.
Unirsi in “team giusti” è un processo doloroso.
Perché abbiamo bisogno di un Scrum master?
Toyota ha un caso interessante per esemplificare il ruolo dello Scrum master. In fabbrica, alcuni lavoratori erano assegnati ad assistere un ingegnere meccanico per ottimizzare il lavoro. L’ingegnere meccanico veniva pagato a una tariffa oraria piuttosto alta, quindi le prestazioni dovevano essere aumentate e i costi ridotti. È stata notata l’esigenza dell’ingegnere meccanico di cercare la chiave giusta – allora un apprendista è stato assegnato per fornire chiavi. È stato concepito di facilitare ulteriormente il processo: stencil per gli strumenti sono stati dipinti sul pavimento e l’apprendista li disponeva al mattino prima del lavoro.
Quindi, un buon Scrum master garantisce l’80% del successo nell’introduzione di Scrum. Se ti manca una persona che possa assumere questo ruolo, trova chi è interessato a lavorare ulteriormente in questo campo. In ultima istanza, cerca uno Scrum master nelle aziende IT.
Lo Scrum master ha le seguenti funzioni non ovvie:
- Capire dove il team è sottoperformante, dove è possibile accelerare e dove è meglio rallentare. È come uno scudo contro le scadenze pressanti e il caos.
- Essere responsabile del senso di sicurezza del team. Include la protezione da un cliente che vuole “fare tutto per ieri”. Ad esempio, abbiamo affrontato questo problema: gli account manager stavano preparando report per i clienti a lungo. Su iniziativa dello Scrum master, abbiamo impostato report automatici generati in tempo reale. Ora il cliente non deve aspettare la fine del mese per capire come stanno le cose. Tutte le parti sono soddisfatte.
- Aumentare il livello del team per utilizzare Scrum tramite scelta volontaria.
- Comunicazione uno a uno con ciascun membro del team. Riguardo ai problemi e alle difficoltà dell’impiegato. In questo modo, i junior specialist raggiungeranno più rapidamente il livello medio, e i specialisti di livello medio cresceranno in senior. Il turnover del personale diminuirà.
Perché abbiamo bisogno di un product owner?
Non abbiamo capito subito chi dovesse diventare il product owner e di cosa si sarebbe occupato. Siamo giunti alla conclusione che il product owner è uno specialista tecnico con buone conoscenze del prodotto e capace di elaborare strategie contestuali e SEO, trasmettendole al cliente. In altre parole, è uno stratega che dice cosa deve essere fatto.
Cosa fa il nostro product owner?
- forma backlog;
- rimuove e stabilisce le priorità dei compiti;
- regola le strategie in base ai dati ottenuti dal team;
- è responsabile verso i clienti per il risultato.
Il modo in cui abbiamo introdotto Scrum in un’azienda non IT
Gli specialisti lavoravano separatamente: copywriter ed editor, costruttori di link e analisti SEO. Durante l’introduzione di Scrum, li abbiamo mescolati tra loro. Ogni team ha anche un account manager che eroga valore ai clienti.
I team sono stati formati per ciascuna delle tre aree SEO:
- gestione della massa di link
- creazione di contenuti
- ristrutturazione del sito web.
Il lavoro è stato suddiviso in sprint che costituiscono la pianificazione mensile. Durante la pianificazione, cercavamo di ridurre il rischio di non ottenere un risultato alla fine del mese.
Facciamo esperimenti con la durata degli sprint. Quando abbiamo iniziato a introdurre Scrum, gli sprint duravano una settimana. Uno sprint settimanale consente di eseguire rapidamente un processo e di realizzare dove si sta sbagliando, insegnare agli impiegati e capire come funziona tutto.
Consiglio chiave per la durata degli sprint di Scrum nel marketing: seleziona una scadenza che sia sufficiente per realizzare qualcosa di utile.
Gli sprint sono strutturati come segue:
pianificazione —> riunioni —> dimostrazione —> retrospettiva.
Abbiamo reindirizzato parte dei team per avere sprint di due settimane. Tieni presente che più lungo è lo sprint, maggiore è il rischio di saltare le scadenze.
Utilizziamo i seguenti strumenti nel nostro lavoro:
- pianificazione poker. La tecnica consente di valutare la complessità e la portata dei compiti che dovranno essere affrontati mentre il prodotto viene creato. Tutti i membri del team sono coinvolti nella pianificazione poker. Utilizzando delle carte, valutano i compiti e prendono decisioni collettive;
- analogo della programmazione a coppie basato sulla programmazione estrema. Diverse persone lavorano su un compito nello stesso posto di lavoro. È un esempio dimostrativo della regola “Due teste sono meglio di una”. La utilizziamo nei momenti critici;
- cicli HADI. Sono algoritmi per verificare ipotesi controverse che aiutano a guadagnare la fiducia del cliente. Leggi di più sui cicli HADI qui sotto.
Quali sono i cicli HADI e come usarli?
Che cos’è? Un ciclo HADI è un algoritmo per verificare un’ipotesi che appare come segue:
ipotesi —> verifica —> risultato —> conclusioni.
I cicli HADI sono simili al ciclo Lean Startup:
crea —> misura —> impara
Come funziona?
Generi ipotesi la cui fattibilità è messa in dubbio. Se un compito è comprensibile e necessario, non ha senso elaborarlo in un ciclo HADI. Dopo aver verificato l’ipotesi, determini se ha funzionato o meno e a quale grado di efficienza. Se ha funzionato, la lanci in uno sprint, se no, semplicemente la scarti.
Come appare?
Ad esempio, c’è un’ipotesi: “Se faccio interlinking sui prodotti, questo porterà a una crescita tripla del traffico”. Controlli l’ipotesi su un prodotto, impostando link manualmente all’interno del sito web. Se l’ipotesi ha funzionato, dai un compito ai programmatori: “Fornisci interlinking su tutto il sito”.
Qual è il vantaggio dei cicli HADI?
Può sembrare al cliente che la tua nuova soluzione non funzionerà bene. In risposta, mostri un esempio reale basato su un elemento.
Documenta le tue ipotesi, anche se non hanno funzionato. Nel prossimo sprint, puoi testarne un’altra. Inoltre, assicurati che i tuoi esperimenti non causino conflitti di interesse (ad esempio, affinché le ipotesi relative alla stessa pagina web non siano testate simultaneamente). Altrimenti, non sarà chiaro quale ipotesi ha avuto successo.
7 consigli per introdurre Scrum se non sei un’azienda IT
- Inizia dalla formazione. Leggi letteratura specializzata, partecipa a corsi di formazione.
- Determina chi è il tuo stakeholder (parte interessata). E poi lavora per fornire valore al cliente e allo stakeholder.
- Gli sprint dovrebbero rimanere immutati. Non avere paura di cambiare le altre cose.
- Non reindirizzare l’intero team verso Scrum, solo perché “è figo”. Ad esempio, i nostri copywriter lavorano con Kanban perché i testi non hanno priorità – devono solo essere completati il più rapidamente possibile.
- Determina la dimensione ottimale del tuo team. Secondo la mia esperienza, è di cinque-sette persone in aziende non IT.
- Organizza un’area di lavoro isolata per ciascun team. Se hai un ufficio open space, aggiungi tabelle Scrum offline.
- Assumi la guida nell’implementazione di Scrum. Se la direzione non è consapevole dello scopo di una nuova metodologia, non verrà fatto nulla.