Um exemplo prático de SCRUM em uma Campanha de Marketing (Parte II)

Leia a Parte I aqui

Planeje, fracasse, itere…

Enfim, chegamos na Sprint1 e como já sabemos, o SCRUM permite que a equipe tenha um nível de interação muito alto, principalmente pela característica de autogerenciamento e é exatamente por isso que certas regras quando combinadas entre todos de forma antecipada, tornam o ambiente mais amigável e estimulam a disciplina e organização.

Para a campanha foram necessárias algumas definições importantes previamente combinadas com o time na reunião Sprint Planning.

Sprint Planning

Definition of Ready

Aqui descrevemos o que é importante estar pronto em relação aos itens do Product Backlog para que a Sprint seja iniciada:

Definições de pronto para iniciar: à construção da Landing Page finalizada; o e-mail que será enviado devidamente finalizado com as configurações prévias do software de disparo prontas; os anúncios do Google Adwords validados; assim como os Banners finalizados e toda a configuração do Google Adwords feita e pronta para inicio da Sprint.

Definition of Done

Aqui descrevemos o que é importante estar pronto após a execução da Sprint em relação aos itens do Product Backlog:

Definição de pronto após finalizada a Sprint: as Estatísticas de acesso do Google Adwords; do Google Analitycs; dos e-mails enviados; das ligações realizadas; das oportunidades abertas; dos registros de visitas e dos faturamentos. Ainda consta desta lista, a relação de e-mails sensibilizados que foram encaminhados para a pessoa de Telemarketing para ações de Follow-up.

Meta

A meta definida para a Sprint 1 foi baseada na quantidade de Contatos mapeados considerados efetivos (quando há um contato com chances reais de virar uma oportunidade), que no caso foi de 25 Contatos efetivos, no índice de CTR 1 do Google ADwords superior a 1% e no índice de e-mails clicados superior a 15% do total dos e-mails lidos.

1  O CTR é o número de cliques recebidos pelo anúncio dividido pelo número de vezes que ele é exibido.

Conforme o SCRUM há alguns cerimoniais que são utilizados como reuniões de feedback e que suportam o conceito de Inspeção e Adaptação, no caso:  Daily Meetings, Reviews e Retrospectives.

 Sprint 1

Basicamente o conceito de iniciar a Sprint da campanha foi:

– Disparar o Mail Marketing
– Ativar as Campanhas no Google Adwords (Pesquisa Orgânica e Rede de Display)
– Iniciar o trabalho de “cold call”

Há quem pergunte sobre o Sprint Backlog da campanha e a resposta é: “Os itens do Product Backlog estavam tão bem definidos que não tivemos problemas em utilizá-los na integra sem precisar decompô-los, até porque, essa seria uma tarefa bem difícil no nosso caso”.

Daily Meeting e Review

Uma vez que os dados foram gerados diariamente ao longo da Sprint, qualquer pessoa do time podia acompanhar o desempenho dos resultados, e encaramos isso como a nossa Daily Meeting, onde cada membro opinou sobre o andamento da campanha e sugeriu mudanças no decorrer do dia que foram implementadas ao longo da Sprint.

A partir da Daily Meeting muitas mudanças e ajustes foram realizados no Google ADwords.

Veja algumas importantes mudanças que ocorreram durante a Sprint 1:

– Rapidamente identificamos a necessidade de incrementar o valor unitário de cliques para algumas palavras chaves do Google ADwords com maior probabilidade de sucesso e revisão de outras com menos impressões entre outros ajustes em anúncios;

– Foram sugeridas novas possibilidades de mensagens do Mail Marketing e outras estratégias devido a baixa taxa de abertura;

– Foram apresentadas algumas dúvidas levantadas por clientes sobre produtos e soluções que acabaram por demandar um treinamento para a Analista de Telemarketing ministrado junto a nossa Parceira Oracle;

– E por último foi discutido possíveis ajustes no script de Prospecção para melhorar o discurso e a qualidade dos contatos efetivos.

Já a Review tratamos como o encontro realizado ao final da Sprint com o objetivo de apresentar os resultados, então foi apresentado um quadro resumo (com gráficos) com todos os números de desempenho e estatísticas de acesso e cliques realizados ao longo da Sprint.

Retrospective

As retrospectivas são as reuniões destinadas a entendimentos e esclarecimentos a respeito do processo de trabalho de uma Sprint, tendo como base o aprendizado necessário para a promoção das possíveis adaptações para as próximas Sprints.

Em nossa 1ª retrospectiva foram levantados alguns pontos de melhoria descritos baixo:

– Entendimento sobre o conceito de Oportunidade entre Prospecção e Vendas;

– Melhora no formato de apresentação do relatório de oportunidades e do quadro resumo;

– Detalhamento do fluxo de suporte da Oracle com relação às dúvidas técnicas levantadas nas atividades de prospecção;

– Solicitação de suporte do Google para aperfeiçoar algumas configurações do Google Adwords e esclarecer algumas dúvidas;

E tudo isso depois de apenas uma semana de campanha!

As metas foram parcialmente alcançadas:

Contatos Efetivos: 25 realizados
CTR: 0,08
E-mails clicados: 14,29%

Demais Sprints e Campanhas

As demais Sprints seguiram por mais três semanas e contribuíram positivamente para a melhora dos indicadores da campanha, forneceu subsídios valiosos sobre o comportamento dos clientes e reforçou a experiência e confiança do time em busca de resultados mais concretos.

Após duas Campanhas (Logística e Indústria), de acordo com os resultados gerados, conseguimos um aumento de 85% de incremento de novas Oportunidades e demos um importante passo no reforço da nossa marca junto ao mercado, especificamente para os dois segmentos abordados.

E depois…

Atualmente estamos trabalhando em nossa terceira campanha e o que eu posso registrar até o momento é que o SCRUM realmente nos trouxe uma perspectiva diferente de trabalho, totalmente baseada em um maior engajamento e colaboração do time, em prol de resultados mais satisfatórios para todos e para a empresa.

Também não posso deixar de considerar o aprendizado que todos nós tivemos em conjunto, embora não tenha trabalhado em todas as frentes, posso garantir que aprendi muito sobre várias atividades que se delegadas individualmente e gerenciadas de forma centralizada, não estariam tão expostas e suscetíveis as contribuições do grupo.

O efeito alcançado de melhoria contínua também foi notável, principalmente pelos erros e desencontros gerados pelas escolhas mal sucedidas, ou seja, quanto mais cedo você errar, mais perto de acertar nas próximas tentativas você estará, e com essa prática os resultados apareceram em questão de tempo.

Enfim, é preciso separar bem o Método ou Modelo de Trabalho de resultados positivos, é certo que o SCRUM não resolve tudo e nem é garantia de sucesso, porém através desse exercício empírico, se é que eu posso chamar assim, para minha empresa e para o meu grupo de trabalho ele funcionou adequadamente e trouxe resultados satisfatórios.

Agora só resta você testar também e lembre-se que para começar é preciso não se esquecer de Planejar, Fracassar e Iterar!

Boa sorte!

1 Comentário »

Categorias deste post

Agile, Gestão de Produtos, Mudança organizacional, Scrum

Um exemplo prático de SCRUM em uma Campanha de Marketing (Parte I)

Planeje, fracasse, itere…

Desde 2002 atuo na área de negócios com foco em vendas de soluções e serviços para tecnologia e agora nos últimos anos comecei a desbravar a área de marketing, foi então que resolvi colocar em prática algumas experiências adquiridas com o tempo.

Métodos Ágeis tem revolucionado a área de tecnologia, sobretudo área de desenvolvimento de software e mais recentemente a área de gestão.

E é exatamente com o foco mais em gestão do que em tecnologia que escrevo este artigo com o objetivo de apresentar de forma prática e direta o uso de uma Metodologia Ágil aplicada a Área de Marketing, onde a intenção aqui não é explicar o que é o SCRUM e sim demonstrar o seu uso no dia a dia de uma campanha de marketing recentemente lançada pela empresa.

A ideia partiu da necessidade de trabalharmos uma campanha para a venda de licenças Oracle que servisse de modelo para as demais campanhas de marketing da Unidade de Negócios responsável pela venda de produtos e soluções.

O desafio foi imenso, pois não sabíamos por onde começar, então tomamos por base iniciar pelo caminho mais lógico e óbvio, a Visão:

Vision – É melhor começar por aqui!

Antes de tudo, é muito importante sabermos para onde queremos ir ou onde queremos chegar.  Por isso, antes de iniciarmos os trabalhos efetivamente, conversamos com todo o grupo envolvido a respeito dos objetivos da campanha e o resultado dessa conversa foi a descrição abaixo sobre a Visão:

“Reforçar a presença da Unidade de Negócios junto ao mercado e clientes da empresa como fornecedores de soluções Oracle através de quatro campanhas para segmentos diferentes com duração de aproximadamente 1 mês cada uma e consequentemente incrementar em 80% o Pipeline de Oportunidades do time de vendas. “

Pre-game – Antes de iniciar o jogo.

Trabalhar com Métodos Ágeis exige muita disciplina e planejamento ao contrário do que se prega por aí, a diferença é que o planejamento realizado é pragmático e o feedback das ações e acontecimentos são rápidos, diferente da dinâmica utilizada em métodos tradicionais.  Sendo assim, foram definidos previamente a título de Pre-Game algumas premissas importantes e vitais para a campanha:

– Principais Canais a serem utilizados:
– Google Adwords;
– Mail Marketing disparado através de uma ferramenta específica;
– Ligações (Telemarketing Ativo) realizadas por um membro da equipe com experiência neste tipo de abordagem;
– Visitas e atendimento comercial realizado por um Vendedor especializado;

– Os papéis:
– Eu como Scrum Master;
– O Gerente de operações da Unidade de Negócios como o  Product Owner ;
– O time de execução: Vendedor,  Analista de Telemarketing e Analista de Marketing .

– Definição de uma meta por campanha expressa em quantidade de licenças por tipo de produto. Essa meta não é a mesma meta da Sprint sugerida pelo SCRUM que será comentada mais adiante, é apenas uma diretriz e definição de “norte” para a equipe de vendas;

– Como medição dos resultados, decidimos utilizar os Relatórios Gerenciais das ferramentas utilizadas (Google Adwords, Google Analitycs, e-Goi e Sistema de CRM);

– Embora a literatura do SCRUM sugira um tempo de Sprint entre 2 a 4 semanas como ideal, o tempo de duração utilizado nas Sprints foi de 1 semana, pois de acordo com o negócio em questão, foi considerado um tempo suficiente para a percepção das mudanças e geração de resultados.

Product Backlog – É hora de exercitar sua criatividade!

Após a etapa de Pre-game, montamos uma lista de itens com todas as informações que tínhamos disponíveis e que de alguma forma poderiam ajudar a formar a nossa lista final do Product Backlog:

– Informações bem detalhadas sobre os Produtos e Soluções ofertadas
– Cases de Sucesso sobre os segmentos que estávamos abordando
– Uma pesquisa simples sobre os segmentos desejados considerando alguns números de mercado e os principais desafios para Área de Tecnologia para o próximo ano para cada um deles
– Política de descontos dos nossos Distribuidores
– Base de e-mails exportada a partir do CRM

A partir dessas informações “idealizamos” o nosso próprio Product Backlog conforme os seguintes itens:

– Landing Page da campanha
– Banners publicitários
– Anúncios
– Script para Prospecção (Telemarketing Ativo)
– E-mail

A escolha de cada item acima foi decidida com base em “peças” que poderiam ser trabalhadas quanto à forma, estética e conteúdo e que também poderiam ser facilmente estressados ao longo das Sprints, considerando testes e medições. Em outras palavras, o conceito de Inspeção e Adaptação foi levado ao extremo, pois os resultados das medições ficaram disponíveis em tempo real o tempo todo e as alterações e mudanças foram realizadas ora balizadas pelos resultados até então atingidos, ora como testes que se provaram ou foram abandonados nas Sprints futuras.

Na Parte II deste texto você verá o que aconteceu na Sprint 1, não deixe de ler aqui!

2 Comentários »

Categorias deste post

Agile, Gestão de Produtos, Mudança organizacional, Scrum

SAFe – Uma visão inicial de como escalar Agile

Imagine uma pessoa solteira por opção, que acredita que é uma péssima decisão casar e ter filhos. Imagine essa pessoa tentando aconselhar as ações e decisões de um casal com 4 filhos e que está tendo todos aqueles desafios típicos de uma grande família. Nesse cenário é fácil visualizar o solteiro emanando críticas, que no fundo, vão na linha de “vocês estão errados! Vocês deveriam era ter adotado a filosofia de não de ter filhos! É melhor para a sociedade etc.”.

O que você acha de uma abordagem como essa? Você há de concordar comigo que é, no mínimo, nada produtiva uma eventual discussão entre o solteiro e esse casal.  Baseados nessa metáfora, vamos analisar uma situação do mundo corporativo.  Tomando como referência uma empresa grande (casal com vários filhos) e um  time de desenvolvimento de software (solteiro),   seria igualmente pouco produtivo tentar ajudar a empresa grande, apenas com as ferramentas voltadas ao dia-a-dia do time e/ou do desenvolvimento de um produto. O ponto central da incongruência não é que uma empresa é mais importante ou mais complexa que um time, mas sim, os problemas de ser ágil em uma empresa inteira, com vários times, com diferentes partes de produtos, são diferentes (não melhores) de ser ágil em apenas um time autossuficiente.

É com o reconhecimento de que precisamos de uma abordagem apropriada para os desafios de adotar ágil em larga escala, que o SAFe vem ganhando um considerável número de experimentações ao redor do mundo.

Mas afinal, o que é o SAFe?

SAFe é um acrônimo para Scaled Agile Framework. É um modelo criado por Dean Leffingwell e mantido e evoluído pela Scaled Agile Academy . O SAFe é baseado em Scrum, XP (Extreme Programming), Lean e muita experiência de campo,  para a implementação de práticas ágeis em grande escala. Ele reconhece o que tipicamente tem funcionado bem no trabalho de times ágeis, na forma de fazer gestão de programa e na maneira  ágil tratar um portfólio de demandas organizacionais.  O SAFe fornece um conjunto de práticas para ajudar grandes organizações a responderem perguntas do tipo:  Como rodar ágil em contextos envolvendo vários times? Como sincronizar o trabalho desses times? Como coordenar o resultado do trabalho de times distribuídos geograficamente?  Como priorizar demandas em produtos robustos e dinâmicos? Como escalar uma arquitetura ágil? Como tratar, de maneira ágil, os riscos de um projeto complicado? Como ser ágil e estar em conformidade com modelos de governança?

SAFeBigPicture 

Um modelo de transformação respeitando o jeito de ser das empresas

Uma das características mais fortes do SAFe, é que o mesmo reconhece o jeito de ser de uma organização.  Isso dentro de uma empresa de grande porte, significa que o SAFe introduz a filosofia ágil na cultura organizacional e ajuda a empresa a gerar resultados, sem bater de frente com a estrutura e papéis existentes ou até mesmo, com a cola social vigente na organização.  Então, do ponto de vista estratégico, por ser um modelo que respeita o jeito de ser e a cultura das organizações, o SAFe tem ajudado o movimento ágil a chegar em empresas e em esferas que nunca conseguimos chegar antes.

O que difere o SAFe das demais abordagens ágeis. 

Como falei anteriormente, o SAFe bebe da fonte do Scrum, adota o XP com abordagem padrão para o time e, é fortemente inspirado pelo pensamento Lean para uma abordagem mais enxuta do portfólio de produtos. Então muito mais do que diferenças, o SAFe tem coisas complementares à todas essas abordagens.

Mas claro que o SAFe não é apenas um mix dessa práticas/abordagens. O SAFe oferece em encadeamento lógico de como ligar a estratégia da empresa (alto nível) à um ciclo de desenvolvimento realmente ágil (e vice-e-versa). Lembra da diferença entre os problemas e soluções de um casal com filhos para os problemas e soluções de um solteiro? Então, o SAFe obviamente introduz uma série de atividades, regras e papéis diferentes ao da abordagem pura do Scrum ou XP.   Essas peculiaridades, estão distribuídas principalmente nos níveis de Programa e Portfólio.  Por exemplo, se olharmos para maneira como o SAFe faz a gestão de portfólio, veremos que temos papéis mais específicos para o trabalho nesse nível,  então além de um trabalho forte de Program Portfolio Management,  também há o papel de Epic Owners. De uma maneira resumida, entenda que um Epic Owner é o responsável por grandes assuntos de negócio dentro um determinado objetivo de negócio (tema de negócio).

Mas o SAFe tem várias outras peculiaridades,  que em breve, escreverei com mais detalhes.

SAFe e Scrum

Note que na “cebola” do SAFe organizada em Portfolio Level, Program Level e Team Level,  o último nível (Team Level) é baseado em Scrum. No nível de time, ele trabalha com tudo aquilo que estamos acostumados no Scrum, então elementos como auto-organização, empoderamento da micro-gestão e colaboração são partes essenciais para o funcionamento do SAFe. Assim como o Scrum é um framework para a gestão do trabalho de times em ambientes complexos, o SAFe também é um framework para ajudar na gestão  ágil de vários programas organizacionais, de forma a fornecer para a empresa, uma maneira enxuta (maximização de valor e eliminação de desperdício) de gerar resultados em todo o seu portfólio de produtos.

SAFeScrumAndXP

Orientado à produto

O SAFe, ao contrário do que pode se imaginar, eleva ao máximo o conceito de organizar o trabalho por um forte senso de geração de valor. Uma das provas disso, é que dentro do SAFe, a disciplina clássica de gestão  de projetos (aquele conceito com início, meio e fim) praticamente desaparece.  No lugar dessa disciplina, o SAFe introduz fortemente a disciplina de gestão de produtos. Isso representa um salto gigantesco na maturidade com o qual as empresas devem lidar com a gestão de portfólio de seus produtos.   Para o SAFe, a forma de organizar a execução dessas demandas de trabalho sobre os produtos, é através de um conceito chamado ART.

ART – O coração do SAFe.

Na verdade, espero produzir vários e vários pequenos posts explicando os principais detalhes do SAFe, mas no momento, vamos entender o elemento central de todo o funcionamento do SAFe.

Esse elemento, nos termos do SAFe chama-se ART. ART é um acrônimo para Agile Release Train. ART é a forma do SAFe organizar a entrega de um épico de negócio (grande assunto em nível de Portfólio) dentro de um conjunto cadenciado e sincronizado de várias ações envolvendo diferentes times.

Sem entrar (ainda) nos pormenores de como funciona o ART, vamos nos ater na metáfora principal dele: O trem (train, em inglês).

A metáfora vem da ideia de: Um trem parte de uma estação e chega na próxima estação com um confiável agendamento.  Nesse caso, em termos práticos, teremos uma cadência fixa, uma velocidade “normalizada” e releases previsíveis.

Para colocar em prática essa metáfora, é necessário uma abordagem específica para organizar pessoas e processos ao redor da construção do ART.

Pessoas, pois um ART pode ser trabalhado por vários e diferentes times (cada um com sua respectiva Sprint). Então, vamos precisar de novos papéis para suportar a integração técnica e processual desses diferentes times. Essa é missão de um RTE (Release Train Engineer) – Em breve escreverei sobre esse papel também.

Processos, pois para entregar o incremento de produto gerado por um trem, que tem vários times trabalhando nele, será preciso trabalhar com mais de uma Sprint com a mesma cadência de início de fim para todos os times. Além de claro de outros detalhes que em breve escrevei aqui no blog.

Apenas uma coceira no cérebro

Bom, a ideia desse breve texto, foi gerar apenas uma pequena coceira no seu cérebro sobre o SAFe. Por tratar de um assunto crítico para as organizações (Agile em larga escala),  SAFe é um assunto realmente vasto. Portanto, conto com  feedbacks vindos por comentários, e-mails, tweets para me ajudar a compor um norte dos próximos assuntos que escreverei sobre o mesmo.

Também aproveito para convida-lo, a fazer parte do grupo SAFeBrazil (grupo de discussões no facebook – http://www.facebook.com/groups/SAFeBrazil).  Lá poderemos trocar mais figurinhas sobre o assunto e até mesmo esclarecer mais alguns detalhes sobre o SAFe e sobre o assunto Agile em larga escala de maneira geral.

Mais referências:

scaledagileframework.com

1 Comentário »

Categorias deste post

Agile, Mudança organizacional, Portfólio, SAFe, Scrum