Agile Marketing: come iniziare ad applicare la metodologia

Visto che la settimana scorsa ho pubblicato un tutorial su Trello, ho pensato che potesse essere utile spiegare come applico la metodologia Agile nei miei progetti.

Forse non hai mai sentito parlare di metodologie agili.

O magari pensi che servano solo per lo sviluppo software e i prodotti digitali.

Niente di più lontano dalla realtà: si possono applicare davvero a qualsiasi processo, progetto o reparto.

E questo articolo ha due parti molto ben distinte:

• Nella prima ti parlerò un po' di che cosa sono le metodologie agili e di come è iniziato tutto. La teoria che c'è dietro e i suoi concetti.
• Nella seconda parte ti spiegherò come applico io le parti di questa metodologia che mi piacciono nei team di marketing, così che, se ti interessa, tu possa iniziare ad applicarle al tuo fin da subito. La parte pratica e operativa.

Se conosci già la prima parte puoi saltare direttamente qui.

Cominciamo dall'inizio.

Parte 1: In cosa consiste la metodologia Agile

È un approccio al processo decisionale nella gestione dei progetti che mette al centro lo sviluppo di funzionalità in modo incrementale e iterativo, offrendo più valore all'utente / cliente a ogni ciclo.

Nasce prima nello sviluppo software e subito dopo viene applicata ad altri ambiti, come la gestione di progetti di qualsiasi tipo (non solo software), la creazione di prodotto, la UX o il marketing.

Si oppone ai modelli a cascata -in cui per iniziare una parte del progetto bisogna aver terminato la precedente- perché sono considerati troppo burocratici, e pone molta enfasi sulla comunicazione tra le parti, più che sulla documentazione.

Sembra bello, vero? Ma è possibile che ti stia chiedendo come sia nato tutto questo.

Adesso lo vedrai.

Storia della metodologia Agile

A metà degli anni 90 nacque una corrente di rifiuto della gestione strutturata dei progetti, che sfociò in una convention nel 2001 a Snowbird, Utah.

Lì venne coniato per la prima volta il termine “Agile Methodology”, fu creata la “Agile Alliance” e venne pubblicato l’“Agile Manifesto”, che raccoglie i principi della metodologia.

Il Manifesto Agile

Puoi leggere il documento originale qui:

http://agilemanifesto.org/

I quattro valori del Manifesto

Come hai potuto vedere nel link qui sopra, il documento specifica che:

“Stiamo scoprendo modi migliori di sviluppare software facendolo e aiutando gli altri a farlo. Grazie a questa attività siamo arrivati a valorizzare:

• Gli individui e le interazioni più che i processi e gli strumenti
• Il software funzionante più che una documentazione esaustiva
• La collaborazione con il cliente più che la negoziazione dei contratti
• Rispondere al cambiamento più che seguire un piano

Vale a dire che, pur riconoscendo il valore degli elementi a destra, consideriamo più importanti quelli a sinistra.”

E questi quattro valori si articolano nei seguenti dodici principi.

I dodici principi del Manifesto Agile

Li trovi qui:

http://agilemanifesto.org/principles.html

Ma te li copio:

1. “Soddisfazione del cliente. È la base di tutto. Si ottiene consegnando prodotti di valore che soddisfano un'esigenza.
2. Benvenuti i nuovi requisiti. Cambiare strada in corsa non significa fare un passo indietro. Qualsiasi suggerimento o soluzione è benvenuto se serve a migliorare il prodotto.
3. Consegne settimanali. La suddivisione del lavoro in fasi produttive è alla base della metodologia. Quando possibile, eseguirne una ogni settimana.
4. È possibile misurare i progressi. L'evoluzione dei processi non è un elemento soggettivo. Si può misurare con indicatori concreti.
5. Sviluppo sostenibile. Il modo di eseguire i progetti deve garantirne di per sé la continuità. Non si tratta di fare tanto per fare.
6. Lavoro ravvicinato. I responsabili dei progetti devono svolgere il loro lavoro nello stesso ambiente in cui avvengono le attività, non dagli uffici.
7. Conversazione faccia a faccia. Il responsabile deve comunicare i propri messaggi in modo efficace, meglio se di persona. Sono raccomandate riunioni periodiche sia con il cliente sia con i collaboratori.
8. Motivazione e fiducia. I processi avranno successo solo se chi li porta avanti è motivato e interagisce in un clima di fiducia e solidarietà.
9. Eccellenza tecnica e buon design. La forma non deve mai andare persa, così come la qualità del lavoro. È tutto un insieme.
10. Semplicità. Le attività devono essere il più semplici possibile. Se una non può essere eseguita in questi termini, deve essere divisa in iterazioni finché il livello di complessità non si riduce.
11. Autogestione dei team. Anche se deve esistere una figura che monitori i team di lavoro, questi devono essere in grado di organizzarsi da soli. Un eccesso di gerarchie crea dipendenza tra i collaboratori.
12. Adattamento alle circostanze che cambiano. I progetti di solito non finiscono nello stesso modo in cui sono iniziati. È indispensabile che chi li esegue sappia adattarsi alle diverse circostanze che possono presentarsi.”

Non so cosa ne pensi, ma se sei mai stato coinvolto nello sviluppo di prodotti digitali, è difficile non essere d'accordo con assolutamente tutti i punti.

Molto difficile.

Tanto che oggi, vista la sua utilità nell'ambito originario, questa metodologia è stata, come dicevo, trasferita alla gestione di ogni tipo di progetto e perfino di settori.

Si parla di “Design di prodotto Agile”, “Agile Marketing” e “Agile Management”, nei quali si cerca sempre di mettere l'accento su:

• Comunicazione faccia a faccia.
• Trasparenza.
• Soddisfazione del cliente.
• Semplicità.
• Sviluppo incrementale e miglioramento continuo.

Cominci a vedere il senso della metodologia?

Passiamo agli elementi essenziali.

Elementi e concetti di base della metodologia Agile

Bene. Tutto quello spiegato finora è molto bello, ma per iniziare bisogna portare la teoria sul terreno pratico e spiegare i diversi elementi che ne renderanno possibile l'impostazione e l'esecuzione.

Il framework

Anche se tutte le metodologie agili raccolgono gli stessi principi e valori, ognuna li applica in modo diverso.

E questi modi diversi di fare le cose sono i diversi framework o quadri di riferimento.

Ce ne sono diversi, ognuno con le proprie regole, vantaggi, raccomandazioni e svantaggi. I due più comuni e conosciuti sono Kanban e Scrum.

Kanban

Nasce in Giappone dopo la Seconda guerra mondiale, che lasciò il paese in un disastro economico e tecnologico.

Negli anni 50 Toyota progettò un sistema di produzione “just in time” (JIT) in cui ogni pezzo veniva prodotto esattamente al momento giusto, né prima né dopo, e che definì “altamente efficace ed efficiente”.

Per realizzarlo si basavano su schede che identificavano il fabbisogno di materiale nella catena di produzione.

Quindi questa metodologia riprende l'idea delle schede e le equipara a un'attività.

Si crea una bacheca con una colonna per ogni stato attraverso cui deve passare un'attività, per esempio:

• Definita.
• In esecuzione.
• Completata.
• Revisionata.

Questo è un esempio di bacheca semplice, ma può diventare complessa quanto richiede il progetto. Un esempio di bacheca più complessa potrebbe essere:

• Definizione.
• Analisi.
• Sviluppo
• Test.
• Messa in produzione.
• Documentazione.

La bacheca sarà diversa per ogni azienda o team in base alle esigenze ed è applicabile sia a progetti di nuovo sviluppo (“lanciare il blog”, “aprire un canale TikTok”) sia ad attività di manutenzione (“revisione dei banner del sito”) o ricorrenti (“revisione delle commissioni degli affiliati”, “reporting settimanale ecommerce”).

La bacheca può essere fisica (è ciò che si consiglia affinché sia visibile e trasparente per tutto il team) oppure digitale, ed è qui che entra in gioco Trello.

Scrum

È simile al precedente perché, come ti dicevo, i principi e la filosofia su cui si basano sono gli stessi.

Il naming si potrebbe tradurre come “mischia” e viene dal rugby, quando tutta la squadra si unisce.

Si distinguono per piccole sfumature, forse perché Scrum è considerato più restrittivo e, nella mia esperienza, è più orientato allo sviluppo di prodotto digitale:

• Raccomanda team interdisciplinari. In Kanban sono ammessi quelli specializzati.
• Ruoli specifici: Scrum Master, Product Owner e team di sviluppo in Scrum sono obbligatori; in Kanban puoi averli oppure no
• Iterazioni di durata determinata (tra 1 e 4 settimane): gli sprint (si insiste molto su questo).
• I cambiamenti: ciò che entra in uno sprint non si tocca e i cambiamenti desiderati vengono rimandati allo sprint successivo per poter misurare il processo di burn o Burndown (non è proprio così semplice). In Kanban i cambiamenti sono più facili da eseguire, perché si può sostituire una funzionalità a priorità più bassa con quella nuova desiderata.
• Cerimonie specifiche a durata fissa.
• Nuova bacheca a ogni sprint vs la bacheca persistente di Kanban.

Per tutto questo, personalmente per Agile Marketing preferisco Kanban ed è quella che ti spiegherò in questo articolo.

In realtà non è la cosa più comune, ma ho visto e usato modelli ibridi:

• Uso di Scrum per nuovi sviluppi e Kanban per attività ricorrenti all'interno dello stesso team. È quello che avevamo in Lowi.
• Metodologia “Scrumban”, che prende in prestito parti dell'uno e dell'altro.

User story

Forse il nucleo della metodologia.

Si tratta di un modo semplice di descrivere un'attività concisa che apporta valore all'utente o al cliente.

Di solito vengono scritte su schede (a mano su post-it o in formato digitale) e comprendono:

1. Titolo: breve, per farvi riferimento.
2. Descrizione: Come [ruolo dell'utente] Voglio [funzionalità] Per [Obiettivo della story]. Esempio: "Come utente del blog voglio vedere articoli correlati alla fine dell'articolo per continuare a leggere argomenti di mio interesse“.

Inoltre, devono possedere queste caratteristiche:

1. Indipendenti: tra loro. Devono poter essere affrontate separatamente, anche se correlate. Per esempio, in una campagna pubblicitaria si separerà l'attività di design da quella di copywriting, anche se ovviamente devono essere collegate.
2. Negoziabili: ambito e dettagli vengono concordati tra le due parti e rinegoziati se necessario, per esempio dividendoli in due parti.
3. Di valore: devono apportare valore reale al cliente, qualcosa di tangibile.
4. Stimabili: cioè è possibile analizzare lo sforzo richiesto per l'esecuzione. In tempo o punti di sviluppo.
5. Piccole: se sono troppo grandi e non possono essere stimate, vanno suddivise.
6. Verificabili: testabili, con criteri di accettazione binari (supera o non supera).

Una volta redatta, l'attività viene inserita nella colonna iniziale della bacheca e, man mano che cambia stato, viene spostata tra le colonne.

Il Backlog

È l'insieme delle attività del progetto già redatte e ancora da affrontare.

Il Team

A seconda della metodologia, può essere indispensabile o meno disporre di determinati ruoli nel team.

Per esempio, in Scrum normalmente si hanno:

• Product Owner: responsabile business del prodotto.
• Scrum Master: risolutore di problemi e facilitatore dello sviluppo. Può essere o meno il leader del team.
• Team di sviluppo / specialisti (UX, designer, SEO…): in pratica, le persone che eseguiranno la maggior parte delle attività.
• Tech lead: responsabile tecnico del team. Può essere la stessa persona che ricopre il ruolo di Scrum Master.
• QA: test.

In Kanban non è necessario avere questi ruoli, anche se è vero che quanto meglio è definito il ruolo di ogni membro del team, tanto più facile sarà valutare l'attività e poi eseguirla.

Sprint

Durata di un'iterazione, ciclo o consegna, nella quale verranno rilasciate una o più nuove funzionalità prioritarie o miglioramenti (feature) di un prodotto digitale oppure verranno svolte le attività pertinenti di quel ciclo (“creare i contenuti Instagram”).

Di solito durano tra una e quattro settimane. Nello sviluppo di prodotto digitale sono spesso due o tre, mentre nel marketing possono tranquillamente durare una settimana.

L'obiettivo dello Sprint

Nello sviluppo di prodotto esiste un obiettivo dello Sprint, che raggruppa la maggior parte delle funzionalità che si intende affrontare.

In altri tipi di progetti questo obiettivo non è sempre necessario.

Cerimonie

È così che vengono chiamate le riunioni del team proprie della metodologia.

Queste sono le più comuni e ognuna ha la propria durata, frequenza e obiettivi:

Servono ad analizzare e migliorare in modo iterativo lo sviluppo e i processi

• Daily: ogni giorno i membri del team spiegano molto brevemente cosa faranno quel giorno e se c'è qualcosa che blocca un'attività precedente, così da discutere i passi da seguire per rimuovere il blocco. Dovrebbe durare circa cinque minuti.
• Sprint plan: alla fine dello sprint in corso, il team si riunisce per discutere come affrontare lo sprint successivo e stimare le attività.
• Refinement: è il passo precedente alla cerimonia appena descritta. Nel refinement si cerca di fare in modo che ogni story sia abbastanza chiara e comprensibile per il team e che l'ambito sia definito così da poter essere stimata nello Sprint plan.
• Retrospettiva: dopo la chiusura dello sprint si analizza com'è andata, quali problemi si sono incontrati e quali punti di miglioramento si possono considerare per gli sprint futuri.

Se parliamo di marketing, tutte queste cerimonie sono indispensabili?

Più avanti ti darò la mia risposta, perché qui finisce la teoria.

Adesso ti spiego come l'ho applicata da zero in diversi team e progetti.

Inoltre vedrai che l'approccio è molto semplice e non servono cambiamenti radicali né nuovi strumenti per iniziare ad applicare i principi agili.

Parte 2: Il processo di implementazione della metodologia Agile nel Marketing

Se non hai mai avuto esperienza con metodologie agili, la prima cosa che voglio che tu faccia è leggere più volte il manifesto e i suoi principi, perché in realtà basta questo per capire e applicare alcuni concetti.

Si tratta di un cambiamento di mentalità in cui direi che la cosa principale è parlare e raggiungere accordi tra le parti (responsabili, il proprio team, team esterni…) sapendo che tutti cercate il bene comune.

In secondo luogo, essere flessibili. Capire che i cambiamenti arriveranno e bisogna accettarli. Anche se ci infastidiscono. Questo non significa “cedere” sempre, ma tornare al punto precedente: parlare e accordarsi.

Terzo e ultimo, misurare. Perché misurare è l'unico modo che abbiamo per sapere quanto è ottimale il nostro rendimento, quello del nostro team e se tutte le azioni che eseguiamo valgono davvero la pena.

Bene, una volta che questo ti è entrato bene in testa, passiamo a parlare del sistema.

Il sistema dell'Agile Marketing

L'idea di fondo è che il tuo team sia in grado di eseguire un numero limitato di attività in un determinato periodo.

Chiameremo questo periodo sprint e, per iniziare, la cosa più semplice è che duri una settimana.

Quindi dovrai organizzare un sistema affinché ogni settimana (sprint) venga eseguito il numero adeguato di attività.

Quante sono queste attività? All'inizio non lo sai, perché non hai uno storico. Quindi, nei primi sprint, il massimo a cui puoi aspirare è stimare con un certo margine di errore, che diminuirà man mano che tu e il tuo team acquisirete esperienza.

Inoltre non avete ancora esperienza nel redigere le attività, quindi alla stima si aggiungerà un ulteriore livello di difficoltà.

Ma tranquillo, questa mancanza di certezza durerà poco: dopo diversi sprint, una volta misurato e imparato a redigere correttamente le attività, avrai dati per stimare molto meglio ogni attività.

Quindi, sapendo quale sarà l'evoluzione, la prima cosa da fare è trovare uno strumento in cui creare il backlog e annotare tutte le attività dello sprint.

Gli strumenti dell'Agile Marketing

Ne hai diversi, a seconda che tu preferisca soluzioni online o offline.

Vantaggi di ciascun tipo?

Ti dirò che quelle online sono più immediate e possono avere un costo minimo, mentre quelle offline, che consistono sostanzialmente in una bacheca e alcuni post-it, rendono molto chiaro a tutto il team su cosa si sta lavorando e valorizzano quel lavoro agli occhi dell'azienda.

Il mio consiglio?

Salvo nei casi in cui sia indispensabile rendere chiarissimo tutto ciò che si sta facendo, inizia con uno strumento online.

Te ne consiglio due, in base a quanto sei convinto del sistema: Excel se vuoi provare e Trello se sei convinto che faccia per te.

Agile Marketing con Excel

Dico Excel perché è il più diffuso, ma va bene qualsiasi foglio di calcolo (Google Sheets, LibreOffice…).

L'idea qui non è tanto parlare di Kanban e bacheche, quanto iniziare subito ad applicare i principi agili.

Per farlo, creerai un documento in cui aggiungerai tutte le attività da affrontare, una sotto l'altra. Sarà il tuo Backlog.

Inoltre creerai una serie di colonne che ti aiutino a definire ogni attività, pianificare e misurare le prestazioni del team e lo sforzo richiesto da ogni tipo di attività:

In questo caso le colonne che abbiamo sono:

• Priorità: anche se potremmo mettere in alto quelle più prioritarie dello sprint, questo ci impedirebbe di filtrare, quindi aggiungiamo una colonna.
• Marca: se lavori con più clienti o brand, questo ti permetterà di segmentare per ciascuno.
• Attività: in questo caso aggiungiamo solo il titolo, perché in generale sono attività che già conosciamo e non servono descrizioni più ampie.
• Commento: in ogni caso, se ci servissero più dettagli, li aggiungeremmo qui.
• Tipo di attività: ci permetterà di sapere quanto tempo dedichiamo a ciascuna delle diverse attività e di analizzare:
• Se vale la pena il tempo investito.
• Se il tempo di esecuzione si riduce man mano che la persona acquisisce più esperienza nello stesso tipo di attività.
• Persona: cioè, chi la eseguirà.
• Stato dell'attività: Non iniziata, Iniziata o Completata.
• Data di ingresso: la data di inizio dello sprint, che ci permetterà di filtrare ciò che viene fatto in ogni sprint.
• Inizio: data di cambio dello stato dell'attività, da Non iniziata a Iniziata.
• Ora di inizio: l'ora in cui si inizia un'attività.
• Ora di fine: l'ora in cui si conclude un'attività.
• Sforzo in ore: la differenza tra l'Ora di inizio e l'Ora di fine.
• Settimana: per sapere la settimana dell'anno e poter fare confronti in futuro o creare grafici.

A ogni sprint si aggiungerebbero le nuove attività indicando la Data di ingresso e filtrando per quella data, così avremmo già impostato il nuovo sprint.

Naturalmente, se sono rimaste attività in sospeso da altri sprint, aggiungiamo al filtro la data dello sprint precedente così da vedere le attività di entrambi.

Questo metodo è valido finché non abbiamo attività che si trascinano per più di 2 sprint; altrimenti si accumulerebbero troppo e dovremmo cercare un altro sistema, come creare una nuova attività nel nuovo sprint che sostituisca quella rimasta incompleta nello sprint precedente.

Bene, con un modello come questo è più che sufficiente per iniziare a pianificare e applicare i tre pilastri dell'agilità: accordarsi, essere flessibili e misurare.

Poi, quando lo userai da un po' -e vedrai che funziona-, magari vorrai fare un passo in più. Sarà il momento di cambiare strumento…

Agile Marketing con Trello

Per prima cosa, qui hai un tutorial per iniziare a usare lo strumento.

Dopo averlo letto e aver creato il tuo account, sappi che ho pubblicato anche questo articolo su come utilizzare Trello per applicare la metodologia Kanban nel marketing, in cui entro più nel dettaglio, ma qui ti lascio comunque qualche indicazione:

1. Crea una sola bacheca per iniziare. È molto più facile da gestire quando sei agli inizi.
2. In quella bacheca crea 3 o 4 colonne, non di più, che potrebbero essere:
• Backlog: il backlog con tutte le attività, quelle dello sprint in corso e tutte le altre che verranno aggiunte per gli sprint futuri.
• To do: sposta da Backlog a questa colonna le attività che verranno eseguite in quello sprint. Quelle con priorità maggiore saranno in alto.
• Doing: una volta iniziato lo sprint, quando la persona responsabile di ogni attività ne inizia una nuova, la sposterà dalla colonna To do a questa.
• Done: una volta completata un'attività, verrà spostata dalla colonna Doing a questa.
3. Se l'attività dovesse essere validata da una persona diversa da chi l'ha eseguita, aggiungeremmo una quinta colonna “Validated”.
4. Una volta chiuso lo sprint, tutte le attività completate verrebbero archiviate e inizieremmo a mettere in To do quelle del nuovo sprint.

Facile, vero?

A questo punto mancherebbe solo aggiungere il livello di analisi: capire cosa è successo se qualcosa non è stato completato, se il problema era nell'analisi della capacità del team, nella redazione dell'attività, nella stima dell'attività…

E un modo per affrontare la questione è attraverso le cerimonie.

Cerimonie dell'Agile Marketing

Nella parte teorica abbiamo parlato di quattro cerimonie:

• Daily.
• Sprint plan.
• Refinement.
• Retrospettiva.

Ognuna viene svolta con obiettivi molto chiari, ma penso che siano molto concentrate sullo sviluppo di prodotto digitale e che nel marketing non siano tutte indispensabili.

In realtà dipenderà anche dalle dimensioni del team, perché più è grande, più sarà necessario mettere ordine e ascoltare.

Chiarito questo, ti do la mia opinione su ciascuna:

La daily è indispensabile. E lo è perché aiuta molto il buon funzionamento del team e sblocca le situazioni, oltre a far sì che tutti sappiamo a che punto siamo.

Lo sprint plan è utile, anche se non indispensabile se il team è piccolo (fino a 3-4 persone).

E il refinement, è ancora più sacrificabile, perché se il team lavora insieme da tempo non serve una sessione per chiarire cose che si risolvono con un messaggio su Slack o una chiamata di 30 secondi tra le due parti.

Le retrospettive sono utili soprattutto se durante lo sprint c'è stato un problema importante. Ascoltare l'opinione di ogni membro ci aiuterà a prendere buone decisioni di miglioramento.

Detto questo, non penso sia indispensabile farle dopo ogni sprint (soprattutto se sono sprint settimanali), ma sì periodicamente e anche, come dicevo, ogni volta che ci sia stato qualche inconveniente di una certa importanza.

Per concludere, diciamo che secondo me le cerimonie devono essere un mezzo per raggiungere un fine, non un fine in sé, come a volte mi è capitato di vedere.

Dimensioni del team

Anche se ho usato il sistema spiegato finora in team di 10 persone, penso che per queste dimensioni servirebbe qualche aggiustamento.

Tuttavia credo che sia perfetto per team più piccoli, tra 3 e 6 persone.

Se il tuo team è ancora più piccolo, non penso nemmeno che Trello sia necessario. Forse Excel e Slack (o Telegram) sono più che sufficienti.

Vantaggi dell'Agile Marketing

Il principale, per me, è poter avere una vista di tutte le attività da affrontare in ogni sprint, così da sapere chiaramente quali riusciamo a fare e quali vanno rimandate. È molto facile stabilire le priorità e assegnare le attività alle persone.

A livello organizzativo è una meraviglia, soprattutto perché il team sa cosa deve fare e può concentrarsi su quello.

Il vantaggio successivo è che, una volta implementato il sistema, saremo in grado di misurare e analizzare ogni tipo di attività. Se confronti lo sforzo con il contributo al business, potresti sorprenderti e smettere di fare attività che porti avanti da anni (“post su Facebook”).

O scoprire a quale persona del team è meglio assegnare ogni attività.

Un altro vantaggio è che, soprattutto se usi Trello più di Excel, tutto rimane documentato, lasciandoci a disposizione un vero e proprio repository.

Infine, se necessario, come ho detto prima, avere una bacheca o un backlog ben popolato mette in valore il lavoro svolto dal team.

Infine, il costo di tutto questo è ridotto:

• In denaro, perché gli strumenti sono gratuiti o a basso costo.
• In tempo, perché anche se c'è un leggero aumento del carico di lavoro, spero di averti chiarito che ne vale ampiamente la pena.

Conclusioni

Anche se l'articolo è piuttosto lungo, ho appena scalfito la superficie della metodologia Agile.

È un'introduzione perché tu possa valutare se può fare per te o se il tuo sistema attuale ti si addice di più.

In ogni caso, al di là dei sistemi, vorrei che ti rimanessero quelli che per me sono i suoi tre valori principali:

• Parlare e accordarsi tra le parti.
• Flessibilità.
• Misurazione.

Dando per scontato che ci sia chiaro che tutto questo serve a portare avanti il lavoro / progetto.

Detto questo, spero di essere riuscito a spiegarti il valore dell'applicazione della metodologia Agile nei team di Marketing, perché se ben eseguita apporta davvero molto valore. Te lo dico per esperienza personale.

Quindi fammi un favore e dalle una possibilità.

In ogni caso, anche se sono ben lontano dall'essere uno Scrum Master, se pensi di aver bisogno di aiuto per organizzare il tuo team nei progetti digitali, non devi far altro che scrivermi.