Sabe aquele papo que alguns ouvem e repete de que “no Lean-Ágil a gente não planeja”? A ignorância voluntária é uma escolha para muitas empresas e equipes, mas no final das contas, ela custa caro para todos. O problema não é ter um plano, mas como ele é usado, de formai inteligente ou burra. É como no ditado “don’t throw the baby out with the bathwater” (“não jogue o bebê fora junto com a água suja”) – na pressa ou desejo de eliminar algo ruim (a água suja), acabem jogando fora também o que há de bom (o bebê, que precisa ser limpo).
Ter um plano de entregas (release plan) NÃO é ressuscitar um cronograma engessado, nem é sinonimo de microgerenciamento ou resgate do triangulo de ferro original, onde sucesso é entregar o que foi planejado no escopo, tempo e custo previstos. Não podemos pensar em plano de entrega como um pacote único, indivisível, com cultura e processos do século passado, não está relacionado nem a waterfall, menos ainda a comando-controle. Se isso acontece, a culpa não é do Release Plan, o seu problema é maior que isso.
Em uma auto-estradas, é ter um mapa e GPS para a viagem, isso não impede de mudar a velocidade ou rota, mas resignifica estas decisões. Pense em um Rally, com mapa, regras e desafio (objetivos), sobre o qual o piloto e co-piloto (time) se organizam (Release Plan), juntos analisam min-a-min (fluxo, daily, kanban), não só para chegar ao fim, mas passar em cada ponto de controle (dailys, iterações e reviews), refinando seu plano e execução à cada nova realidade.
O Manifesto Ágil possui quatro valores, que NUNCA, JAMAIS, DE NENHUMA FORMA podem ser vistos como opções polarizadas. A proposta NÃO era investir em [pessoas, entregas, cliente e mudanças] em detrimento de [processos, documentação, contratos e planos]. A proposta era resignificar e balancear, valorizando mais, sem perder o equilíbrio mínimo necessário. Lê-los de forma simplista gera falsos silogismos, argumentos e processos que serão questionados em um futuro muito breve. Temos vários conceitos que evitam eventuais falácias:
Estratégia e Business readiness – Stakeholders e negócio precisam de um mínimo de previsibilidade para gerenciar seus roadmaps e portfólios, priorizar e gerenciar programas, projetos ou operações, liberar orçamentos e tudo mais em “business readiness” (processo de verificação estruturado que garante que uma organização, envolvidos, processos, dados e tecnologia sejam conhecidos e planejados frente a estratégia, planos e mudanças significativas).
Visão sistêmica e Value Driven Design – Apesar de propostas como Dual Track de Jeff Paton, Triple Track de Paulo Caroli ou Flight Levels do David Anderson, sempre há o risco de que o fluxo de iterações foquem excessivamente no curto prazo. Sem um plano de entregas, o time pode perder a visão do todo e focar em tarefas. O plano ajuda a equipe a entender a arquitetura do produto vinculada aos benefícios que precisam ser gerados ao longo do tempo.
Gestão de Dependências e Riscos – Projetos e operações muitas vezes possuem dependencias e riscos, que podem ser tecnológicos, intra ou intertimes, envolver parceiros e fornecedores, exigir aprovações de outras áreas, como jurídica ou compliance. Visualizar as entregas futuras permite antecipar gargalos e coordenar os esforços antes que eles interrompam o ritmo da equipe. Um plano também antecipa a visão e gerenciamento de riscos relacionados a dependências.
Planejamento em Ondas Sucessivas (Rolling Wave Planning) – Não é planejar apenas uma onda! Consiste em planejar o trabalho imediato em detalhes e o trabalho futuro em linhas mais gerais. O Conceito aplicado justifica a coexistência da Sprint (onda detalhada e de curto prazo) com o Plano de Entregas (onda de médio/longo prazo, descrita em níveis de macrofuncionalidades ou epicos).
Pensamento Lean (Lean Thinking e Lean Startup) – Originado no Sistema Toyota de Produção, o Lean foca na eliminação de desperdícios e na maximização antecipada do valor para o cliente. O plano de entregas funciona como o mapeamento do fluxo de valor (Value Stream Mapping) do produto. Sem ele, há o risco de priorizar o desperdício, algo que o cliente não precisa agora ou, se pudesse, teria planejado de outra forma.
Refinamento Sucessivo (Hierarchical Breakdown) e Opções Reais (Real Options Theory) – Esta teoria econômica estipula que você deve planejar, mas adiar decisões irreversíveis até o último momento responsável. Um plano de entregas é importante, mas não deve ser rígido e detalhado, mas um portfólio de opções. Ele permite que você declare a intenção de entrega de valor, com flexibilidade para mudar conforme o cenário do mercado ou aprendizados evoluem.
Cone das incertezas ou Compromisso Progressivo (Cone of Uncertainty) – Criado na engenharia de software por Steve McConnell, demonstra que no início de um projeto a incerteza é alta e vai diminuindo à medida que avança os aprendizados. Corrobora a ideia de que o plano de entregas não deve ser estático. O cone mostra que a incerteza inicial vai se refinando, ficando mais estreito e preciso a cada iteração.
Sistemas Complexos e Cynefin Framework – Desenvolvido por Dave Snowden, ajuda a classificar contextos de problemas em: Simples, Complicados, Complexos e Caóticos. O desenvolvimento de software ágil quase sempre é Complexo (Sondar-Sentir-Responder). O plano atua como uma hipótese inicial (a “sonda”), dá uma direção para o sistema se mover, permitindo que o trabalho, entregas e feedbacks retroalimentem e melhorem o plano.
