“Ágil não tem cronograma!” — Falácia?

Os times que apoio estão no momento de transição entre pensar e fazer projetos tradicionais e fazer projetos e produtos usando frameworks ágeis. Estamos virando a chave de um modelo de planejamento de atividades para um modelo de planejamento de entregas (outputs).

Um grande problema que enfrentamos é a cultura do cronograma, nossas pessoas estão acostumadas a usar o cronograma clássico de gestão de atividades como ferramenta de comunicação de prazos.

Dizer “Ágil não tem cronograma” complica ainda mais a coisa, tento desmontar essa falácia mostrando como podemos fazer planejamento de uma forma diferente e mais aderente ao ágil.

Sei bem que no ágil raiz a gente faz planejamento no nível do produto, planejamento de outcomes, mas ainda não estamos nesse momento por aqui, temos um caminho pela frente. Não dá pra sair de planejamento de atividades pra planejamento de outcomes, sem construir uma cultura pra isso e passar por planejamento de outputs é um caminho.

Venho tentando trabalhar com os times a seguinte linha de pensamento.

1a etapa: precisamos fatiar e classificar

Eu costumo sempre perguntar aos times “O que você vai colocar na mão do usuário pra ele validar? Isso é a sua entrega, isso é o que você vai planejar!” Com a resposta para essa pergunta a gente entende o tamanho dessa entrega ainda sob o prisma do que o usuário vai validar.

Por exemplo, se o usuário vai validar um cadastro de cliente (o famoso CRUD), será que validar todas as operações do CRUD de uma vez só não é muita coisa? Será que a gente não pode entregar para ele validar as operações separadamente? 1o a inclusão, 2o a exclusão, 3o alteração e por fim a consulta? Ou em qualquer outra ordem que faça mais sentido para o usuário.

Depois disso ainda precisamos entender se “Cada entrega dessas cabe em 1 sprint?” Se não couber precisamos quebrar ainda mais, sem perder de vista “o que vamos botar na mão do usuário pra validar”. Não adianta quebrar uma funcionalidade de inclusão de usuário em: 1o vou entregar a tela, depois entrego o banco de dados. O usuário deve validar a entrega como um todo, uma tela de inclusão sem um banco de dados não tem valor nenhum pra ele.

No caso de uma tela de inclusão não caber na sprint, que tal colocarmos menos campos da tela, por exemplo? Uma tela que originalmente tem 20 campos com dados de cliente não poderia ter uma 1a entrega somente com 5 campos principais e nas sprints seguintes a gente iria incrementando com os outros campos? Cada caso é um caso, o importante aqui é pegar a ideia e tentar transpor pra sua realidade. Mas se liguem na cultura do incremental, ela é importante pra te fazer pensar o fatiamento das entregas.

Depois de entendermos como podemos granularizar a entrega, fatalmente vem a pergunta “Mas como vamos dizer ao time o que eles devem fazer” e eu sempre respondo “não vamos!”. O time vai entender a entrega que deve ser feita e como quebramos isso, e se eles quiserem se organizar melhor eles vão quebrar isso em atividades. Mas independente se o time vai quebrar em atividades ou não, os nossos prazos e acompanhamentos sempre serão feito em cima das entregas de valor.

Também ouço perguntas como essa, “Mas o time precisa construir um pipeline de deploy para poder entregar o CRUD, e isso o usuário não vai validar”. O Pipeline é uma entrega técnica, assim como uma refatoração de código ou um débito técnico, por exemplo, e o usuário precisa entender a importância e o valor que isso tem para que a entrega do CRUD como um todo aconteça com qualidade. A missão de convencer o usuário é do time técnico.

No final do fatiamento podemos enquadrar nessa estrutura:

Onde,

• CRUD = Épico
• Inclusão de clientes = História
• Alteração de clientes = História
• Exclusão de clientes = História
• Consulta de clientes = História
• Pipeline de Deploy = Tarefa (entrega técnica)

2a etapa: Agora podemos planejar

Feito o Fatiamento, agora precisamos alinhar e comunicar o planejamento das entregas. Pensem nessa estrutura abaixo:

Uma forma de fazer seria planejarmos de cima pra baixo, a ferramenta de comunicação num nível executivo por exemplo seria o roadmap onde colocaríamos os épicos e o mês/ano em que pretendemos entregar (entregar = código em produção na mão do usuário).

No universo das empresas mais tradicionais, não é o time dev que faz deploy de código em produção (#choqueparaStartups), e nessa situação a gente pode ter que empacotar a entrega de uma ou mais sprints para poder executar o deploy.

Na camada da release e da sprint temos as histórias e tarefas, basta a gente “encaixar” nas sprints as histórias e tarefas de acordo com o planejamento da release. E ao executarmos a planning nós sabemos quais são as histórias e tarefas que entregaremos ao final da sprint, e não é que temos uma data aí? (pq somos um time de alta performance e não quebramos sprints!! heheheh). A ideia é planejar de cima pra baixo (do RoadMap pra Sprint Planning) e comunicar uma data de baixo pra cima (da Sprint Planning pro RoadMap)

E como temos sempre o menor grão da entrega nesse planejamento todo, podemos mexer nele como um jogo de lego. Mexer no roadmap impacta a release plan que por sua vez impacta na sprint planning. E tudo bem a gente “remontar” esse lego sempre que for necessário. Estamos falando de entregas e dependendo do feedback do usuário ou da necessidade do negócio da empresa a priorização das entregas pode e deve mudar, é assim que a gente garante o valor na entrega.

As etapas de Fatiamento (1a etapa) e Planejamento (2a etapa) são constantes e dependendo da maturidade ágil do time elas são executadas em intervalos maiores ou menores.

Essa é uma forma de fazer, existem várias outras mas a essência do pensamento se mantém: comunicamos e planejamos entregas e não tarefas, fatiamos primeiro e só depois planejamos, transparência acima de tudo, deus acima de todos (não, pera!).