Ágil além do software: 10 práticas para qualquer time – Parte 1

O Movimento Ágil não para de crescer. Em 2017, a Forbes entrevistou 500 executivos e 92% afirmaram que pensam que agilidade organizacional é crítica para o sucesso do negócio. Desde o nascimento do Manifesto em 2001, o interesse em agilidade de forma mais ampla tem despertado alguns questionamentos. Será que as práticas ágeis são aplicáveis em times fora do desenvolvimento de software? RH? Finanças? Marketing?

A comunidade Modern Agile propôs uma nova versão do manifesto, que acredito fazer mais sentido para contextos além do desenvolvimento de produtos digitais.

Olhando de perto, vejo que o Modern Agile é mais  uma evidência que os valores ágeis, como experimentação, segurança emocional, entrega de valor e foco nas pessoas são universais.

Ainda assim, a dúvida que fica não são os valores, mas sim as práticas. Ao tentar aplicar um framework como Scrum ou o método Kanban, muitos entusiastas desanimam, porque os métodos na sua totalidade podem ser difíceis de adotar em trabalhos que não envolvam o desenvolvimento de algum produto ou prestação de um serviço. Mas se selecionarmos algumas práticas comuns em times ágeis, veremos que elas podem ser úteis em contextos diversos e para qualquer time. É o que exploraremos neste texto.

Vale ressaltar que as práticas que apresentaremos pressupõem um “time”, ou um trabalho cuja natureza demande uma certa interdependência entre pessoas. Se não há necessidade de trocas e colaboração entre os indivíduos para entregar valor, o Ágil simplesmente perde sua mágica, não importando se é para desenvolvimento de software ou não.

Nesta primeira parte do texto abordaremos 2 práticas: Sprinting, Backlog Coletivo e Gestão à Vista. Vamos a elas!

1. Sprinting: foco na geração de valor rápida

A gestão de projetos tradicional apoiou-se no Triângulo de Ferro, um sistema de tripla restrição que diz que qualquer iniciativa possui três necessidades conflitantes: custo, tempo e escopo. O Ágil nos ensinou que somos incapazes de planejar projetos acertando as 3 dimensões. Alguma delas vai sofrer com nossa incapacidade de prever o futuro. Em geral, a alavanca mais saudável no triângulo é o escopo, por 3 motivos:

1. Geralmente não alteramos a equipe durante um projeto, então custo não é uma possibilidade. Adicionar ou remover pessoas a um time durante um projeto também costuma causar problemas (a lei de Brooks).
2. Precisamos entregar valor rapidamente, pois o desafio está em entender as necessidades do cliente e acertar aquilo que ele precisa, então o tempo geralmente também é fixo.
3. Por fim, no trabalho moderno sempre temos mais demanda do que capacidade de entrega, portanto é impossível entregar tudo que o cliente pede.

Dividir o trabalho em “Sprints”, ou fazer “Sprinting” foi uma sacada do framework Scrum. Uma Sprint é um bloco de tempo fixo, normalmente algo entre 1 e 4 semanas, onde um time colabora para entregar o máximo de valor possível para o cliente final naquele período. O fato de haver uma restrição de tempo – o tamanho da Sprint – induz o time a pensar em soluções criativas para entregar valor rápido. Aqui o perfeito é inimigo do bom.

Vamos a um exemplo para ficar mais tangível!

Exemplo de RH

Imagine que você faz parte de um time de RH de 3 pessoas que está com a missão de criar um novo programa de desenvolvimento para uma organização. Este programa inclui um novo sistema de remuneração, dar clareza para oportunidades de desenvolvimento e criar uma experiência fantástica para o funcionário. Olhando assim, parece uma missão épica! E é mesmo. Você precisa fatiar esta história (um termo que utilizamos no Ágil) em coisas menores.

O primeiro passo talvez seja entender quem é o seu cliente. Neste caso, podemos considerar a organização inteira o cliente. Os usuários, no entanto, são os funcionários.

O próximo é refletir: o que é valor para o seu cliente/usuário? Talvez já exista uma pesquisa de clima que dê clareza que o tema promoção é crítico. O time de RH pode então fazer uma investigação mais a fundo e entender que na realidade o que as pessoas querem dizer com ser promovido está mais conectado com ter mais oportunidades de aprendizado. Esse já parece um problema um pouco mais fácil de resolver, certo?

Agora imagine que você está fazendo Sprints de 2 semanas, sendo que só metade do tempo das pessoas é dedicado a isso (elas possuem outras atividades). Então você tem 1 semana de trabalho de um time de 3 pessoas para entregar alguma coisa de valor. O que pode ser entregue nesse período? Depois de um pouco de brainstorming e discussões, o grupo chega na conclusão de que nessa primeira Sprint é possível entregar um quadro onde as pessoas declaram 1) que coisas podem aprender e 2) que coisas podem ensinar. Um barbante é usado para conectar as duas colunas e o RH passaria a promover encontros entre essas pessoas para que elas possam ajudar-se mutuamente.

Isso resolveu o problema? Provavelmente não na sua totalidade. Mas ao menos algum valor foi entregue ao cliente e usuário final. Na próxima Sprint talvez o quadro ganhe uma versão digital, para que quem está fora do escritório possa utilizá-lo. Se sistematicamente a cada 2 semanas o time entregar algo funcional, imagine o que pode acontecer em 1 ano!?

A prática de fazer Sprinting combate a nossa tendência natural de planejar mais do que deveríamos, a Lei de Parkinson e a Síndrome do Estudante.

2. Backlog Coletivo: compartilhando as demandas de valor

Muitos grupos se chamam de times, mas poucos aproveitam as oportunidades de colaboração e sinergias entre os integrantes. Um sintoma comum desta falta de coordenação são listas de trabalho individuais. Ao invés de tratar as demandas do grupo como um Backlog compartilhado, cada um possui o seu repositório de trabalho individual.

Uma das abordagens não exclui a outra, claro. É valioso ter a sua própria lista de atividades para se organizar. Mas é também importante que um time compartilhe critérios de priorização, para que haja mais foco.

Tanto o Scrum quanto o Kanban nos convidam a olhar para o serviço ou produto sendo desenvolvido com as lentes de uma priorização do todo, e não do trabalho individual. No Scrum existem dois Backlogs, o da Sprint e o do Produto. No Kanban Maturity Model, a partir do estágio 2 de maturidade já temos critérios de priorização para o fluxo ao invés de listas individuais.

É importante adicionar que criar um Backlog compartilhado não é só fazer um agregado de listas de tarefas individuais. Um Backlog geralmente possui itens que geram algum tipo de valor para o usuário ou cliente do produto/serviço. Dentro de cada item de Backlog podem existir diversas tarefas ou ações que precisam ser completadas.

Exemplos de Marketing

Para o Backlog Compartilhado, vamos imaginar que fazemos parte de um time de Marketing de uma organização que vende cursos e treinamentos. Nesta empresa, a aquisição acontece no momento em que um usuário compra um curso no nosso site. O objetivo deste time é criar campanhas e comunicações que ajudem nossos consultores e treinadores a venderem mais cursos. O nosso grupo tem especialistas em mídias sociais, e-mail marketing, adwords, otimização de motores de busca (SEO) e em produção de conteúdo para o nosso blog.

Antes da implementação do Backlog Compartilhado, cada especialista tinha a sua lista de tarefas individual. Muitas vezes a pessoa que trabalhava em SEO nem sabia que tipos de campanhas de e-mail marketing estavam sendo feitas. Thomas, responsável pelas comunicações via Facebook simplesmente executava pedidos feitos por outras áreas. A sensação geral do grupo era de trabalhar em uma pizzaria, onde pedidos eram feitos e o processo executado, sem qualquer reflexão ou questionamento da parte deles.

Foi aí que eles resolveram colocar todas as demandas em um quadro no Trello, criando um Backlog Compartilhado. A visibilidade do processo já jogou na cara deles que o volume de coisas em andamento era absurdo. Além disso, eles perceberam que as ações não estavam sincronizadas. Por exemplo, se Juliana do e-mail marketing soubesse do que estava por vir em termos de conteúdo para o blog, ela poderia criar campanhas que aproveitassem esses recursos.

Parece um exemplo exagerado quando pensamos que cada uma das 4 especialidades listadas é representada por uma pessoa. Mas e se ao invés disso considerarmos que cada uma delas pode ser outro time com 10 integrantes? A chance de assimetria da informação aumenta muito.

Além de colocar as demandas em um único lugar, o time de Marketing começou a escrevê-las na forma de histórias do usuário, para centrar os trabalhos na perspectiva de quem precisa das comunicações. Assim, toda vez que alguém encomendava uma “pizza”, eles questionavam. Por exemplo:

Jonas, da área de produto, chega para o time e pede: “Eu quero uma campanha no Instagram com um vídeo sobre a importância de ter um design organizacional mais fluido”. O time pergunta:

1. Qual o seu objetivo com isso?
2. Como você pretende impactar o nosso usuário com essa campanha?
3. Que ação você gostaria que ele executasse a partir dessa campanha?

Após os questionamentos, o grupo conclui que o que Jonas gostaria na realidade é que os usuários comprassem mais o curso de design organizacional e que hoje parece que a oferta de valor está confusa. Depois das reflexões, eles descrevem a seguinte história de usuário:

Enquanto consultor*, eu gostaria de vender cursos de design organizacional com uma oferta de valor mais clara.

*Estamos considerando o usuário final desta história (e do time de Marketing) a própria organização, ou mais especificamente, o consultor que quer vender o curso de design organizacional.

Essa compõe a primeira e mais prioritária história do Backlog Compartilhado do time de Marketing. Agora eles podem criar uma campanha de comunicação mais assertiva e centrada nas necessidades do cliente final. Isso sim é ser ágil!

Vantagens do Backlog Compartilhado

Listamos abaixo algumas vantagens da prática de “Backlog Compartilhado”:

1. Foco: Com todas as demandas de um grupo na mesma lista, fica mais fácil encontrar sinergias entre as diferentes especialidades do time. Como exemplificamos com a história sobre a empresa que vende cursos, se todas as especialidades de Marketing se concentrarem em criar campanhas que busquem resolver o mesmo problema, o impacto será muito maior.
2. Formato de valor: Ao escrever os itens do Backlog em formato de valor (histórias de usuário), convidamos todos a refletir sobre que tipo de problema buscamos resolver, ao invés de só executar pedidos de outros departamentos.
3. Reduzir dependência de especialistas: Não capturamos esta vantagem no exemplo, mas a redução da dependência de especialistas é reduzida com um Backlog único. No ágil estimulamos que as pessoas saiam um pouco da sua zona de especialização (por exemplo, SEO) e contribuam com aquilo que é mais prioritário, às vezes executando aquilo que não é o seu forte. Com o tempo todos aprendem um pouco de tudo e conseguimos reduzir gargalos quando o violinista sai de férias.

3. Gestão à vista: enxergando para melhorar

Após a segunda guerra mundial, o Japão teve que reinventar sua produção de veículos em massa para concorrer com o mercado americano. O Sistema Toyota de Produção [1] revolucionou o mercado, instalando a produção puxada (ao invés de empurrada) que permitia redução do estoque e minimização do desperdício. Isso deu início ao pensamento lean, que mais tarde influenciou fortemente o Movimento Ágil.

Um dos principais conceitos do Sistema Toyota é a gestão à vista, ou a prática de criar representações visuais e acessíveis sobre o processo produtivo. No desenvolvimento de software, tanto o framework Scrum como o método Kanban fazem forte uso das técnicas de visualização. Não é a toa que times ágeis são geralmente associados ao uso de notas adesivas (para não dizer que ganhamos comissão da 3M) e quadros na parede.

Muitos aspectos do trabalho do conhecimento são invisíveis. Por exemplo, ao contrário de um processo de produção de um carro, quando acumulamos estoque, não conseguimos enxergar. Pela perspectiva lean, toda vez que colocamos energia em algo e não finalizamos, estamos desperdiçando. E todos aqueles relatórios que você fez e nunca foram usados? E toda documentação escrita que nunca foi lida? E aqueles powerpoints que você começou, mas não terminou? Dinheiro investido (seu tempo e salário) que não gerou nenhum retorno. Desperdício.

Além da possibilidade de mensurar e melhorar o processo, a gestão à vista também nos permite usar da pressão dos pares para que um grupo mantenha-se atento aos seus objetivos. Por exemplo, quando criamos um quadro de tarefas, com visibilidade do que cada um está fazendo, estamos colocando em evidência quando alguém não está fazendo nada. E ninguém quer ser visto não fazendo nada no ambiente de trabalho.

Existem inúmeras formas de tornar a gestão mais visual. Quadros de tarefas, Backlogs e listas de impedimentos (coisas que estão atrapalhando um time) estão entre os artefatos que mais damos visibilidade em times ágeis.

Exemplo de Finanças

Imagine que fazemos parte de uma área de finanças, responsável pela parte administrativa, financeira e jurídica de uma organização. Para nós, é muito importante que alguns procedimentos sejam seguidos e cumpridos semanalmente, como o pagamento de fornecedores e de funcionários. Para resolver esta questão, criamos um checklist semanal e mensal, com as atividades recorrentes mais importantes:

1. Pagou os fornecedores? (semanal)
2. Atualizou os modelos financeiros? (semanal)
3. Processou a folha de pagamento? (mensal)
4. Verificou se existem novas ações judiciais? (mensal)

Este é um exemplo simplório. Em geral, times que trabalham com finanças têm dezenas de checklists ou procedimentos que precisam ser repetidos. Agora imagine que o nosso time resolveu montar um grande quadro com todos esses checklists para cada semana. Também combinamos de nos reunirmos diariamente em frente a esse quadro e atualizar o checklist.

Apesar de simples, este processo nos permite visualizar rapidamente quando algo está saindo do trilhos. Se a folha de pagamentos pode atrasar, Sirlei pode sinalizar esse problema e pedir ajuda para Kim, da área jurídica. Note que isto só é possível quando criamos 1) uma forma de visualizar o trabalho e como ele está indo e 2) um ritual de verificação do andamento do curso.

A gestão à vista pode ser aplicada em quaisquer artefatos que o seu time possuir. O importante é dar visibilidade àqueles que vão permitir que o time tome alguma ação.

Próximo Capítulo

Hoje abordamos 3 práticas ágeis para qualquer time: Sprinting, Backlog Compartilhado e Gestão à Vista. Mostramos exemplos de áreas de RH, Marketing e Finanças. Já está convencido de que o ágil não é só para software? Espere só a parte 2, que traremos mais 3 práticas.

Referências

[1] Sistema Toyota de Produção. Disponível em: <https://administradores.com.br/artigos/sistema-toyota-de-producao>.

[2] Citação do Peter Drucker. Disponível em: <https://guavabox.com/if-you-cant-measure-it-you-cant-improve-it/>.