O mínimo de agilidade que você pode aplicar em qualquer projeto

Eu aprendi métodos ágeis pela primeira vez em 2010, começando com Scrum. De lá pra cá eu não parei mais. Tive a oportunidade de aplicar do zero em diversas startups e empresas como RedeHost, Busca Acelerada, Opideia, Route, Agibank, Banco Topázio e Linx.

Em algumas delas, consegui grandes transformações, como no caso do Agibank e RedeHost. Em outras, transformei apenas alguns times, como no Route e no Banco Topázio. Mas em todas, sem exceção, eu comecei com um mínimo, básico e essencial, que eu arrisco a chamar de “universal”.

Este artigo vem muito inspirado pela minha última experiência, onde fui chamado para liderar um projeto milionário que tinha iniciado em 2018 e estava com um atraso enorme na entrega, com o perigo de perdermos o cliente. Consegui ajudar o time a dar a volta por cima com um mínimo de agilidade, em pouco mais de um mês. É esse mínimo de agilidade que eu acho que você pode aplicar em qualquer projeto, empresa ou equipe que eu quero compartilhar hoje.

#1 – Transparência

Em quase todas aquelas referências que citei no início desse artigo, eu entrei no meio de um projeto, sem saber nada do que estava acontecendo. E achava que era o único nessa situação, mas não era. Salvo algumas poucas pessoas que tinham tudo na sua cabeça, poucas pessoas do time realmente sabiam o que precisava ser feito. O primeiro passo foi nivelar o entendimento de todo mundo.

Transparência é o primeiro pilar do Scrum, um dos princípios do Manifesto Ágil e parte do que eu chamo a Essência da Agilidade. John Maxwell chama isso de Lei do Placar, pois todo time tem de conhecer os aspectos significativos do projeto para poder trabalhar de forma eficaz, rumo ao mesmo objetivo.

Como fiz isso? Tirei tudo o que precisava ser feito da cabeça, emails, planilhas, arquivos de texto, etc e coloquei em um único lugar, visível a todos. Você pode chamar isso de Backlog se quiser, mas era “apenas” uma planilha no Excel com código, nome, descrição, responsável, status e prioridade.

Dá pra fazer com Jira Software, com Azure DevOps, com Trello, com Project…pra mim, o mínimo é com Excel mesmo. E funciona muito bem para começar com gestão de backlog sem ter de ensinar o pessoal a usar uma ferramenta bem mais complexa. Como a empresa usa a suíte do Office 365, todos tínhamos Excel e o compartilhamento da planilha era pelo OneDrive.

#2 – Inspeção

Inspeção é o segundo pilar do Scrum e ele depende da Transparência para poder ser aplicado na prática. Você tem de poder ver o terreno antes de poder inspecioná-lo.

Sabendo tudo que tínhamos de fazer, qual a prioridade e quem estava fazendo o quê, estávamos aptos a inspecionar esse projeto diariamente, através de reuniões diárias. Analisávamos coisas como:

algum item prioritário não estava evoluindo? Estava sem “dono”? Estava impedido de avançar?
qual item poderia nos “matar” essa semana se a gente não entregasse?
qual item não estava claro o bastante para poder ser executado?
qual item podíamos renegociar para entregar depois?
ainda estávamos aptos a entregar no prazo? Quais os ofensores para nosso plano?

Você pode chamar isso de Planning, mas era diário. Você pode chamar de Daily, mas levava de 30 a 60 minutos. Eu chamava apenas de alinhamento diário e isso era o bastante para todos. Era completamente focada no nosso backlog, a planilha de Excel que falei anteriormente. A call era feita pelo Teams da Microsoft (a empresa tem o Office 365) e usávamos muito o recurso de compartilhar a tela para todos vermos o mesmo backlog enquanto discutíamos.

#3 – Adaptação

Adaptação é o terceiro pilar do Scrum e ela vem depois da Inspeção. Baseado no retorno da inspeção, podemos nos adaptar à nova situação, tomar novas decisões e melhorar como o time está jogando.

Muitas vezes, depois do alinhamento diário, tínhamos outras discussões, em grupos menores e mais focados, em um ou outro aspecto do projeto ou item específico do backlog. Algumas adaptações que fazíamos frequentemente:

um item que podia nos “matar” essa semana, tinha de ter uma atenção especial. Podemos colocar mais alguém a trabalhar nele? Podemos simplificá-lo (um MVP de repente)?
um item que estava impedido, tinha de ter seu impedimento entendido e resolvido imediatamente. Não tínhamos Scrum Master, então distribuíamos impedimento entre algumas lideranças do projeto (o gestor, o líder técnico, etc).
um item não estava claro? Seja por questões técnicas ou de negócio, imediatamente buscávamos alguém na empresa (ou no cliente) que pudesse ajudar a clarear as coisas.

Note que, para que a adaptação ocorra, precisávamos de ação concreta e imediata. Não tínhamos tempo a perder, tínhamos de resolver os problemas do projeto na raiz e o mais rápido possível. Não queríamos culpados, desculpas, etc; focávamos sempre na solução. Esse era um dos meus principais papéis nesse projeto, o de líder-servidor.

#4 – Comunicação

Note que em diversos momentos eu falei de comunicação de forma implícita e a própria transparência depende muito de comunicação, seja a escrita, mas principalmente da oral. Nada supera uma conversa direta e por voz e, mesmo em tempos de pandemia (como a que vivemos na época deste artigo), devemos garantir que as pessoas se conversam, e muito, ao longo de todo o projeto.

Além de todas as ações internas de comunicação do próprio time, que citei nos itens anteriores, aqui quero focar na comunicação do projeto para os demais stakeholders. Todos sabemos que quando um projeto vai mal, fazer gestão de projetos é uma tarefa muito ingrata e o lema “não atire no mensageiro” é muito importante aqui.

TODOS os stakeholders, sem exceção, precisavam ser comunicados, tanto do lado da nossa empresa quanto do lado do cliente. E sim, o projeto ia bem mal, lembra? O famoso farol vermelho…

As lideranças imediatas do projeto se comunicavam todos os dias, sem exceção, em reuniões rápidas de até meia hora. Discutíamos a estratégia, como o time estava evoluindo, escalávamos impedimentos e olhávamos mais à frente, nas próximas entregas, enquanto que o time mantinha-se focado na entrega atual. Saíamos dali sempre com tarefas para cada uma das lideranças.

A camada executiva era comunicada quase diariamente, de maneira pontual, através de uma das lideranças (a de produto, um PO Proxy, já que o cliente não podia estar sempre presente) e semanalmente de maneira oficial, onde apresentávamos o roadmap, status, ofensores e tínhamos sempre de ouvir a mesma história que o projeto começou em 2018, estava atrasado, tínhamos gasto mais de milhão e etc.

Sendo bem sincero, não ter de ouvir mais aquela história já era uma boa motivação para eu querer o sucesso do projeto, haha.

Já o cliente era acionado TODAS as vezes que tínhamos dúvidas, seja através do líder de produto (pode chamar de PO, mas não tínhamos esse rótulo e ele não tinha todas as atribuições de um PO, no máximo um PO Proxy) e quinzenalmente fazíamos as entregas ao vivo para o cliente, via web conference (estávamos todos em quarentena). Pode chamar de Review, mas chamávamos apenas de homologação.

Nesta homologação, recebíamos feedback da entrega que retroalimentavam o nosso backlog e aperfeiçoava nosso entendimento do projeto, do cliente e da nossa própria forma de trabalhar.

Na data que escrevo este artigo, faz pouco mais de dois meses que começamos este trabalho e o produto já está na rua, em piloto, em cerca de 20 clientes do nosso cliente e transacionando quase 200 mil reais desde o lançamento (é um produto financeiro). Este projeto irá ajudar a empresa não apenas a faturar mais nessa época de pandemia, como a mostrar que é possível mudar a forma de trabalhar mesmo durante um projeto em crise.

Adicionalmente, o vídeo abaixo traz mais alguns insights “universais” em termos de agilidade para qualquer projeto: