O marketing ágil talvez não seja uma frase que você ouça todos os dias, mas a cada dia que passa se torna mais popular e importante. Tradicionalmente associado ao desenvolvimento e gerenciamento de softwares, o ágil é uma estrutura leve e bem ágil para desenvolvimento de software / produtos e lançamento de recursos e produtos no mercado.
Ela se opõe aos métodos de produção “em cascata” que tratam a análise, o design, a codificação e o teste como fases discretas – onde, em agilidade, são tratados como contínuos.
À medida que o marketing se torna mais orientado a dados, quantitativo e iterativo, podemos usar muitas dessas mesmas práticas de gerenciamento para aprimorar nossas campanhas de marketing, mitigar riscos e, finalmente, enviar campanhas de marketing mais eficazes.
Antes de nos aprofundarmos nos aplicativos de marketing, no entanto, vamos cobrir brevemente o que é scrum e como ele veio a ser.
O que é Scrum?
Scrum é uma estrutura que ajuda as equipes a trabalharem juntas. Assim como uma equipe de rugby (onde recebe esse nome) treinando para o grande jogo, o Scrum incentiva as equipes a aprender através de experiências, a se organizarem enquanto trabalham em um problema e a refletir sobre suas vitórias e derrotas para melhorar continuamente.
Enquanto o Scrum de que estou falando é usado com mais frequência por equipes de desenvolvimento de software, seus princípios e lições podem ser aplicados a todos os tipos de trabalho em equipe. Essa é uma das razões pelas quais o Scrum é tão popular.
Uma Introdução ao Scrum e Desenvolvimento Ágil
Desenvolvido nos anos 90 por Jeff Sutherland e Ken Schwaber, Scrum é:
- Leve
- Fácil compreensão
- Complicado de dominar
Embora a estrutura do Scrum tenha sido desenvolvida originalmente para lidar com o desenvolvimento de software, é uma estrutura flexível e funcional que pode ser adaptada aos problemas que a equipe de marketing digital também enfrenta, uma vez que também desenvolvem softwares e outros tipos de produtos.
Na maioria das vezes, este guia será paralelo ao guia original do Scrum, com algumas diferenças e alterações para melhor se alinhar à natureza um pouco mais ad-hoc do trabalho de marketing e otimização.
Não reinvente a roda: atenha-se à estrutura
A estrutura do Scrum é composta por equipes do Scrum e seus papéis, eventos, artefatos e regras associados. Embora possa ser tentador escolher partes dessa estrutura, é melhor você ficar o mais próximo possível, pois essa estrutura resistiu ao teste do tempo em muitos aplicativos.
O uso bem-sucedido da estrutura depende de um certo nível de maturidade e alinhamento em torno de alguns valores fundamentais:
- As pessoas se comprometem pessoalmente a bater as metas / objetivos de sua equipe no Scrum.
- Os membros da equipe possuem a coragem necessária de fazer o que precisa ser feito e trabalhar em problemas difíceis.
- Todos possuem foco nas atividades do sprint e nos objetivos da equipe Scrum.
- Os membros do Scrum e seus stakeholders concordam em estarem abertos a respeito do trabalho e os desafios para a realização do trabalho.
- A equipe Scrum se respeitam por serem pessoas independentes e capazes.
Se sua equipe pode se comprometer com esses princípios, vale a pena a curva de aprendizado inicial para tentar implementar essa estrutura altamente eficaz e colaborativa.
Noções básicas do Scrum Framework
- Equipe
- Eventos
- Artefatos
O membros tem funções únicas em seu time, que permitem resultados rápidos e de alta qualidade pelos quais o Scrum é famoso. Eventos Scrum são um conjunto de 5 eventos repetidos que formam a espinha dorsal da estrutura. Por fim, os artefatos são as ferramentas organizacionais, como backlogs do sprint, que permitem que a equipe se mova eficientemente com o máximo de auto-organização.
Funções em uma equipe Scrum
Existem três funções principais que precisam ser preenchidas. Em uma equipe menor, você pode achar que faz sentido que um membro da equipe seja Desenvolvedor (Colaborador Individual), além de ocupar as funções Scrum Master ou Dono do Produto.
O Dono do Produto
De acordo com o Guia Oficial, o Dono do produto é o único dentro do projeto que tem a responsabilidade de gerenciar o Backlog do produto. Isso inclui:
- Expressando com clareza itens do Backlog
- Solicitando e priorizando itens no Backlog
- Garantir que o Backlog do produto esteja sempre visível e claro para todos, e mostre em que a equipe Scrum trabalhará em seguida
- Garantir que a Equipe Scrum (desenvolvimento) tenha total entendimento dos itens no Backlog do Produto no nível necessário
As funções de Product Owner provavelmente já estão bem mapeadas para o que um gerente de projeto tradicional de uma agência ou gerente de programa pode estar fazendo. Basicamente, o Dono do Produto lida com solicitações de trabalho, agenda entregas e trabalha com Clientes e Partes Interessadas.
Se você ainda não tem alguém desempenhando essa função, considere a possibilidade de um colaborador individual intensificar, pois é muito importante ter uma pessoa singular como gerente da lista de pendências e como gargalo para isolar a equipe de desenvolvimento de distrações, solicitações e mudanças.
O Dono do Produto é uma única pessoa e é a única pessoa que pode modificar o Backlog do Produto, alterar as prioridades de trabalho da Equipe de Desenvolvimento e aceitar ou rejeitar solicitações de trabalho recebidas.
Isso é muita responsabilidade, mas já mapeia bem o que um bom gerente de projeto fará em uma organização.
A equipe de desenvolvimento
A equipe de desenvolvimento é composta pelos profissionais que fazem o trabalho de fornecer incrementos de trabalho prontos para o cliente / empresa para a equipe Scrum. Em um contexto de marketing digital, essas pessoas já podem ter cargos como Gerente de Marketing, e etc.
Em uma estrutura Scrum padronizada, todas essas pessoas perdem cargos e se tornam simplesmente “Desenvolvedores”, que contribuem com seus pontos fortes e fracos à equipe para atingir os objetivos da Sprint.
A equipe de desenvolvimento é encarregada pela empresa de se auto-organizar e gerenciar seu próprio trabalho. Isso ajuda a desassociar as equipes de marketing e a realizar mais trabalhos.
De acordo com o Guia Scrum, as equipes de desenvolvimento têm as seguintes características:
- Eles são auto-organizados
- Eles são multifuncionais
- O Scrum não reconhece títulos para os membros da equipe de desenvolvimento que não sejam Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa
- Não faz parte da metodologia Scrum reconhecer equipes menores (sub-equipes) como parte da equipe de desenvolvimento, independente se for algo específico ou de testes e análises
- Cada membro entre os desenvolvedores podem possuir conhecimento ou habilidade especialista, mas a responsabilidade sobre o projeto é de toda a equipe e não de um membro específico
Uma observação importante a ser destacada aqui é a expectativa de que a equipe de desenvolvimento seja multifuncional. Embora isso seja ideal, nem sempre é possível em um contexto de marketing.
Por exemplo, uma pequena agência de marketing digital pode ter apenas um editor de vídeo, mas clientes suficientes para justificar duas equipes Scrum separadas.
Nesse caso, apenas seja flexível. A maneira como lidamos com isso em nossa equipe foi fazer com que o editor de vídeo estivesse em vários intervalos de tempo por semana para cada equipe. Dessa forma, sabe-se quando podemos lidar razoavelmente com as gravações para que o sprint não se sustente nessa dependência.
O Scrum Master
O Scrum Master é um pouco de um líder e treinador da equipe Scrum. É um papel muito importante, pois existe para otimizar e implementar a estrutura do Scrum.
O Scrum Master é um líder servo da equipe. Eles atuam como um recurso para aqueles que estão fora da equipe Scrum para entender o processo e se adaptar a ele. O Scrum Master ajuda a organização a otimizar suas interações com a equipe Scrum para maximizar o valor criado usando o Scrum.
Aqui estão algumas especificidades de como o Scrum Master atende a várias partes interessadas extraídas do Guia Scrum.
Scrum Master Service | Dono do Produto
O Scrum Master dá suporte ao dono do produto de múltiplas formas, entre elas:
- Aplicando as melhores técnicas para gestão eficiente do Backlog do Produto
- Ajudar a equipe Scrum a compreender todos os itens de forma clara e concisa do Backlog do produto
- Garantir que o Dono do produto consiga gerenciar o Backlog do produto de forma a encontrar o máximo valor
- Tornando possível eventos Scrum, conforme solicitado ou necessário
Scrum Master Service | equipe de desenvolvimento
O Scrum Master dá suporte à equipe de desenvolvimento de múltiplas formas, entre elas:
- Treinar os membros da equipe em funcionalidade cruzada e auto-organização
- Dando suporte a equipe de desenvolvimento na criação de produtos novos de forma ágil
- Eliminando os impedimentos durante o progresso da Equipe de Desenvolvimento
- Tornando possível eventos Scrum, conforme solicitado ou necessário
Serviço Scrum Master | Organização
O Scrum Master dá suporte a organização de múltiplas formas, entre elas:
- Liderar e treinar a organização na adoção do Scrum
- Planejando novas implementações do Scrum dentro da empresa
- Ajudar os funcionários e as partes interessadas a entender e implementar o Scrum e o desenvolvimento empírico de produtos
- Causando mudanças que aumentam a produtividade da equipe Scrum
- Trabalho em conjunto com outros Scrum Masters visando melhorar a eficácia da aplicação do Scrum na empresa
Eventos Scrum para otimização da taxa de conversão
No Scrum tradicional, existem 5 eventos principais nos quais toda equipe do Scrum participa. O poder da estrutura de eventos é que é repetitivo, iterativo e direto otimizar o processo que uma equipe de profissionais de marketing pode usar para produzir mais trabalho, melhor, em menos Tempo. A imagem abaixo é um resumo simples, abordaremos cada evento individualmente.
O Sprint
O guia Scrum descreve o sprint como “um período de um mês ou menos, durante o qual é criado um incremento de produto” Concluído “, utilizável e potencialmente liberável”.
Esse conceito já saiu do mundo do software, com livros apropriadamente escritos sobre ele.
Portanto, você só precisa modificar um pouco o conceito para usá-lo em sua equipe de marketing. Talvez seja necessário alterar um pouco o tempo da estrita prescrição de um mês permitida pela estrutura original do Scrum, ou pelo menos ser criativo em tarefas de divisão para ajustar-se a esse prazo.
Vimos sucesso ao diminuir o requisito de que cada sprint precisa ter um produto liberável no final. Em vez disso, cada sprint deve cruzar um marco.
Por exemplo, se você estiver executando um sprint de duas semanas, no qual sua equipe fará um mergulho profundo na análise para se preparar para uma rodada de experimentos no site de um cliente, poderá definir “Enviar descobertas de auditoria ao cliente” como sua meta de sprint. Seu próximo sprint depois disso pode ser “Enviar wireframes de variação de teste ao cliente”.
Uma característica mais definidora de um sprint é que normalmente é definido qual será o objetivo, e quaisquer solicitações extras de trabalho que inviabilizem esse objetivo serão colocadas no backlog e consideradas para inclusão no próximo sprint. Isso pode ser complicado se você estiver lidando com clientes, pois você sabe que o processo pode ser prejudicado por emergências e necessidades urgentes.
Leve isso em consideração e considere agendar um horário para a semana que não é considerada parte do sprint para lidar com os “deveres” dos clientes.
Planejamento de Sprint
Antes que um objetivo de sprint possa ser estabelecido, uma equipe Scrum precisa executar uma sessão de planejamento de sprint.
Nesta sessão de planejamento, é onde toda a equipe colabora na definição do trabalho a ser realizado e da meta do sprint para o próximo sprint. O tempo de planejamento do sprint não deve exceder 2 horas por semana do sprint. Portanto, um sprint de duas semanas deve ter no máximo quatro horas de planejamento antes do início.
O planejamento da Sprint responde a duas perguntas principais:
- O que pode ser entregue no próximo Sprint?
- Como o trabalho necessário para atingir as metas do sprint será concluído?
O que pode ser entregue no próximo sprint?
É aqui que a equipe do Scrum se reúne para decidir em quais itens da lista de pendências se concentrar no próximo sprint. Depois que a equipe decide o que priorizar, eles trabalham juntos para estabelecer a meta principal do sprint.
Decidir sobre uma meta de sprint singular nem sempre pode ser prático para uma equipe de marketing ágil com diversos projetos ou clientes em andamento. Você pode resolver isso estabelecendo vários objetivos para o seu sprint.
Uma vez que a equipe tenha decidido sobre os itens da lista de pendências para trabalhar neste Sprint e os objetivos gerais do Sprint, eles poderão se concentrar em como atingir os objetivos e concluir os itens previstos para o próximo Sprint.
Como será realizado o próximo trabalho?
Quando você decide o que focar e como conquistar esses itens, você os coloca em um Backlog do Spring.
Esse backlog do sprint é o que a equipe fará referência durante o sprint como sua fonte de tarefas durante o sprint. Esse planejamento é feito de forma colaborativa à medida que a equipe se auto-organiza. O Dono do produto pode definir alguns trilhos de proteção mínimos para itens essenciais no trabalho.
O Scrum diário
Muitas equipes de marketing já fazem reuniões diárias, portanto, o Scrum diário não deve ser uma novidade.
Utilizando como referência o Guia Scrum, “O Scrum diário é uma reunião de 15 minutos para a equipe ajustar atividades e planejar atividades para o próximo dia de trabalho. Esta tarefa é realizada através da inspeção do trabalho desde o último Scrum Diário e prevendo o trabalho que poderia ser feito antes do próximo. Esta reunião é realizada da mesma forma, incluindo horário e local, visando diminuir a complexidade.”
Durante esta reunião, cada membro da equipe responde a três perguntas principais:
- Quais atividades realizei ontem que ajudam a bater a meta do sprint?
- Quais atividades realizarei hoje para ajudar a bater a meta do sprint?
- Existem obstáculos à frente que irão interferir na minha capacidade de cumprir a meta do sprint?
Um dos maiores benefícios do Scrum diário é que elimina reuniões desnecessárias que assolam muitas empresas. Em vez de cinco reuniões ad-hoc diferentes de “bases de toque” a cada semana, a equipe pode lidar com as coisas antecipadamente, diariamente, no stand-up diário do Scrum.
Analise e compartilhe o Sprint revisado
Respire fundo, seu sprint acabou!
Felizmente, a equipe foi capaz de trabalhar com eficiência e flexibilidade e atingir os objetivos do sprint. Com o sprint terminado, agora é hora da revisão do sprint. Essa é a chance da equipe de mostrar um pouco às partes interessadas no trabalho.
Essa reunião não deve demorar mais de uma hora por semana do sprint.
De acordo com o Guia Scrum, para revisar um sprint você deve:
- A equipe Scrum e todas as partes interessadas devem participar da reunião
- O Dono do produto deve explicar quais itens do Backlog foram concluídos com êxito
- A equipe de desenvolvimento avalia tudo que fluiu bem e o que não deu certo
- A equipe de desenvolvimento mostra o trabalho que foi concluído
- Todo o grupo colabora com ideias sobre o que fazer na sequência visando melhorar os Sprints
- Momento de revisar como o mercado pode ter mudando neste período e a forma de usar o produto
- Momento de rever cronograma, orçamento, recursos potenciais e necessidade do mercado para a próxima versão de liberação do produto
Saindo da revisão do sprint, a equipe terá cruzado os itens do Backlog do Produto, conforme concluído e Concluído. Isso ajudará a definir o curso e os objetivos no próximo Sprint.
Use a Retrospectiva do Sprint para melhorar iterativamente
A retrospectiva do sprint (retro) é onde a equipe faz uma análise crítica de si mesma e ganha e perde ao longo do último sprint. O objetivo aqui é definir melhorias para o próximo Sprint.
O Retro está após a revisão do sprint, mas antes da próxima rodada de planejamento do sprint. Essa reunião não deve durar mais que uma hora a cada duas semanas de tempo de corrida. Esta reunião é organizada e facilitada pelo Scrum Master, pois é a principal pessoa responsável por fazer a equipe do Scrum maximizar a eficiência e aumentar a velocidade.
De acordo com o Guia Scrum, o objetivo do Retros é:
- Inspecione como foi o último sprint em relação a pessoas, relacionamentos, processos e ferramentas
- Identifique e encomende os principais itens que foram bem e as possíveis melhorias
- Crie um plano para implementar melhorias na maneira como a equipe Scrum faz seu trabalho
Embora as melhorias nos processos da equipe possam ser feitas a qualquer momento, ter um processo formalizado e iterativo com o Retro pode trazer foco e propriedade para a maneira como a equipe trabalha e como melhorá-la.
Scrum “Artefatos” para Marketing Agile
No Scrum, existem três estruturas projetadas para fornecer transparência e responsabilidade ao trabalho da equipe:
- Lista de produtos pendentes
- Backlog da Sprint
- Incremento
Essas são as chaves para criar a infraestrutura que permite os processos de trabalho iterativos que dão à Scrum a reputação de sobrecarregar as equipes. Eles são necessários para facilitar o marketing ágil nas organizações.
Backlog do produto (Backlog do cliente)
Seguindo o Guia oficial Scrum, “O Backlog de produto é composto fundamentalmente por uma lista com uma ordem lótica de tudo que será obrigatório no produto e é o único lugar onde concentram os requisitos de todas as alterações pendentes de realização no produto. O Dono do Produto é a pessoa que fica responsável por este Backlog, considerando desde o conteúdo até a disponibilidade.”
Uma diferença que temos que fazer aqui é quanto ao termo “Backlog do Produto” é proveniente do software e do design do produto e pode também utilizado como “Backlog do Cliente” quando analisado no contexto de uma agência ou “Backlog de Teste” para uma equipe de CRO em diferentes contextos.
O Backlog lista os “recursos, funções, requisitos, aprimoramentos e correções que compõem as modificações a serem feitas no produto / software em versões futuras. Os itens do Backlog do produto têm atributos de descrição, ordem, estimativa e valor. ”
Para equipes de agências focadas em CRO, o “Backlog do cliente” pode listar todos os “Estudos, testes, relatórios e trabalho de design” que o cliente precisa.
Um processo de melhoria e refinamento do Backlog do Produto é como a equipe cria e mantém o Backlog. Esta etapa é realizada pelo Dono do Produto (Dono do Cliente) e pela Equipe.
Este deve ser um procedimento constante de forma que o Dono do produto e os desenvolvedores oferecem suas colaborações em todos os detalhes dos itens listados no Backlog.
Os itens na parte superior do Backlog na maioria das vezes serão mais claros e detalhados do que os itens inferiores, à medida que se aproximam de serem movidos para o backlog do sprint. Os itens do Backlog do produto que estão prontos para serem trabalhados e que podem ser concluídos razoavelmente no próximo sprint são considerados “Prontos”.
Sprint Backlog
De acordo com o Guia oficial, “O backlog do sprint é composto por itens do Backlog do produto / software inseridos para o Sprint, além de um plano para concluir o incremento do produto e bater a meta estabelecida para o Sprint. Trata-se de uma previsão da equipe sobre qual será a funcionalidade no próximo incremento e o trabalho necessário para entregar essa funcionalidade em um incremento com status de “Concluído”. “
A lista de pendências do sprint é o único local em que a equipe rastreia e monitora o progresso nos itens durante o sprint, enquanto trabalham em direção aos objetivos do sprint.
A equipe modifica e move os itens durante o sprint do backlog do sprint para Em andamento para Concluído. As placas Kanban são uma maneira comum de visualizar e acompanhar esse fluxo.
Incremento
Uma restrição essencial para manter a integridade do sprint é o conceito de um “incremento”.
No software, isso significa uma nova versão funcional do que está sendo trabalhado, mas para uma equipe de marketing ágil ou CRO, isso é um pouco diferente.
Basicamente, no final de um Sprint, tudo o que foi colocado na fila como um item de backlog do sprint deve ser CONCLUÍDO. Não está quase lá – FEITO.
Dessa forma, à medida que o sprint termina, as tarefas também são concluídas, permitindo que a equipe prossiga para a próxima rodada de planejamento do sprint com uma lousa limpa e o trabalho concluído.
Qualquer tarefa não concluída é considerada desperdício no final do sprint de forma que deverão ser planejadas novamente.
Personalizando o Scrum para ser utilizado com equipes de marketing ágil e CRO
Neste artigo, tentei incluir considerações sobre onde as raízes de software do Scrum não se encaixam na maneira como os profissionais de marketing digital trabalham. No entanto, se você for criativo, poderá aplicar quase tudo isso diretamente.
O principal desafio que algumas empresas enfrentam ao implementá-lo em suas equipes de marketing de conteúdo é tentar executar o Scrum meio período, em vez de se comprometer totalmente. A desvantagem dessa estratégia é que ela acaba criando mais trabalho e estresse para a equipe, pois neste caso existe backlogs pessoais e o Scrum para gerenciar e trabalhar.
Se eu puder recomendar uma coisa a alguém que leu isso e vai testar a implementação do Scrum, faça tudo. Se não funcionar para a sua organização, tudo bem, mas se comprometa com o teste.
Conclusão
O desenvolvimento ágil (Scrum) é uma estrutura para o desenvolvimento ágil de softwares, mas esta estrutura pode ser facilmente aplicada para equipes de marketing em agências ou ainda em setores de empresas de outros segmentos.
Os benefícios para isso são muitos: iteração mais rápida, mais produtividade, melhores campanhas. Uma organização de marketing ágil é o contexto perfeito para uma equipe de experimentação ou otimização prosperar. Cria uma cultura de experimentação – uma cultura iterativa e orientada a dados.
Como você opera seu departamento de marketing? É mais parecido com o marketing tradicional em cascata ou você opera uma equipe de marketing inovadora e ágil?
De 0 a 10, o quanto você recomendaria este artigo para um amigo?