Depois de trabalhar algum tempo como gerente de produtos em uma empresa de software e lidar com equipes de desenvolvimento usando uma metodologia tradicional (modelo cascata), eu logo percebi que não era exatamente fã daquele jeito de desenvolver produtos. De certa forma, a essência ágil sempre fez parte de mim, porque eu não costumo planejar tanto para fazer as coisas: planejo o suficiente para começar e depois vou evoluindo e escalando. É minha forma de fazer as coisas andarem.
Ao desenvolver produtos é indicado que adotemos alguma metodologia e, de fato, para alguns cenários e projetos o modelo tradicional cumpre bem seu papel. Já em outros, a grande sacada e solução pode ser partir para uma metodologia ágil.
As metodologias ágeis nasceram a partir do momento em que alguns grandes nomes do desenvolvimento de software se uniram e formaram a chamada Aliança Ágil. Eles assinaram o Manifesto do Desenvolvimento Ágil de Software, na qual foram levantados pontos que deveriam ser valorizados, dentre eles:
- indivíduos e interações MAIS que processos e ferramentas;
- software funcionando MAIS QUE e uma documentação muito abrangente;
- colaboração do cliente MAIS QUE negociação de contratos;
- resposta a modificações MAIS QUE seguir um plano.
A partir dai, surgiram os 12 princípios do manifesto ágil, que direcionaram as metodologias que nasceram a partir dele.
Comecei então a estudar metodologias ágeis, fortemente relacionadas ao universo de software. Fiz um curso sobre Scrum e me certifiquei em um dos papeis, o “product owner”. Acabei me tornando membro da Scrum Alliance e hoje ministro a disciplina de métodos ágeis em uma universidade.
Logo que assumi a gerência de uma equipe de marketing me dei conta de que precisaria de algum modelo ou ferramenta para guiar o trabalho, manter as metas organizadas e encontrar formas de comunicação realmente eficazes entre a equipe. Então eu me lembrei dos princípios ágeis.
Busquei inspirações no Scrum e chegamos a um modelo bacana e que se mostrou bem produtivo, mesmo nosso foco não sendo desenvolvimento de software: aqui desenvolvemos e administramos alguns sites e blogs, materiais ricos e artigos e usamos uma plataforma de automação de marketing. Mesmo não se tratando de software não deixam de ser produtos.
O Scrum na verdade não é bem uma metodologia, mas um framework para desenvolvimento de produtos de forma flexível. E ele não é uma metodologia porque não se trata de um processo prescribente, que lhe diz exatamente como fazer tudo. É na verdade um conjunto de valores, princípios e práticas que fornecem a base para que a organização adicione suas práticas particulares de gestão, de modo que sejam úteis e relevantes para a realidade de cada negócio.
A popularidade do Scrum se deve ao trabalho de Schwaber, cujos métodos foram descritos na obra Agile Software Development with Scrum, de Schwaber e Beddle. Por ser flexível, possibilita a execução de ciclos menores de desenvolvimento de produtos, que permitem o lançamento de versões com mais frequência, de forma que continuamente pode-se entregar valor ao cliente (e o cliente pode ser interno, como o diretor da empresa).
A concepção inicial do Scrum ocorreu na indústria automobilística, como citam Takeuchi e Nonaka em seu artigo “The New New Product Development Game”, publicado no Harvard Business Review (1986), que logo foi adaptado às várias áreas diferentes da produção de software.
Normalmente, o Scrum é usado para trabalhos complexos nos quais é impossível predizer tudo o que irá ocorrer e ressalta o uso de um conjunto de padrões de processos, principalmente para projetos cujos prazos são curtos ou baseados em requisitos passíveis de mudanças. Bem parecido com a realidade de uma equipe de marketing focada em produção de conteúdo e administração de blogs corporativos: demandas surgindo o tempo todo e prioridades mudando com frequência.
Os papéis do time são bem definidos e ele é estruturado e autorizado a organizar e gerenciar seu próprio trabalho. Entende-se que cada profissional da equipe tem conhecimento e experiência para sugerir a melhor forma de se desenvolver algo, bem o oposto do que aconteceria em uma metodologia tradicional, pautada na figura de um gerente de projetos que define sozinho como será cada detalhe.
No caso do software, o ciclo de desenvolvimento é baseado nas chamadas sprints, que possuem um tempo definido, geralmente de 30 dias, cuja meta é alcançar objetivos estabelecidos que estão representados no chamado product backlog, uma lista contendo tudo o que se deseja desenvolver e que conforme os ciclos de desenvolvimento forem executados, terá seus itens priorizados e repriorizados.
Nos inspiramos nessa dinâmica e começamos a usar o ágil na equipe de marketing. Usamos a ferramenta Trello para organizar as atividades e as pessoas que se envolveriam nelas, um quadro visual e dinâmico para entendermos o que precisa ser feito, prioridades, andamento, impedimentos, que também permite anexar documentos, referências, sites, comentários e etiquetas coloridas (para sinalizar o status de cada atividade).
Combinamos rápidas e frequentes reuniões de alinhamento, na qual cada um comenta no que está trabalhando naquele dia e possíveis impedimentos ou dúvidas. A comunicação se tornou ainda mais clara e frequente e a equipe ganhou autonomia, pois sabe claramente quais são suas metas e a prioridade das atividades.
Como sentamos um ao lado do outro, a comunicação ficou ainda mais frequente. Diariamente fazemos reuniões de alinhamento e nenhum impedimento é passado para frente, assim que ele aparece nos falamos e resolvemos o quanto antes, assim como no Scrum. Periodicamente fazemos reuniões um pouquinho mais demoradas, nas quais são planejadas as atividades priorizadas e cada um contribui com sua visão e experiência: o resultado é sempre um blog, um artigo, um infoproduto, uma arte muito mais criativas e interessantes por causa da colaboração da equipe.
Todos nós temos acesso ao quadro de atividades, que está constantemente priorizado e com informação suficiente para orientar o trabalho de cada um. Mas a melhor forma de fazê-lo eu deixo para cada especialista e o resultado tem sido incrível.
Para nós não é importante afirmar que “usamos Scrum ou não”. Não nos importa o termo, afinal, ele foi adaptado para nossa realidade e talvez não seja mais explicitamente Scrum, mas o importante é que funciona.
Acredito que esse modelo deu certo para nossa realidade porque eu sempre tive horror de bancar a geretona que faz microgerenciamento. Aqui somos uma equipe de verdade e eu também coloco a mão na massa.
Métodos ágeis estão alta, presentes em centenas de empresas por todo o mundo e agora estão sendo adaptados como estratégia fora do universo de desenvolvimento de software. Fique de olho nesta tendência!
