Scrum é um framework ágil que surgiu nos anos 90 para desenvolver, entregar e manter produtos complexos. Porém, ele pode ser aplicado em diferentes setores, equipes e situações, inclusive no Marketing. O Scrum possui papéis, rituais e regras, que devem ser seguidos para obter sucesso com o framework.
Quando estiver lidando com gerenciamento de projetos, certamente você vai se deparar com o termo Scrum mais cedo ou mais tarde - se é que isso já não aconteceu. Esse é um termo que revolucionou o trabalho de desenvolvimento de software em todo o mundo, mas também representa uma nova maneira de como lidamos com projetos em outras áreas.
Para entender o que Scrum significa, você deve primeiro entender o conceito de Metodologias Ágeis. Embora esses termos estejam conectados, há uma diferença importante entre eles.
Metodologias Ágeis tratam de processos que destacam o trabalho em equipe, a colaboração próxima com os clientes, a distribuição de entregas frequentes de versões de trabalho e respostas rápidas às mudanças.
Já o Scrum é apenas uma das muitas maneiras de desenvolver esses processos ágeis, se enquadrando como uma dessas metodologias - outros exemplos são o Lean, Kanban e Smart. Essa é uma abordagem mais específica, com papéis e rituais bem definidos para o gerenciamento de equipe e atividades.
O objetivo deste conteúdo é mostrar em detalhes o que é de fato o Scrum, como ele funciona e apresentar, de forma prática, como implementar ele na sua equipe. Trazemos também um exemplo de como a Resultados Digitais fez isso dentro do time de Marketing.
O que é Scrum?
Com nome inspirado na formação de uma jogada do Rugby, o Scrum, em sua essência, é um framework usado para desenvolver, entregar e manter produtos complexos. Ele é usado desde o início dos anos 90, que possui claro seus papéis, rituais e regras.
Mas sua origem inicia de fato em 1986 com um artigo chamado “O novo jogo de desenvolvimento de novos produtos”, escrito por Hirotaka Takeuchi e Ikujiro Nonaka, publicado pela The Harvard Business Review. Lá os autores descrevem duas abordagens diferentes para gerenciar o desenvolvimento de produtos:
- algumas equipes trabalhavam como corredores em uma prova de revezamento: seguiam em linha reta, passando o bastão para o próximo responsável da entrega seguinte;
- outras equipes funcionavam como jogadores de Rugby: todos jogavam juntos uma única partida, e passam as entregas para frente e para trás no processo, conforme é necessário.
Mas foi em 1993 que Jeff Sutherland teria criado o Scrum, fazendo uma analogia direta ao artigo de Takeuchi e Nonaka. A primeira aplicação aconteceu no trabalho da Easel Corp., uma empresa de desenvolvimento de software.
Sutherland inclusive fez parte do Manifesto Ágil, um marco na indústria. Ele foi criado em 2001 com os valores e princípios essenciais para o desenvolvimento de softwares, junto com outros 16 profissionais.
Os principais valores apresentados no manifesto ágil são:
- Indivíduos e interações mais que processos e ferramentas;
- Software em funcionamento mais que documentação abrangente;
- Colaboração com o cliente mais que negociação de contratos;
- Responder a mudanças mais que seguir um plano.
Já em 2014, com o Scrum sendo utilizado pelas principais empresas de desenvolvimento de software do mundo, foi publicado o principal livro de Jeff Sutherland sobre o tema, chamado Scrum: a arte de fazer o dobro do trabalho na metade do tempo.
Apesar de ter sido criado para times de produto, o Scrum tem sido usado em escolas, governos, equipes de Marketing e várias outras equipes descritas no próprio livro.
Por ser um framework e não uma metodologia, está em um constante processo de melhoria e adaptação. Porém, para seu sucesso, é necessário manter e garantir cada um de seus componentes.
Metodologia versus framework
O Scrum é um framework, não uma metodologia. É importante entender a diferença de significado, para não aplicá-lo da maneira errada.
Metodologias são conjuntos de métodos e técnicas que, a partir de estudo e embasamento científico, se comprovaram eficazes para uma certa finalidade. Já um framework, por outro lado, pode ser explicado de maneira geral como uma estrutura de conceitos básicos que servirão de norte para o seu trabalho.
Enquanto metodologias apresentam caminhos definidos e trilhados, um framework pressupõe apenas que diante de qualquer coisa que apareça nesse caminho, o modo de pensar e buscar uma solução será o mesmo.
Por isso, não adianta simplesmente “seguir a receita”. É importante entender os porquês e saber adaptar à realidade da sua equipe, preservando a essência do Scrum, que é de transparência, colaboração e agilidade.
Além do mais, scrum se aprende na prática! No começo, muita coisa pode sair ainda meio “torta”, mas a melhoria contínua está na essência do scrum - mais adiante vamos falar das reuniões de retrospectiva.
>> Leia mais: Gestão de projetos em Marketing Digital: o que é, qual é a importância e tudo o que você precisa saber
Como o Scrum funciona?
Logo abaixo você confere como é criada uma estrutura de funcionamento do Scrum. Em resumo, ela é baseada em:
- Equipe: contendo o Product Owner, Scrum Master e o Time em si;
- Estrutura principal: que é a Sprint, trabalhada através do Product Backlog, Sprint Backlog e dos Trabalhos finalizados;
- Eventos e cerimônias: com o Sprint Planning, Sprint Review, Sprint Retrospective e a Daily.
Dividindo o trabalho (backlog) por sprints
No Scrum, tudo que existe para ser feito está concentrado em uma lista, devidamente ordenada pela prioridade, chamada Backlog de Produto. A tradução literal de backlog é acúmulo, no sentido de trabalho acumulado a ser feito.
Na prática, sua equipe pode trabalhar com um backlog por “produto” — no caso dos times de Marketing que aplicam Scrum, os produtos podem ser representados como a criação de um site ou uma campanha de Inbound Marketing — ou mesmo um backlog por time, fazendo uma divisão prévia de qual time ficará responsável por quais entregas.
No backlog, é importante que cada item da lista seja uma entrega de valor para o objetivo final, mesmo que não seja, por si, um lançamento completo.
Exemplo prático para a Sprint
Para tornar esse processo de divisão de backlog e sprint mais claro, vamos trazer um exemplo já adaptando os conceitos para o trabalho de Marketing.
Digamos que uma equipe precisa lançar uma campanha para divulgar um novo material. Nesse caso, a publicação da Landing Page entrega valor para o objetivo final, ainda que depois de finalizá-la seja necessário fazer outras ações para lançar a campanha, como botões de Call-to-Action no site ou anúncios em mídias pagas.
Por outro lado, a simples definição de quais serão os campos de um formulário não entrega um valor concreto, por ser muito granular. Para dar vazão ao trabalho contido no Backlog, o time responsável divide a entrega em sprints. Cada sprint é um período fixo de tempo com um backlog fixo, chamado de backlog da sprint (sprint backlog).
Isto é muito importante: uma vez planejado o backlog de uma sprint — vamos explicar mais adiante como isso é feito —, ele não deve ser alterado! Este é um dos principais pontos que mantém o time focado e produtivo.
O que fazer quando surgir uma demanda fora da sprint?
É o próprio time que se compromete com a entrega daquilo que julga possível para uma sprint. Se alguém interfere constantemente nesse compromisso, aumenta o risco de nada ser entregue.
Além disso, é comum surgirem demandas urgentes e imprevistas no dia a dia. Idealmente, elas não devem entrar no meio de uma sprint já planejada, mas vale usar o bom senso: se você aceitar sem nenhum critério qualquer mudança na sprint, coloca todo o projeto em risco. Por isso, capriche na negociação de prazos das entregas.
O tempo recomendado para uma sprint fica entre uma semana e um mês, conforme a complexidade do produto ou projeto. Como não é recomendado interferir no backlog da sprint, o ideal é planejar as primeiras com apenas uma semana. Assim, se surgir um imprevisto ou demanda urgente, você não precisa esperar tanto tempo até a próxima sprint começar.
Os três papéis principais do Scrum
Para tornar as coisas mais simples, o Scrum propõe que o time seja composto por 3 papéis essenciais para o sucesso da entrega.
Scrum Team
O Scrum Team são os profissionais responsáveis pelas entregas no final de cada uma das Sprints. Esses profissionais são auto-organizados, multi-funcionais e possuem ownership com as entregas de toda a equipe.
A equipe, formada por 5 a 9 pessoas, é quem vai transformar os requisitos mapeados em realidade. Definida a equipe, precisamos agora de duas pessoas chave em todo o processo: o Product Owner e o Scrum Master.
Product Owner (Dono do Produto)
É papel do PO, como são conhecidos os Product Owners, receber as demandas, entendê-las, processá-las e priorizá-las, em conjunto com o time. Não existem dois Product Owners em um time!
Processar as demandas significa traduzi-las em requisitos simples, especificando a “Definição de Pronto”, que é uma forma de sinalizar quais são os critérios que servirão para validar a entrega.
Então cabe ao Product Owner gerenciar o Backlog de Produto, definindo os itens que entram lá, ordenando de acordo com as prioridades e garantindo clareza no backlog.
Um detalhe importante: o PO deve ter uma visão clara do produto e deve transmitir ela para todo o time, por isso precisa de um sólido conhecimento do negócio e boa comunicação.
Também existe um “acordo de cavalheiros” entre Product Owner e Scrum Team: o time se compromete a entregar as atividades que entraram na Sprint. Já o Product Owner se compromete em não trazer novas demandas durante a Sprint.
Scrum Master
Durante uma sprint, é comum surgirem imprevistos e impedimentos que colocam em risco a entrega estabelecida para aquele período. Ou pior ainda: distrações e solicitações “atravessadas” que tiram o foco do objetivo. É papel do Scrum Master blindar o time de influências externas e ajudar a remover impedimentos.
A pessoa que assume esse papel não é formalmente a líder do time, mas sim a responsável por garantir a aplicação do Scrum, bem como o foco e o fluxo de trabalho. Ainda assim, muitos lugares acabam estabelecendo essa hierarquia formal, o que pode funcionar, dependendo do contexto.
Além de fazer parte do time e trabalhar nas entregas, o Scrum Master ajuda os outros membros da equipe a remover impedimentos, aumentarem a produtividade e garantir a entrega da Sprint.
O Scrum Master também é o braço direito do Product Owner, facilitando os eventos, auxiliando na compreensão do backlog de produto e em todos os outros aspectos do Scrum.
Elementos da estrutura do Scrum
Agora vamos conhecer os elementos básicos que criam a composição principal do Scrum, onde os profissionais devem atuar a cada projeto.
Backlog de Produto
O Backlog de Produto é onde se concentra tudo que é necessário realizar, sendo a única fonte de demandas para as Sprints. O Product Owner é o responsável por ele: deve manter atualizado, com todas as ações e priorizado.
Ele está em constante atualização, pois evolui em conjunto com o produto. Em cada Sprint Planning, a equipe, em conjunto com o PO, movem as demandas que serão priorizadas durante o período para o Backlog da Sprint.
Backlog da Sprint
O Backlog da Sprint é o conjunto de demandas do Backlog de Produto priorizados na Sprint e deve estar sempre visível para toda a equipe. Essa priorização é feita através da dinâmica de votação, onde são atribuídos pontos de urgência e o tempo de execução de cada atividade.
Ao montar o backlog da Sprint, a equipe e o Scrum Master devem ficar atentos ao acumulado de pontos de estimativa: se estiver muito acima da média atingida em cada Sprint, provavelmente a equipe não vai conseguir entregar tudo no prazo.
Também é importante o Scrum Master garantir que toda demanda tenha pelo menos um membro da equipe atribuído e também tenha seus pontos de estimativa. Isso garante que todas as demandas tenham um responsável e não fiquem abandonadas no Scrum Board.
Sprint
Já falamos sobre ela, mas para deixar claro, a Sprint é o período de execução das ações incluídas no Backlog da Sprint, que vai da reunião de Sprint Planning até a reunião de Sprint Retrospective e Sprint Review.
A duração de uma Sprint pode variar de acordo com o time e suas entregas. Em times de produto é comum uma Sprint durar 15 dias ou todo o mês (não deve passar disso). EM outras equipes, como acontece no Marketing, é comum optar por Sprints semanais, indo de segunda a sexta-feira.
A Sprint é o coração do Scrum, e para manter rodando da melhor forma deve seguir algumas regras básicas:
- Não são feitas mudanças que possam pôr em perigo o objetivo da Sprint;
- As metas de qualidade não diminuem;
- O backlog pode ser renegociado entre o Product Owner e o Scrum Team.
Agora vamos entender mais sobre os elementos que tornam a Sprint uma realidade.
Scrum Board
O Scrum Board é onde todas as informações ficam organizadas e deve estar sempre visível para todos os membros da equipe, e se possível para outras equipes também.
É muito semelhante ao Kanban, com “cards” para as entregas e colunas separando suas etapas: “to do”, “in progress” e “done. No exemplo abaixo, também existe uma coluna de “pause” para tarefas que estão com algum impedimento.
Uma boa prática para garantir o foco é não ter mais que 3 cards somados nas colunas de “in progress” e “pause”. Exemplo de Scrum Board, feito na ferramenta Vivify Scrum
A forma mais comum de ter o Scrum Board é um quadro, com linhas e post-its. Essa forma é eficiente pois o quadro é visível não só por todo o time, mas também por toda a empresa, e acaba tornando as interações mais impactantes. É importante combinar uma comemoração quando algum item é passado para a coluna “Done”, por exemplo.
Também existem diversas ferramentas pagas e gratuitas para fazer o quadro. A mais comum é o Trello, um verdadeiro coringa quando falamos de gestão de tarefas, mas também existe o Vivify Scrum, que possui funcionalidades dedicadas para o Framework e acabou atendendo melhor essa necessidade.
Pontos de Estimativa
Aqui conseguimos dimensionar o tamanho das tarefas e com isso entender o quanto é possível alocar em cada Sprint e a velocidade do time, algo essencial no Scrum.
Com os pontos de estimativa nas tarefas, é possível entender quantos pontos a equipe está entregando Sprint após Sprint. Aumentar a quantidade de pontos por Sprint representa um aumento na velocidade de entregas e, consequentemente, de produtividade.
Exemplo de pontos de estimativa incluídos na demanda
Os pontos podem ser baseados em alguma referência temporária, como horas ou dias, mas não é algo necessário. Uma boa sugestão no começo é considerar que um ponto equivale à aproximadamente uma hora.
Para evitar problemas dificuldades na hora de estimar os pontos de cada entrega, é recomendado usar a Sequência de Fibonacci nos pontos, em que o próximo número é resultado da soma dos últimos dois. Assim, a pontuação fica: 0.5, 1, 2, 3, 5, 8, 13.
Se você nunca fez algo parecido e tem dificuldade para estimar os pontos para as entregas, pode usar o Planning Poker, uma técnica baseada no consenso. O Planning Poker pode ser feito pessoalmente, usando um baralho, ou com ferramentas online.
Burndown
Com todos os cards devidamente pontuados e incluídos no Backlog da Sprint, é possível criarmos um gráfico de burndown. Ele é uma visualização de quantos pontos é preciso entregar, do primeiro ao último dia da Sprint. No gráfico abaixo, temos uma linha com o número ideal de pontos e uma linha com o número de pontos entregues.
A linha que apresenta o número ideal de pontos inicia o primeiro dia da Sprint com todos os seus pontos de estimativa e fica zerada no último dia, caindo proporcionalmente dia após dia, servindo como referência para uma “Sprint perfeita”.
Já a linha com os pontos entregues vai caindo de acordo com as tarefas que são passadas para “Done” e torna previsível se a Sprint será entregue ou não.
É importante que o gráfico fique disponível para toda a equipe, seja revisado em cada Sprint Retrospective e, se possível, seja avaliado rapidamente em cada Daily.
Eventos e cerimônias do Scrum
O Scrum propõe vários encontros, chamados de cerimônias, cada um com uma periodicidade e um objetivo específico, como veremos em detalhes a partir de agora.
Talvez sejam os pontos mais importantes de todo o framework, já que os rituais podem definir o sucesso ou o fracasso ao implementar o Scrum na sua equipe. Isso porque os rituais do Scrum são reuniões que ocorrem durante a Sprint, incluindo uma reunião diária.
Daily Meeting
Talvez seja o ritual mais famoso do Scrum: uma reunião diária com toda a equipe de pé (o Product Owner não precisa participar), em frente ao Scrum Board, onde cada um fala o que fez e o que vai fazer, em resumo.
O encontro não deve durar mais de 15 minutos, e para garantir o foco e a objetividade, todos ficam de pé em frente ao quadro, onde seja possível visualizar todo o backlog da sprint.
Ali, cada um deve responder brevemente a três perguntas:
- O que eu fiz ontem que ajudou a entregar a Sprint?
- O que eu farei hoje para ajudar a entregar a Sprint?
- Vejo algo que atrapalhe a entrega da Sprint?
Lembre-se que, em um time de 9 pessoas, cada um terá pouco mais de um minuto e meio para responder às perguntas. Não é o momento de explicações muito detalhadas, muito menos de brainstorming de solução dos impedimentos. Essas questões devem ser endereçadas individualmente, fora da daily. O objetivo da daily é manter o foco e a transparência.
Para funcionar corretamente, é importante que ela ocorra sempre no mesmo local e horário, sem atraso e sem cancelamento.
Planejamento da sprint (Sprint Planning)
É o pontapé inicial da sprint e toda a equipe participa, incluindo o Product Owner, que apresenta as prioridades para a próxima Sprint. Enquanto isso, toda a equipe faz as perguntas necessárias para quebrar as prioridades em entregas técnicas.
Existem diversos formatos e dinâmicas possíveis para uma reunião de planejamento da sprint. Independente de como você escolher conduzir essa reunião, é essencial que ela marque a “migração” de parte do backlog de produto para um backlog de sprint.
No planejamento, após o Product Owner apresentar e justificar as entregas e suas prioridades, todo o time define o que se sente seguro para entregar até o final da sprint. É comum que o time transforme cada entrega de valor em uma lista de tarefas a serem realizadas, com a devida estimativa do tempo e/ou dificuldade.
Ainda assim, prazos são prazos. Não é possível atrasar uma campanha de Dia das Mães, por exemplo. Então, o time deve ser estimulado a procurar alternativas de escopo e solução, procurando uma saída que seja proveitosa para todas as partes.
Revisão da sprint (Sprint Review)
Ao final da sprint, todo o trabalho que foi concluído deve ser oficialmente entregue e apresentado aos interessados. Em alguns casos, apenas o Product Owner consegue estar presente.
A Sprint Review inclui os seguintes elementos:
- Os participantes incluem o Time Scrum e os Stakeholders convidados pelo Product Owner;
- O Product Owner esclarece quais itens do Backlog foram entregues e quais não foram;
- O time discute o que foi bem durante a Sprint, quais problemas ocorreram e como foram resolvidos;
- O time demonstra o que foi entregue e responde dúvidas;
- O Product Owner discute o Backlog do Produto;
- O grupo todo colabora sobre o que fazer a seguir;
- Revisão da linha do tempo, orçamento, potenciais capacidades e mercado.
Retrospectiva da sprint (Sprint Retrospective)
A Sprint Retrospective é um momento de avaliação, para cada membro do time criar um plano de melhorias a serem aplicadas na próxima Sprint. A reunião ocorre depois da Sprint Review e antes da Sprint Planning.
Pode durar no máximo 3 horas em Sprints maiores. Lembrando que é tarefa do Scrum Master garantir que todas as reuniões ocorram dentro do tempo estimado.
O propósito da reunião é:
- Inspecionar como a última Sprint foi em relação às pessoas, aos relacionamentos, aos processos e às ferramentas;
- Identificar e ordenar os principais itens que foram bem e as potenciais melhorias;
- Criar um plano para implementar as melhorias.
Na Retrospectiva da sprint, o objetivo é que todo o time levante pontos positivos e negativos da sprint que acabou de encerrar, sendo que os pontos negativos devem gerar acionáveis práticos de como solucioná-los, atenuá-los ou evitá-los na sprint seguinte.
Como adaptar o Scrum para uma equipe de Marketing?
Não é só as equipes de produto e desenvolvimento que precisam lidar na sua rotina com projetos longos e complexos. Diversas outras áreas possuem desafios semelhantes, como os times de Marketing.
Campanhas de divulgação, seja de produtos, serviços ou materiais demandam várias etapas de execução antes de chegar até a conclusão.
É por isso que o Scrum não fica preso apenas ao uso por times de desenvolvimento de software. Como o próprio Southerland afirma em seu livro, o framework pode ser aplicado em vários outros times e proporcionar os mesmos benefícios.
Aqui você vai conferir o exemplo real de como fizemos essa implementação na área de Marketing da RD, iniciando o processo no ano de 2018. A partir de agora, essa experiência é descrita em 1ª pessoa pelo Ewerton Silva, Head de SEO da Resultados Digitais.
Implementação do Scrum com os profissionais e times de Marketing da RD
Aqui na Resultados Digitais é comum usarmos a frase “o Marketing é a locomotiva da empresa”. Assim, lembramos que é através do Marketing Digital que nossa empresa cresce. Quando o Marketing está “a todo vapor”, acaba puxando os vagões de Vendas, Customer Success e todos os outros resultados que precisamos.
E 2018 foi um dos anos mais intensos na nossa locomotiva. Metas cada vez mais agressivas, Lead Scoring cada vez mais exigente, expansão internacional crescendo e exigindo cada vez mais. A equipe de Marketing fez um trabalho intenso para manter a locomotiva em velocidade máxima.
Para atender tudo isso, entraram várias caras novas na equipe, que foi se tornando cada dia mais robusta.
Chegamos a um ponto em que foi decidido: vamos dividir a equipe de Marketing entre Brasil e Expansão Internacional e junto com outros profissionais, mudei meu foco 100% para nosso crescimento em outros países.
Acredito que isso trouxe várias vantagens, principalmente trazendo foco na operação. Antes, ela acabava ficando dividida entre os países e, em um caso de emergência, era difícil saber o que priorizar.
Mas por englobar canais e conteúdo, a equipe de Marketing Internacional era composta por mais de 15 pessoas, tornando a gestão um pouco mais distante da rotina dos profissionais e exigindo uma autogestão eficiente.
Scrum como caminho para tornar a rotina mais eficiente
No processo de tornar minha autogestão cada vez mais eficiente, além do desejo de aumentar a produtividade, cheguei até o livro de Jeff Sutherland.
O livro é incrível. Apresenta casos reais de aplicação do framework com ganhos incríveis de eficiência e tira uma dúvida que sempre tive: apesar de ter sido desenvolvido para gerenciar e desenvolver produtos, dá para aplicar em diversas áreas e situações.
Ao terminar o livro, estava ansioso para chegar a próxima semana e começar a testar o framework na minha rotina, e foi o que fiz. Mesmo sem um “Scrum Team”, consegui seguir a maior parte das diretrizes do framework e já nas primeiras Sprints vi uma melhora incrível na gestão de tarefas e na produtividade.
Antes de começar os testes na minha rotina e em nossa equipe, busquei outras referências de aplicação do framework em equipes de Marketing. Notei que, por se tratar de algo que está constantemente sendo adaptado e melhorado, as outras aplicações não se encaixavam muito em nossa realidade.
Por isso decidi fazer como a maioria das equipes fazem: iniciamos o Scrum em sua essência e fomos adaptando semana a semana. Hoje utilizamos o Scrum com todo o time, aumentando a velocidade das entregas de todos, gerando grandes aprendizados e aprimorando o que fazemos a cada semana.
Veja a seguir como adaptamos cada uma das características do Scrum em nossa equipe.
Equipe
Antes de avançarmos em backlog, sprints e outras características, é importante apresentar nossa equipe e como adaptamos cada uma das funções essenciais do Scrum para nosso time. Lembra que mencionei que o time de Marketing Internacional contava com mais de 15 pessoas?
No livro e em diversas documentações sobre o assunto, todos os autores são muito claros nisso: o time não pode ter mais de 9 pessoas. Acima disso, fica muito difícil gerenciar e acaba tornando várias outras características que deveriam ser simples em algo complexo.
Uma coisa é uma reunião diária de 15 minutos com 9 pessoas. Já imaginou com 18? Então o primeiro passo foi reduzir nosso time para no máximo 9 pessoas, com as funções mais relacionadas as principais entregas do time. Com isso, nosso time ficou em 7 pessoas.
O Scrum Team, formado por essas 7 pessoas, são os profissionais responsáveis pelas entregas no final de cada uma das Sprints. Um exemplo multi-funcional é do nosso especialista em Email Marketing, que precisou realizar um projeto de melhoria na geração de conversões de Fundo de Funil.
Olhando sua especialidade, não é sua função olhar para nossas Landing Pages e pontos de conversão no site e analisar sua eficiência. Porém, ele tinha as melhores habilidades para realizar o projeto.
Definida a equipe, precisamos agora de duas pessoas chave em todo o processo: o Product Owner (no nosso caso, Marketing Owner) e o Scrum Master.
Product Marketing Owner
Ao adaptar para o Marketing, o nosso “Marketing Owner” possui características semelhantes ao PO. No Marketing, o acordo entre Marketing Owner e o time é que, novas demandas devem ser evitadas, mas podem entrar na Sprint desde que demandas com o mesmo peso sejam despriorizadas.
No caso do nosso time, o Marketing Owner cria as demandas no Backlog somente em situações em que não temos um membro com experiência no assunto para assumir a entrega. Assim, sua atribuição é definida em comum acordo com a equipe, na reunião de Sprint Planning.
Ele também define o objetivo da Sprint e auxilia o Scrum Master a manter a Sprint rodando, usando sua influência na empresa para destravar demandas que dependem de outros times e áreas.
Scrum Master
Vimos que o Scrum Master é responsável por garantir que todo o time mantém as características do Scrum, ajudando a entenderem a teoria, práticas e a importância de cada aspecto. Por tudo isso, é muito importante que o Scrum Master da equipe de Marketing seja a pessoa com maior familiaridade com o Framework.
No nosso caso, como estudei e dei início a adoção do Scrum na minha equipe, me tornei o Scrum Master. Desde então tivemos treinamentos, conversas para tirar dúvidas pontuais da equipe, seja nos rituais do Scrum ou em corredores e várias melhorias nas práticas do Framework, sempre visando manter o time engajado e cada vez mais produtivo.
Um exemplo são as reuniões diárias que no começo fazíamos informalmente em uma TV no corredor. Porém os ruídos em volta começaram a atrapalhar a reunião. Coube ao Scrum Master (no caso, eu) buscar uma melhor alternativa para realizarmos as reuniões sem interrupções ou demora para conectar o notebook na TV, garantindo a duração máxima de 15 minutos por dia.
Outro exemplo é se, durante uma reunião diária, vejo que um membro da equipe está com muitas demandas a fazer e a Sprint está chegando ao fim: nesse caso é preciso entender a prioridade das demandas, sua relação com o objetivo da Sprint e se outro membro da equipe consegue absorver.
Esses exemplos mostram como o Scrum vai se aperfeiçoando quando executado e como o trabalho do Scrum Master é fundamental para garantir esse desenvolvimento.
Adaptando a estrutura do Scrum para o Marketing
Assim como os papéis do Scrum, a sua estrutura também deve ser adaptada para a realidade dos times de Marketing. O que realizamos dentro da equipe foi o seguinte:
- Backlog de Produto Marketing: no caso do Marketing, o backlog é mais dinâmico, pois é atualizado pelo próprio time, de acordo com as prioridades passadas pelo Marketing Owner. Porém o Marketing Owner tem total liberdade de incluir novas demandas, atribuí-las a membros da equipe e repriorizá-las;
- Backlog da Sprint: no caso de uma equipe de Marketing, é importante que todas as demandas da semana entrem no Backlog da Sprint: reuniões, relatórios, projetos, etc. Uma regra que pode ser usada é que tudo que tomar no mínimo meia hora deve entrar no Backlog da Sprint;
- Sprint: é importante que cada Sprint possua um objetivo claro de entrega, para toda a equipe ter um norte na hora de priorizar as ações. Por exemplo: se a geração de Leads está abaixo da meta, o objetivo da Sprint pode ser reverter esse cenário.
Adaptação dos Rituais do Scrum
Não sei você, mas eu evito ao máximo fazer reuniões, pois muitas vezes parece uma perda de tempo. É claro que existem exceções, e as reuniões do Scrum estão inclusas na lista.
Cada um dos Rituais do Scrum são essenciais para manter o framework rodando no Marketing, a equipe alinhada e gerar um impacto positivo na produtividade de todos.
-
Sprint Planning: no caso da nossa equipe de Marketing, cada membro já traz para reunião seu backlog preenchido com tarefas de rotina e entregas que já estavam previstas para a semana que se inicia, usando a priorização do Marketing Owner para incluir novas demandas na Sprint e suas priorizações;
-
Daily Meeting: como Scrum Master da nossa equipe, faço anotações de melhorias ou coisas que preciso conversar com algum membro da equipe após a reunião. Lembre-se: se perder o controle das reuniões diárias, elas vão se tornar o maior ladrão da produtividade da equipe e tudo que foi feito será em vão;
- Sprint Review: a Sprint Review é realizada ao final da Sprint para avaliar seu incremento e adaptar o backlog, se necessário. Durante a reunião, toda a equipe conversa de forma informal sobre o que foi feito na Sprint, com objetivo de gerar maior colaboração entre a equipe. No nosso caso, juntamos a Sprint Review e a Sprint Retrospective em uma reunião de no máximo 30 minutos;
- Sprint Retrospective: o Scrum Master usa a reunião para incentivar o time a melhorar seu processo de desenvolvimento para a próxima Sprint e, ao final da Sprint Retrospective, o time deverá ter identificado melhorias que serão implementadas na próxima Sprint.
Dicas finais para aplicar o Scrum na prática
Como avisamos no início, não é produtivo encarar o Scrum como uma metodologia ou uma receita de bolo. O ideal é entender os princípios que embasam essa forma de trabalhar e se organizar, aplicando com adaptações ao contexto da sua equipe.
Para projetos com escopo mais definido e data de entrega, o Scrum pode não fazer tanto sentido, uma vez que seu valor está na definição do escopo ao longo do projeto. Como em toda metodologia ágil, os envolvidos pressupõem que não sabem exatamente todo o trabalho que precisará ser feito, nem como deverá ser feito, e por isso valorizam a estrutura do Scrum.
No entanto, vale a reflexão: será que mesmo para projetos cujo escopo parece “simples e bem definido”, não é melhor experimentar uma abordagem que permita o surgimento de soluções criativas ao longo do processo? Então, que tal fazer um teste e observar os resultados?
Para saber de mais dicas que vão apoiar o processo de gestão na área, confira tudo da Semana da Gestão de Marketing!
Post originalmente publicado em junho de 2019 e atualizado em setembro de 2020.
