Agile Marketing: como começar a aplicar a metodologia

Aproveitando que na semana passada publiquei um tutorial sobre Trello, pensei que poderia ser útil explicar como aplico a metodologia Agile nos meus projetos.

Talvez as metodologias ágeis não te digam muito.

Ou talvez aches que servem apenas para desenvolvimento de software e produtos digitais.

Nada mais longe da realidade: podem, na verdade, ser aplicadas a qualquer processo, projeto ou departamento.

E este artigo tem duas partes muito bem definidas:

• Na primeira vou falar um pouco sobre o que são as metodologias ágeis e como tudo começou. A teoria que está por trás delas e os seus conceitos.
• Na segunda parte vou explicar como aplico eu as partes desta metodologia de que gosto em equipes de marketing, para que, se tiver interesse, você possa começar a aplicá-las na sua desde já. A parte prática e operacional.

Se você já conhece a primeira parte, pode pular diretamente para aqui.

Comecemos pelo princípio.

Parte 1: Em que consiste a metodologia Agile

É uma abordagem à tomada de decisões na gestão de projetos que coloca o foco no desenvolvimento de funcionalidade de forma incremental e iterativa, trazendo mais valor ao usuário / cliente em cada ciclo.

Surge primeiro no desenvolvimento de software e rapidamente passa a ser aplicada a outros campos, como a gestão de projetos de qualquer tipo (não apenas software), a criação de produto, UX ou marketing.

Ela opõe-se aos modelos em cascata -em que para começar uma parte do projeto é preciso ter terminado a anterior- por serem considerados demasiado burocráticos, e coloca muita ênfase na comunicação entre as partes, acima da documentação.

Parece bom, não é? Mas talvez você esteja se perguntando como surgiu tudo isso.

Pois agora você vai ver.

História da metodologia Agile

Em meados dos anos 90 surgiu uma corrente de rejeição da gestão de projetos estruturada, que culminou numa convenção em 2001 em Snowbird, Utah.

Foi aí que se cunhou pela primeira vez o termo “Agile Methodology”, se criou a “Agile Alliance” e se publicou o “Agile Manifesto”, que reúne os princípios da metodologia.

O Manifesto Agile

Você pode ler o documento original aqui:

http://agilemanifesto.org/

Os quatro valores do Manifesto

Como você pôde ver no link acima, o documento especifica que:

“Estamos a descobrir melhores formas de desenvolver software, fazendo-o nós próprios e ajudando outros a fazê-lo. Através deste trabalho aprendemos a valorizar:

• Indivíduos e interações mais do que processos e ferramentas
• Software funcional mais do que documentação abrangente
• Colaboração com o cliente mais do que negociação contratual
• Resposta à mudança mais do que seguir um plano

Isto é, embora haja valor nos itens à direita, valorizamos mais os itens à esquerda.”

E estes quatro valores desdobram-se nestes doze princípios.

Os doze princípios do Manifesto Agile

Estão aqui:

http://agilemanifesto.org/principles.html

Mas vou copiá-los para ti:

1. “Satisfação do cliente. É a base de tudo. Alcança-se através da entrega de produtos de valor que satisfaçam uma necessidade.
2. Bem-vindos os novos requisitos. Mudar ao longo do caminho não é dar um passo atrás. Qualquer sugestão ou solução é bem-vinda se servir para melhorar o produto.
3. Entregas semanais. A divisão do trabalho em fases produtivas é a base da metodologia. Sempre que possível, executar uma por semana.
4. É possível medir o progresso. A evolução dos processos não é algo subjetivo. Pode ser medida com indicadores concretos.
5. Desenvolvimento sustentável. A forma de executar os projetos deve garantir, por si só, a sua continuidade. Não é uma questão de fazer por fazer.
6. Trabalho próximo. Os líderes dos projetos devem exercer o seu trabalho no mesmo terreno onde as tarefas acontecem, e não a partir dos gabinetes.
7. Conversa cara a cara. O gestor responsável deve comunicar eficazmente as suas mensagens, de preferência presencialmente. Recomendam-se reuniões periódicas tanto com o cliente como com os colaboradores.
8. Motivação e confiança. Os processos só terão sucesso se quem os executa for uma pessoa motivada e interagir num ambiente de confiança e solidariedade.
9. Excelência técnica e bom design. As formas nunca devem perder-se, assim como a qualidade do trabalho. Tudo faz parte de um conjunto.
10. Simplicidade. As tarefas devem ser o mais simples possível. Se alguma não puder ser executada nesses termos, deve ser dividida em iterações até reduzir o seu nível de complexidade.
11. Autogestão das equipes. Embora deva existir alguém que monitore as equipes de trabalho, estas devem ser capazes de se organizar por si próprias. O excesso de hierarquias cria dependência entre os colaboradores.
12. Adaptação a circunstâncias em mudança. Os projetos não costumam terminar da mesma forma que começaram. É indispensável que quem os executa consiga adaptar-se às diferentes circunstâncias que possam surgir.”

Não sei o que você acha, mas, se alguma vez esteve envolvido no desenvolvimento de produtos digitais, é difícil não concordar com absolutamente todos os pontos.

Muito difícil.

Tanto que, atualmente, perante a sua utilidade no âmbito original, esta metodologia foi, como digo, transferida para a gestão de todo o tipo de projetos e até para setores.

Fala-se de “Design de Produto Agile”, “Agile Marketing” e “Agile Management”, em que se procura sempre colocar o foco em:

• Comunicação cara a cara.
• Transparência.
• Satisfação do cliente.
• Simplicidade.
• Desenvolvimento incremental e melhoria contínua.

Já começa a perceber o valor da metodologia?

Vamos aos elementos essenciais.

Elementos e conceitos básicos da metodologia Agile

Bem. Tudo o que foi explicado até agora é muito bonito, mas para começar é preciso trazer a teoria para a prática e explicar os diferentes elementos que vão tornar possível a sua abordagem e execução.

O framework

Embora todas as metodologias ágeis partilhem os mesmos princípios e valores, cada uma os aplica de forma diferente.

E estas diferentes formas de fazer as coisas são os diferentes frameworks ou quadros de referência.

Existem vários, cada um com as suas regras, vantagens, recomendações e inconvenientes. Os dois mais habituais e conhecidos são Kanban e Scrum.

Kanban

Surgiu no Japão após a Segunda Guerra Mundial, que deixou o país mergulhado num desastre económico e tecnológico.

Nos anos 50, a Toyota concebeu um sistema de produção “just in time” (JIT) em que cada peça era feita exatamente no momento certo, nem antes nem depois, e que definiu como “altamente eficaz e eficiente”.

Para o pôr em prática, baseavam-se em cartões que identificavam as necessidades de material na cadeia de produção.

Assim, esta metodologia pega na ideia dos cartões e equipara cada um a uma tarefa.

Cria-se um quadro com uma coluna para cada estado por que uma tarefa tem de passar, por exemplo:

• Definida.
• Em execução.
• Finalizada.
• Revista.

Este é um exemplo de um quadro simples, mas pode tornar-se tão complexo quanto o projeto exigir. Um exemplo de quadro mais complexo poderia ser:

• Definição.
• Análise.
• Desenvolvimento
• Testes.
• Entrada em produção.
• Documentação.

O quadro será diferente para cada empresa ou equipe conforme as suas necessidades e aplica-se tanto a projetos de novo desenvolvimento (“lançar o blog”, “abrir um canal de TikTok”) como a tarefas de manutenção (“revisão dos banners do site”) ou recorrentes (“revisão das comissões de afiliados”, “reporting semanal de ecommerce”).

O quadro pode ser físico (é o que se recomenda para que seja visível e transparente para toda a equipe) ou digital, e é aí que entra o Trello.

Scrum

É semelhante ao anterior porque, como eu dizia, os princípios e a filosofia em que se baseiam são os mesmos.

O nome poderia traduzir-se como “formação ordenada” e vem do rúgbi, quando toda a equipe se junta.

Diferenciam-se em pequenos pormenores, talvez porque o Scrum é considerado mais restritivo e, na minha experiência, está mais orientado para o desenvolvimento de produto digital:

• Recomenda equipes interdisciplinares. No Kanban são permitidas equipes especializadas.
• Papéis específicos: Scrum Master, Product Owner e equipe de desenvolvimento em Scrum são obrigatórios; no Kanban você pode tê-los ou não
• Iterações com duração determinada (entre 1 e 4 semanas): os sprints (dá-se muita ênfase a isto).
• As mudanças: o que entra num sprint é imutável e as alterações desejadas são adiadas para o sprint seguinte, para poder medir o processo de queima ou Burndown (não é exatamente assim). No Kanban, as mudanças são mais simples de executar, pois uma das funcionalidades de menor prioridade pode ser substituída pela nova desejada.
• Cerimônias específicas com duração fixa.
• Quadro novo em cada sprint vs. o quadro persistente do Kanban.

Por tudo isso, pessoalmente prefiro Kanban para Agile Marketing e é essa que vou explicar neste artigo.

Aliás, não é o mais habitual, mas já vi e trabalhei com modelos híbridos:

• Uso de Scrum para novos desenvolvimentos e Kanban para tarefas recorrentes dentro da mesma equipe. Era o que tínhamos na Lowi.
• Metodologia “Scrumban”, que aproveita partes de um e de outro.

Histórias de usuário

Talvez o núcleo da metodologia.

Trata-se de uma forma simples de descrever uma tarefa concisa que traz valor ao usuário ou cliente.

Normalmente são escritas em cartões (à mão em post-its ou digitalmente) e incluem:

1. Título: breve, para fazer referência à tarefa.
2. Descrição: Como [papel do usuário] Quero [funcionalidade] Para [Objetivo da história]. Exemplo: "Como usuário do blog, quero ver artigos relacionados no final do artigo para continuar a ler temas do meu interesse“.

Além disso, têm de possuir estas características:

1. Independentes: umas das outras. Devem poder ser abordadas isoladamente, mesmo estando relacionadas. Por exemplo, numa campanha publicitária, a tarefa de design será separada da de copywriting, embora obviamente ambas tenham de estar relacionadas.
2. Negociáveis: o alcance e os detalhes são acordados entre ambas as partes e renegociados se necessário, dividindo-se, por exemplo, em duas partes.
3. Valiosas: têm de trazer valor real ao cliente, algo tangível.
4. Estimáveis: isto é, é possível analisar o esforço necessário para a sua execução. Em tempo ou em pontos de desenvolvimento.
5. Pequenas: se forem muito grandes e não puderem ser estimadas, têm de ser subdivididas.
6. Verificáveis: testáveis, com critérios de aceitação binários (passa ou não passa).

Depois de redigida, a tarefa é colocada no quadro na coluna inicial e, à medida que o seu estado muda, vai sendo movida entre colunas.

O Backlog

É o conjunto de tarefas do projeto já redigidas e ainda por abordar.

A Equipe

Dependendo da metodologia, pode ser imprescindível ou não contar com determinados papéis na equipe.

Por exemplo, em Scrum, o habitual é contar com:

• Product Owner: responsável de negócio pelo produto.
• Scrum Master: solucionador de problemas e facilitador do desenvolvimento. Pode ser ou não o líder da equipe.
• Equipe de desenvolvimento / especialistas (UX, designers, SEO…): na prática, as pessoas que vão executar a maioria das tarefas.
• Tech lead: responsável técnico da equipe. Pode ser a mesma pessoa que desempenha o papel de Scrum Master.
• QA: testes.

No Kanban não é necessário contar com esses papéis, embora seja verdade que, quanto melhor estiver definido o papel de cada membro da equipe, mais fácil será avaliar a tarefa e executá-la posteriormente.

Sprints

Duração de uma iteração, ciclo ou entrega, em que serão lançadas uma ou várias novas funcionalidades prioritárias ou melhorias (features) de um produto digital, ou serão desenvolvidas as tarefas correspondentes desse ciclo (“criar os conteúdos de Instagram”).

O normal é durarem entre uma e quatro semanas. No desenvolvimento de produto digital costumam ser duas ou três, enquanto em marketing podem perfeitamente ser de uma semana.

O objetivo do Sprint

No desenvolvimento de produto, há um objetivo do Sprint, que agrega a maior parte das funcionalidades que se pretende abordar.

Noutro tipo de projetos, esse objetivo nem sempre é necessário.

Cerimônias

É assim que se chamam as reuniões de equipe próprias da metodologia.

Estas são as mais habituais e cada uma tem a sua duração, frequência e objetivos:

Servem para analisar e melhorar iterativamente o desenvolvimento e os processos

• Daily: diariamente, os membros da equipe comentam muito resumidamente o que vão fazer nesse dia e se existe algo a bloquear uma tarefa anterior, para se discutirem os passos a seguir para eliminar o bloqueio. Deveria durar cerca de cinco minutos.
• Sprint plan: ao terminar o sprint em curso, a equipe reúne-se para comentar como vai abordar o sprint seguinte e estimar as tarefas.
• Refinamento: é o passo anterior à cerimônia precedente. No refinamento, procura-se que cada história esteja suficientemente clara e compreensível para a equipe e que o alcance esteja definido para poder ser estimado no Sprint plan.
• Retrospectiva: após o fecho do sprint, analisa-se como correu, que problemas encontrámos e que pontos de melhoria podem ser considerados para futuros sprints.

Se falarmos de marketing, são todas estas cerimônias imprescindíveis?

Mais à frente dou a minha resposta, porque a teoria acaba aqui.

Agora explico como apliquei tudo isso do zero em diferentes equipes e projetos.

Além disso, você vai ver que a abordagem é muito simples e não são necessárias mudanças radicais nem novas ferramentas para começar a aplicar princípios ágeis.

Parte 2: O processo de implementação da metodologia Agile em Marketing

Se você nunca teve experiência com metodologias ágeis, a primeira coisa que quero que faça é ler várias vezes o manifesto e seus princípios, porque, na realidade, isso é suficiente para compreender e aplicar alguns conceitos.

Trata-se de uma mudança de mentalidade em que eu diria que o principal é falar e chegar a acordos entre as partes (chefias, a própria equipe, equipes externas…) sabendo que todos procuram o bem comum.

Em segundo lugar, ser flexíveis. Perceber que as mudanças vão chegar e é preciso aceitá-las. Mesmo que nos chateie. Isso não significa “ceder” sempre, mas sim voltar ao ponto anterior: falar e acordar.

Em terceiro e último lugar, medir. Porque medir é a única forma de sabermos quão ótimo é o nosso desempenho, o da nossa equipe e se todas as ações que executamos realmente valem a pena.

Certo, depois de ter isso bem gravado na cabeça, passemos ao sistema.

O sistema do Agile Marketing

A ideia por trás disso é que sua equipe é capaz de executar um número limitado de tarefas num determinado período.

A esse período vamos chamar sprint e, para começar, o mais simples é que dure uma semana.

Então, você terá de organizar um sistema para que, a cada semana (sprint), seja realizado o número adequado de tarefas.

Quantas tarefas são? No início você não sabe, porque não tem histórico. Assim, nos primeiros sprints, o máximo a que pode aspirar é estimar com um certo grau de erro, que diminuirá à medida que você e sua equipe ganharem experiência.

Além disso, também não têm experiência a redigir tarefas, pelo que se acrescenta uma camada de dificuldade à estimativa.

Mas não se preocupe, essa falta de certeza vai durar pouco: depois de vários sprints, de medir e de aprender a redigir corretamente as tarefas, você já terá dados para estimar cada tarefa muito melhor.

Então, sabendo como isto vai evoluir, a primeira coisa é encontrar uma ferramenta onde criar o backlog e anotar todas as tarefas do sprint.

As ferramentas do Agile Marketing

Há várias, dependendo de você preferir que sejam online ou offline.

Vantagens de cada tipo?

Eu diria que as online são mais imediatas e podem ter um custo mínimo, enquanto as offline, que basicamente consistem em um quadro e alguns post-its, deixam muito claro para toda a equipe aquilo em que se está trabalhando e valorizam esse trabalho para o negócio.

A minha recomendação?

Exceto nos casos em que seja imprescindível deixar perfeitamente claro tudo o que está sendo feito, começa com uma ferramenta online.

Recomendo duas, dependendo do seu grau de convicção sobre o sistema: Excel se quiser experimentar e Trello se estiver convencido de que isso é para você.

Agile Marketing com Excel

Digo Excel porque é o mais difundido, mas qualquer folha de cálculo (Google Sheets, LibreOffice…) serve.

A ideia aqui não é tanto falar de Kanban e quadros, mas começar já a aplicar princípios ágeis.

Para isso, você vai criar um documento no qual adicionará todas as tarefas a realizar, uma abaixo da outra. Será o seu Backlog.

Além disso, você vai criar uma série de colunas que ajudem a definir cada tarefa, planejar e medir o desempenho da equipe e o esforço exigido por cada tipo de tarefa:

Neste caso, as colunas que temos são:

• Prioridade: embora pudéssemos colocar no topo as tarefas mais prioritárias do sprint, isso impedir-nos-ia de filtrar, por isso adicionamos uma coluna.
• Marca: se trabalhas com vários clientes ou marcas, isto permitirá segmentar por cada um deles.
• Tarefas: neste caso adicionamos apenas o título, porque, em geral, são tarefas que já conhecemos e não precisam de descrições mais extensas.
• Comentário: de qualquer forma, se precisássemos de mais detalhe, acrescentá-lo-íamos aqui.
• Tipo de tarefa: isto vai permitir-nos saber quanto tempo dedicamos a cada uma das diferentes atividades e analisar:
• Se o tempo investido vale a pena.
• Se o tempo de execução diminui à medida que a pessoa ganha mais experiência executando o mesmo tipo de tarefa.
• Pessoa: pois isso mesmo, quem a vai realizar.
• Estado da tarefa: Não iniciada, Iniciada ou Finalizada.
• Data de entrada: a data de início do sprint, o que nos permitirá filtrar o que é feito em cada sprint.
• Início: data em que o estado da tarefa muda de Não iniciada para Iniciada.
• Hora de início: a hora em que uma tarefa começa.
• Hora de fim: a hora em que uma tarefa termina.
• Esforço em horas: a diferença entre a Hora de início e a Hora de fim.
• Semana: para saber a semana do ano e poder comparar no futuro ou criar gráficos.

Em cada sprint, seriam acrescentadas as novas tarefas com a respetiva Data de entrada e, filtrando por essa data, já teríamos estabelecido o novo sprint.

Claro que, se tiverem ficado tarefas pendentes de outros sprints, adicionamos ao filtro a data do sprint anterior para que apareçam as tarefas de ambos.

Este método é válido desde que não tenhamos tarefas de mais de 2 sprints; caso contrário, acumular-se-iam demasiado e teríamos de procurar outro sistema, como criar uma nova tarefa no novo sprint que substitua a que ficou por fazer no sprint anterior.

Bem, com um modelo como este é mais do que suficiente para começar a planejar e aplicar os três pilares da agilidade: acordar, ser flexível e medir.

Depois, quando você já tiver alguma experiência — e vir que isso funciona —, talvez queira dar um passo adiante. Será o momento de mudar de ferramenta…

Agile Marketing com Trello

Antes de mais nada, aqui está um tutorial para começares a usar a ferramenta.

Depois de ler e criar sua conta, saiba que também publiquei este artigo sobre como utilizar Trello para aplicar a metodologia Kanban em marketing, no qual entro em mais detalhes, mas deixo aqui algumas pinceladas:

1. Crie apenas um quadro para começar. É muito mais fácil de gerenciar no início.
2. Nesse quadro, cria 3 ou 4 colunas, não mais, que poderiam ser:
• Backlog: o backlog com todas as tarefas, as do sprint em curso e todas as restantes que forem sendo acrescentadas para futuros sprints.
• To do: move de Backlog para esta coluna as tarefas que vão ser executadas nesse sprint. As tarefas de maior prioridade ficam em cima.
• Doing: depois de o sprint começar, quando a pessoa responsável por cada tarefa iniciar uma nova, move-a da coluna To do para esta.
• Done: quando uma tarefa estiver concluída, será movida da coluna Doing para esta.
3. Se a tarefa tivesse de ser validada por uma pessoa diferente daquela que a executou, adicionaríamos uma quinta coluna “Validated”.
4. Depois de fechado o sprint, todas as tarefas concluídas seriam arquivadas e começaríamos a colocar em To do as tarefas do novo sprint.

Fácil, não é?

Agora só faltaria adicionar a camada de análise: perceber o que aconteceu se alguma tarefa não foi terminada, se o problema foi de análise da capacidade da equipe, da redação da tarefa, da estimativa da tarefa…

E uma forma de abordar o assunto é através das cerimônias.

Cerimônias do Agile Marketing

Na parte teórica falamos de quatro cerimônias:

• Daily.
• Sprint plan.
• Refinamento.
• Retrospectiva.

Cada uma é realizada com objetivos muito claros, mas penso que estão muito focadas no desenvolvimento de produto digital e, em marketing, nem todas são imprescindíveis.

Na realidade, também depende do tamanho da equipe, porque quanto maior for, mais necessário será pôr ordem e ouvir.

Esclarecido isso, dou a minha opinião sobre cada uma:

A daily é imprescindível. E é porque ajuda muito ao bom funcionamento da equipe e a desbloquear coisas, além de garantir que todos sabemos em que ponto estamos.

O sprint plan é útil, embora não seja imprescindível se a equipe for pequena (até 3-4 pessoas).

E o refinamento, é ainda mais dispensável, porque se a equipe já trabalha junta há algum tempo não é necessária uma sessão para esclarecer coisas que se resolvem numa mensagem de Slack ou numa chamada de 30 segundos entre as duas partes.

As retrospectivas são úteis sobretudo se tiver havido algum problema importante no sprint. Ouvir a opinião de cada membro vai ajudar-nos a tomar boas decisões de melhoria.

Posto isto, não acho imprescindível fazê-las após cada sprint (sobretudo se forem sprints semanais), mas sim periodicamente e também, como digo, sempre que tenha havido algum inconveniente de certa importância.

Para concluir, digamos que considero que as cerimônias têm de ser um meio para alcançar um fim, e não um fim em si mesmas, como por vezes já encontrei.

Tamanho da equipe

Embora tenha utilizado o sistema explicado até agora em equipes de 10 pessoas, penso que para este tamanho seria preciso fazer alguns ajustes.

No entanto, acho que é perfeito para equipes mais modestas de entre 3 e 6 pessoas.

Se sua equipe for menor, nem acho que o Trello seja necessário. Talvez Excel e Slack (ou Telegram) sejam mais do que suficientes.

Vantagens do Agile Marketing

A principal, para mim, é poder ter uma vista de todas as tarefas a realizar em cada sprint, para termos claro quais conseguimos fazer e quais têm de ser adiadas. É muito fácil priorizar e atribuir tarefas a pessoas.

Em termos de organização, isto é excelente, sobretudo porque a equipe sabe o que tem de fazer e pode concentrar-se nisso.

A vantagem seguinte é que, depois de implementado o sistema, seremos capazes de medir e analisar cada tipo de tarefa. Se você comparar o esforço com a contribuição para o negócio, talvez se surpreenda e deixe de executar tarefas que faz há anos (“publicações no Facebook”).

Ou de descobrir a que pessoa da equipe é melhor atribuir cada tarefa.

Outra vantagem é que, se utilizares Trello mais do que Excel, tudo fica documentado, ficando ao nosso alcance um verdadeiro repositório.

Por último, se for necessário, como já referi, ter um quadro ou backlog bem preenchido valoriza o trabalho realizado pela equipe.

Por fim, o custo de tudo isto é reduzido:

• Em dinheiro, porque as ferramentas são gratuitas ou de baixo custo.
• Em tempo, porque, embora exista um ligeiro aumento da carga de trabalho, espero ter deixado claro que compensa largamente.

Conclusões

Embora o artigo tenha alguma extensão, mal arranhei a superfície da metodologia Agile.

É uma introdução para você considerar se isso pode ser adequado ao seu caso ou se o sistema atual funciona melhor.

De qualquer forma, para além dos sistemas, gostaria que ficasses com aqueles que, para mim, são os seus três valores principais:

• Falar e chegar a acordo entre as partes.
• Flexibilidade.
• Medição.

Partindo do princípio de que temos claro que o objetivo de tudo isto é levar o trabalho / projeto em frente.

Dito isso, espero ter conseguido explicar o valor de aplicar a metodologia Agile em equipes de Marketing, porque, quando bem executada, ela realmente agrega muito valor. Digo isso por experiência própria.

Por isso, faz-me o favor e dá-lhe uma oportunidade.

De qualquer forma, embora eu esteja longe de ser Scrum Master, se você acha que precisa de ajuda para organizar sua equipe em projetos digitais, basta me escrever.