Práticas ágeis: como evitar erros cometidos por nossa equipe de marketing
Publicados: 2020-12-22O segredo foi revelado. O gerenciamento ágil de projetos é uma virada de jogo - e os desenvolvedores e o pessoal de TI não são mais os únicos a saber sobre isso.
Como profissional de marketing, você certamente já ouviu falar do Agile. Sua equipe pode estar usando algumas práticas Agile, como sprints de projeto e reuniões stand-up. Nesse caso, você está em minoria. Os benefícios do Agile ainda são amplamente inexplorados pelas equipes de marketing. De acordo com um novo relatório da Workfront e MarketingProfs, apenas 30% das equipes de marketing usam uma abordagem ágil para gerenciar seus processos. Os outros 70% provavelmente experimentam as mesmas frustrações que minha equipe experimentou antes de nos comprometermos em fazer o Agile funcionar.
Apenas 30% das equipes de #marketing usam uma abordagem #Agile para gerenciar processos via @workfront_inc @MarketingProfs. Clique para tweetarNossa equipe de marketing de sete pessoas na Emplify tem praticado o Agile por quase um ano. Levamos seis meses para chegar a um ponto de praticar bem: produzir trabalhos melhor, mais rápido e com mais energia e engajamento.
Quando começamos a praticar o Agile, cometemos muitos erros. Tantos erros, na verdade, que um dia trancamos metade de nossa equipe em uma sala de conferências e não saímos antes de identificar e resolver algumas falhas significativas em nossa abordagem. Felizmente havia cerveja e era sexta-feira. Ainda assim, foi doloroso e demorou para nos livrarmos de alguns buracos profundos orientados para o processo.
Neste artigo, compartilho esses erros para que você possa evitar um bloqueio doloroso como o nosso. O Agile pode revolucionar a capacidade de sua equipe de marketing de colaborar e entregar trabalho com mais rapidez - se você se comprometer em fazer o processo funcionar para você.
Antes de começarmos, vamos cobrir alguns princípios básicos:
O que são práticas Agile?
As práticas ágeis (geralmente chamadas de “Agile”) enfatizam a entrega contínua de porções menores de trabalho em vez de projetos com tarefas interconectadas maiores que podem durar semanas ou meses (que é tradicionalmente chamado de gerenciamento em cascata).
Noções básicas do Agile incluem:
- Equipe Scrum: Esta equipe altamente colaborativa, organizada sob um scrum master, resolve problemas complexos e entrega soluções em iterações de comprimento fixo chamadas sprints, que podem durar de uma semana a 30 dias. Uma equipe scrum trabalhando no conteúdo, por exemplo, pode começar um sprint de duas semanas se comprometendo a criar um novo infográfico ou planilha de dados.
- Produto mínimo viável (MVP): ao planejar uma entrega, os princípios do Agile enfatizam a liberação do projeto o mais rápido possível para que sua equipe possa responder antecipadamente a problemas reais. Para alcançar um modelo de entrega contínua, os scrum masters incentivam as equipes a definir o MVP e a descobrir as maneiras mais criativas de finalizar o produto dentro dos limites do sprint. Por exemplo, se você iniciar um sprint de duas semanas para criar um e-book como seu MVP e seu designer ficar doente, você pode decidir redefinir o MVP desse sprint como uma série de postagens de blog e projetar o e-book no próximo arrancada.
- Reunião de pé diária: Os membros da equipe ficam em um círculo por 15 minutos ou mais todas as manhãs para discutir as tarefas realizadas da equipe de scrum, áreas de foco e bloqueadores que podem impedi-los de terminar seu trabalho de sprint designado. No final do sprint, as equipes Agile entregam um conjunto definido de projetos, que são avaliados e aprimorados no próximo sprint. Algumas equipes scrum também incorporam reuniões retrospectivas, onde discutem as deficiências do processo que podem ser tratadas no próximo sprint.
30 Hábitos de Equipes de Conteúdo Altamente Produtivo [Infográfico]
Por que os profissionais de marketing devem usar o Agile?
A National Public Radio usa metodologias Agile para criar e testar uma nova programação. Pense nisso durante o seu próximo “momento de entrada da garagem”. Embora as raízes do Agile estejam no gerenciamento de TI, essa forma de entrega de projeto pode ser aplicada a muitas funções de um negócio, incluindo marketing.
A adoção de um modelo ágil de iteração contínua permite que sua equipe de marketing teste rapidamente novas mensagens ou campanhas, reaja com mais rapidez às atualizações de produtos e defina as expectativas com as partes interessadas que solicitam trabalho de sua equipe.
O momento brilhante de minha equipe veio quase nove meses depois de começarmos nossa jornada Agile, quando atualizamos o conteúdo em nosso site para fazer algumas mudanças em nossas mensagens de produto. Definimos o que poderíamos realizar em uma semana e entregamos esse trabalho no prazo. O conteúdo que não tivemos tempo de atualizar naquele sprint, escondemos da navegação. Temos continuamente acrescentado e atualizado as mensagens nessas páginas durante nossos sprints subsequentes.
Ficou confuso com o Agile Marketing? Suas perguntas respondidas [com vídeo]
Que erros devem ser evitados?
Se você está pensando em adotar o Agile em sua equipe, mesmo que esteja simplesmente procurando simplificar os processos em sua equipe de marketing, você desejará evitar estes quatro erros de marketing Agile que nossa equipe cometeu:
- Chamamos a nós mesmos de Agile sem fazer nosso dever de casa.
- Falhamos em designar os proprietários dos problemas.
- Nós nos concentramos nos resultados finais, e não nos problemas.
- Nós amontoamos em vez de priorizar (e fingimos que poderíamos fazer tudo).
Erro 1: nos chamamos de Agile sem fazer nosso dever de casa
Quando comecei com minha equipe de marketing, rapidamente instituí stand-ups diários para fornecer uma maneira rápida e indolor de verificar os projetos. Achei que já havia conduzido stand-ups e organizado sprints em funções anteriores, então tive experiência com Agile, certo? Errado.
Não entre no trabalho uma segunda-feira e anuncie que você está “indo para o Agile” como eu. Só porque você está trabalhando em sprints de duas semanas e tendo stand-ups diários não significa que você é uma equipe Agile. A beleza do Agile é que ele dá à sua equipe o poder de se comprometer com projetos juntos e definir uma entrega de qualidade dentro de um determinado escopo de tempo. Se você está apenas tentando empinar o máximo de trabalho possível em duas semanas e sacrificando a qualidade para cruzar a linha de chegada, essa beleza é negada.
Antes de instituir processos Agile em sua equipe de marketing, faça sua lição de casa. Abra um ou dois livros. Eu recomendo começar com Scrum de Jeff Sutherland (conhecido por muitos como um dos pais do Agile) e Hacking Marketing de Scott Brinker. Além disso, leia alguns dos excelentes artigos do CMI sobre marketing Agile.
Depois de fazer sua lição de casa, priorize algumas mudanças simples em seu processo existente para começar a elaborar uma abordagem ágil que funcione para sua equipe.
Antes de instituir processos #Agile em sua equipe de #contentmarketing, faça sua lição de casa, diz @evacjackson. Clique para tweetarErro 2: falhamos ao designar os proprietários do problema
Se o seguinte cenário não aconteceu, você pode pular esta seção; você alcançou alguma forma de nirvana no processo de marketing que ainda não descobri.
O resto de vocês, imagine o seguinte: Você está 98% envolvido em um grande projeto de equipe com um prazo claro e uma parte interessada surpresa intervém na hora final com dezenas de revisões. Então, sua equipe é forçada a prolongar o projeto por mais duas semanas para lidar com essas mudanças, porque ninguém pode argumentar que essa parte interessada está errada.
Ainda está lendo? Eu pensei assim.
A falta de propriedade definida de nossa equipe foi o maior obstáculo ao nosso progresso como departamento de marketing ágil. Estávamos sobrecarregados de trabalho. Ficamos frustrados quando várias partes interessadas avaliaram a qualidade do projeto. E não estávamos lançando nada devido a edições e correções de última hora.
Se sua equipe de marketing for parecida com a nossa, você terá dificuldade em saber quem é o proprietário final de um projeto. Quem é a pessoa diretamente responsável pelo sucesso de uma entrega? Quem define resultados mensuráveis para uma tarefa com a qual a equipe pode se alinhar? Quem precisa que este projeto seja bem-sucedido para que ele também tenha sucesso?
Para evitar o retrabalho de última hora, agora atribuímos essa pessoa - o proprietário do problema - a cada projeto.
Evite retrabalho de última hora, atribua um proprietário do problema a cada canal na #Agile #contentstrategy. @evacjackson Clique para tweetarA cada trimestre, definimos uma meta de leads qualificados de vendas para cada um de nossos principais canais de marketing: publicidade, eventos, leads de sites orgânicos e assim por diante. Em seguida, cada um desses canais recebe um proprietário em nossa equipe, e esse proprietário se torna a pessoa responsável por qualquer entrega que se enquadre nesse canal.
A propriedade do problema tem sido particularmente bem-sucedida para nossa equipe por vários motivos:
- Ele coloca o ônus do sucesso em uma pessoa , que é responsabilizada se as metas não forem cumpridas.
- Ele força o proprietário do canal a revelar os problemas antecipadamente para que a equipe possa resolvê-los de forma proativa.
- Ele permite que toda a equipe se envolva no brainstorming de uma solução e na implementação de uma correção.
- Ele capacita uma pessoa para orientar a qualidade de qualquer projeto.
Se sua equipe não tiver certeza de quem tem a palavra final em seus projetos de conteúdo, sente-se com seu departamento e faça uma pergunta surpreendentemente simples, mas desafiadora: "Quem é o dono do quê?" Responder a essa pergunta - e registrar suas respostas para que todos vejam - criará uma responsabilidade incomensurável.
Como evitar sobrecarga colaborativa dentro de sua equipe de conteúdo
Erro 3: nos concentramos nos resultados, e não nos problemas
Outro momento de mudança de jogo para nossa equipe Agile foi quando paramos de ver nosso trabalho como um conjunto de produtos a serem implementados e começamos a pensar sobre nosso trabalho como um conjunto de problemas a resolver.
Pense nos colaboradores individuais de sua equipe: desenvolvedores, redatores, designers e outras funções de implementação semelhantes. Com que frequência eles são solicitados a “projetar este slide” ou “escrever este e-book” com pouco contexto de por que estão fazendo isso?
Simplesmente atribuir uma tarefa em uma lista de tarefas sem ajudar sua equipe a entender o real propósito por trás do projeto leva a um trabalho sem brilho, sem investimento pessoal de sua equipe.
Atribuir uma tarefa sem ajudar sua equipe a entender o propósito leva a um trabalho sem brilho, diz @evacjackson. Clique para tweetarNa verdade, a falta de trabalho orientado para um propósito pode ter implicações graves em mais do que apenas suas táticas de marketing. Em uma pesquisa com membros do LinkedIn, mais de 60% dos entrevistados que não estavam em empregos com objetivos específicos planejavam deixar sua empresa em três anos ou menos.
60% + entrevistados que não estavam em empregos orientados para um propósito planejado para sair em 3 anos ou menos. @LinkedIn @Imperative Click To TweetEm nossa equipe, temos uma regra forte contra iniciar qualquer projeto com uma entrega prescrita em mente. Vamos enfrentá-lo, as partes interessadas nem sempre sabem o que querem. A resolução de problemas ajuda a promover a colaboração para melhores resultados.
Em vez disso, iniciamos cada projeto com uma declaração de problema, que segue um formato normalmente chamado de histórias de usuário no mundo do desenvolvimento ágil. Esse formato é parecido com este:
Quando __________ acontece, eu quero ________, para que possamos obter este resultado mensurável: ___________.
Aqui está um exemplo desse tipo de declaração de problema (ou história de usuário) de um projeto hipotético:
O proprietário do problema de cada projeto determina quais problemas a equipe resolverá para aquele projeto. Por exemplo, o proprietário pode considerar um problema se o site não está classificado para uma determinada palavra-chave ou se as mensagens precisam ser atualizadas para uma próxima feira comercial. Não importa o problema, a declaração do problema nunca inclui uma solução. Depois de decidir priorizar um problema específico, nossa equipe analisa o problema em conjunto, definindo o escopo de uma solução que possamos executar em nosso próximo sprint.
Resolver um problema em equipe permite que todos tenham uma participação no resultado.
Além disso, essa abordagem força a equipe a descobrir os pontos problemáticos por trás do problema de nível superficial para chegar a uma solução que atenda às necessidades principais, em vez de solicitações personalizadas.
Por exemplo, nossa equipe de vendas relatou que alguns clientes em potencial não compareciam às reuniões de demonstração programadas e não respondiam às solicitações de reprogramação. Nosso vice-presidente de vendas queria que a equipe de marketing criasse um vídeo explicativo animado que melhorasse os clientes em potencial para a reunião, embora isso levasse meses.
Depois de fazer algumas perguntas sobre o processo de vendas, percebemos que os principais problemas da equipe de vendas poderiam ser resolvidos com mensagens de e-mail aprimoradas antes da reunião de demonstração. Instituímos uma campanha de gotejamento de três e-mails desencadeada assim que uma reunião fosse agendada. Essa solução levou apenas dois dias para a equipe ser construída. Desde a construção desta campanha, reduzimos o número de pessoas que precisam reagendar reuniões em mais da metade.
Antes de atribuir uma tarefa a um membro da equipe, pergunte-se por que esse trabalho é importante. Ao criar uma declaração de problema e colaborar em uma solução, fomos capazes de identificar uma solução rápida que pagou dividendos para nossa equipe. Se tivéssemos criado um vídeo animado, a equipe de vendas poderia estar lidando com o mesmo problema por meses enquanto esperava por nossa correção.
Erro 4: agrupamos em vez de priorizar (e fingimos que poderíamos fazer tudo)
Se você tentar encaixar o máximo possível em cada sprint de marketing Agile, como fizemos, você está fazendo errado.
Sem um senso comum de prioridade, você não tem ideia de onde concentrar seu tempo. E sem foco, você recorre a dizer sim a tudo. E quando você diz sim para tudo e não tem proprietários problemáticos para seus projetos, você se vê no meio de um trimestre estressante com muitas entregas incompletas.
Muitas equipes Agile usam estimativas para priorizar o trabalho e aumentar a velocidade como uma equipe. Eles aproximam a quantidade de esforço que um projeto exigirá ou discutem quantas horas pode levar para os indivíduos concluírem suas tarefas. Com o tempo, muitas equipes Agile chegam a uma sensação de produção média por sprint, o que as ajuda a planejar novas tarefas.
Em nossos primeiros meses como uma equipe Agile, decidimos fazer esse tipo de estimativa. Infelizmente, acabamos manipulando nossas estimativas para fazer parecer que poderíamos fazer tudo. Adivinhamos quanto trabalho um projeto exigiria e, em seguida, regateamos os requisitos para abrir espaço para três outras solicitações. No final, negamos o valor da estimativa do trabalho, perpetuando um ambiente de estresse implacável.
Tentamos dois ou três métodos de rastreamento de velocidade (incluindo o planning poker, uma forma comum de estimar o trabalho). Nos concentramos em usar a estimativa como uma forma de provar que poderíamos realizar muito trabalho, não como uma forma de nos tornarmos uma equipe mais eficiente. ESSE foi nosso erro.
Recentemente, conversei com o diretor de engenharia de nossa empresa que gerencia o processo Agile para nossa equipe de produto. Quando mencionei que nossa equipe nunca havia dominado a estimativa, ele disse o seguinte:
Você tem um problema com a velocidade do #AgileMarketing - ou com a entrega geral do projeto? @evacjackson Clique para tweetarSe as partes interessadas estão constantemente pedindo relatórios de velocidade ou estimativas aprimoradas de sua equipe, você provavelmente está enfrentando problemas de processo maiores que estão prejudicando a capacidade de sua equipe de entregar trabalho a eles no prazo.
Quando sua equipe ágil que funciona bem está entregando regularmente iterações rápidas de um projeto e sinalizando preocupações para as partes interessadas quando um prazo não é razoável, você naturalmente evita perguntas sobre saída ou produtividade em sua equipe. O gerente de projeto ou scrum master tem a responsabilidade de corrigir o curso e comunicar essas mudanças quando o trabalho estiver ficando para trás.
Não tenha medo de priorizar apenas um ou dois novos projetos (ou problemas ou histórias) em seu próximo sprint porque você tem alguns projetos restantes em seu sprint atual. Apenas certifique-se de comunicar o trabalho restante em tempo hábil para as partes interessadas e compartilhe seus planos para concluir o projeto o mais rápido possível.
E não tenha medo de designar um líder para fazer a decisão final sobre o que precisa ser priorizado. Nossa equipe, por exemplo, proibiu todas as pessoas de moverem os cartões Trello para a coluna de sprint de "prioridade", exceto nosso vice-presidente de marketing. Isso colocava a responsabilidade de priorizar a pessoa com a melhor visão de todo o negócio.
Conclusão
Nossa equipe, como todas as equipes Agile, está adaptando os princípios Agile de maneiras que funcionam para nós. Qualquer que seja a abordagem ágil que sua equipe possa adotar, ela funcionará apenas se você fornecer oportunidades para feedback aberto sobre o processo e se você for flexível o suficiente para alterar seu fluxo de trabalho regularmente. Se eu tivesse um registro de cada ajuste que fizemos em nossa abordagem ágil até agora, seria mais longo do que este post.
Que erros suas equipes cometeram ao implementar processos Agile? Como você tratou desses erros? Deixe-nos saber em um comentário.
Quer melhorar sua estrutura para eficácia do marketing de conteúdo? Inscreva-se para receber nosso boletim informativo semanal Estratégia de conteúdo para profissionais de marketing, que apresenta insights exclusivos de Robert Rose, consultor chefe de conteúdo. Se você for como muitos outros profissionais de marketing que encontramos, todos os sábados ficará ansioso por seus pensamentos.
Imagem da capa por Joseph Kalinowski / Content Marketing Institute