Em 2001, um grupo de especialistas e experientes em desenvolvimento de software publicou um manifesto que continua influenciando a maneira como se pensa e faz tecnologia até hoje.
O Manifesto para Desenvolvimento Ágil de Software (Agile Manifesto) dizia o seguinte:
Estamos descobrindo maneiras melhores de desenvolver software, fazendo-o nós mesmos e ajudando outros a fazerem o mesmo. Através deste trabalho, passamos a valorizar:
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
Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.
Esses conceitos se espalharam rapidamente, pois era evidente o quanto eles ajudavam os times a alcançar o sucesso mediante entrega de sucesso ao cliente.
Diversas metodologias e frameworks ágeis foram criados a partir do manifesto, todos com seu devido valor. Um desses frameworks, o Scrum, teve rápida difusão e acabou extrapolando o segmento de software e chegando a outras áreas como marketing, vendas e até recrutamento e seleção.
Neste post, além de apresentar o Scrum e seu funcionamento, separamos exemplos e dicas pertinentes ao mundo de agências e de Marketing Digital, para ajudar você a ter mais agilidade e transparência na gestão das suas entregas.
Vamos lá!
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.
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, frameworks pressupõem 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 agência, 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!). Então, logo as coisas se ajeitam!
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 agência pode trabalhar com um backlog por “produto” — como um site ou uma campanha de Inbound Marketing — um backlog por cliente 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 cliente, mesmo que não seja, por si, um lançamento completo.
Exemplo
Em uma campanha de Black Friday, uma Landing Page publicada entrega valor para o cliente, ainda que depois de finalizá-la, você precise de outras ferramentas para lançar a campanha, como botões de Call-to-Action para o 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 de Produto, 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.
Dicas especiais para adotar o modelo Scrum
É 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 com o cliente. 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 e até a operação da sua agência em risco. Por isso, capriche na negociação de prazos com o cliente e na antecipação de urgências e imprevistos!
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
Em todo projeto existem diversos interessados. Da parte do cliente, existe aquela pessoa que fala diariamente com a agência (geralmente da equipe de atendimento), mas há também a liderança, e a liderança da liderança e por aí vai, sem falar de outros setores e áreas interessados no projeto. Da parte da sua empresa, não é diferente: o gerente de sucesso do cliente, a equipe criativa, desenvolvedores… todos envolvidos.
Veja mais: Modelo de organograma: como estruturar e escalar sua agência digital
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.
Product Owner (Dono do Produto)
A voz do cliente é representada pelo Product Owner (ou PO). Não importa quantas pessoas interessadas existam do lado “cliente”: é papel do PO 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.
O PO é o “dono do backlog de produto”. É para ele que o time realiza a entrega. Profissionais de Atendimento ou Sucesso do Cliente podem até fazer esse papel, mas a chance de ter um conflito de interesses é grande. O ideal é que o PO seja parte do time, e não parte do cliente, e esteja sempre disponível para o Scrum Master e a Equipe de Desenvolvimento.
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.
Veja mais: Os 7 hábitos das agências altamente eficazes
Equipe de Desenvolvimento
A equipe, formada por 5 a 9 pessoas, é quem vai transformar os requisitos mapeados pelo PO em realidade. No contexto de uma agência, quase sempre essa equipe será multidisciplinar, formada por designers, redatores, programadores e outros perfis necessários para produzir uma entrega completa e de qualidade.
O ideal é que a equipe se auto-organize, inclusive no que diz respeito a projetar a solução e dividir as tarefas. Mas quando cada um tem uma especialidade, esse pode ser um preceito do scrum bem difícil de aplicar à prática.
Eventos e cerimônias
O scrum propõe vários encontros, chamados de cerimônias, cada um com uma periodicidade e um objetivo específico:
Daily Meeting
A reunião diária é uma forma de todo o time fazer um repasse do status da sprint. 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 ou outro artefato onde seja possível visualizar todo o backlog da sprint.
Ali, cada um deve responder brevemente a três perguntas:
- O que você fez, desde a última daily meeting, para contribuir com a entrega da sprint?
- O que você planeja fazer, de agora até a próxima daily, para contribuir com a entrega da sprint?
- Que problemas estão impedindo ou podem vir a impedir seu trabalho de continuar?
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)
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 envolvidos.
No contexto de uma agência ou consultoria, naturalmente existem prazos que não podem ser descumpridos. Nesse caso, a recomendação é procurar não ter rigidez, nem do lado do cliente (um bom alinhamento de expectativas pode ajudar!), nem do lado da gestão (confie no seu time!), nem do time (seja criativo nas soluções!).
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. Mas sempre que possível, envolva também o cliente!
Duas coisas podem acontecer quando uma agência envolve o cliente na cerimônia de entrega. Um cliente participativo, mesmo que exigente, pode estimular o time a se sentir responsável e comprometido pelo que produziu. O time tem vontade de entregar com qualidade e no prazo, porque sabe que estará face a face com o cliente.
Um cliente exigente e não muito compreensivo, por outro lado, pode dar feedbacks desestruturados, causando um desânimo geral no time.
Cabe à agência identificar quando pode ser proveitoso juntar time e cliente nessa reunião!
Retrospectiva da sprint (Sprint Retrospective)
Geralmente, esta cerimônia acontece no mesmo “espaço” da Revisão da sprint, logo em seguida.
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.
Dicas finais para aplicar o Scrum para agências
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 agência — principalmente o tipo de serviços que você presta, o tamanho da sua equipe ou a utilização de freelancers contratados por demanda.
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 responder a mudanças mais que seguir um plano.
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?
Compartilhe com a gente nos comentários a sua experiência!
