Planejamento Ágil: O Melhor de Dois Mundos
Agile 101
Visão Geral do Planejamento Ágil
Planejamento Ágil (Agile). Soa como um paradoxo, não soa? Planejamento envolve estabelecer limites, criar listas de verificação, determinar datas de entrega e seguir um processo passo a passo, não é mesmo?
Mas Agile, não se trata de pessoas fazendo suas próprias coisas? Muitas pessoas pensam no planejamento tradicional como o equivalente musical de uma orquestra clássica disciplinada e no Planejamento Ágil como o caos de forma livre do jazz.
Nada poderia estar mais longe da verdade.
Este artigo explicará por que o pensamento e o planejamento Ágil não são exclusivos e podem trabalhar juntos de forma poderosa para o seu negócio.
Breve Visão Geral
O Planejamento Ágil é uma forma de planejar o desenvolvimento de produtos em um ambiente Agile desde as metas e objetivos do negócio até a execução diária em equipes de desenvolvimento.
O desenvolvimento de produtos, especialmente o desenvolvimento de software, é dinâmico. Os requisitos do usuário e do cliente mudam. Devido às mudanças em seu ambiente e porque a utilização de um produto à medida que ele evolui aciona ideias de uma maneira que nenhum documento de especificação jamais poderia.
Aceitar mudanças frequentes então e planejar de acordo, é fundamental.
Assim como o Desenvolvimento Ágil de Software, o Planejamento Ágil é iterativo, tornando-o inerentemente adaptável à mudança. Isto permite que você concentre sua atenção nas necessidades dos usuários e clientes em todos os níveis de seu negócio.
Isso também significa que o plano em si não é tão importante assim. O verdadeiro valor do Planejamento Ágil está no pensamento necessário para criar o plano e como ele conecta o trabalho em todos os níveis às metas e objetivos orientados ao cliente da empresa.
Breve História
O desenvolvimento de software teve uma má reputação nas décadas de 80 e 90 do século passado. Os projetos ultrapassavam seus cronogramas e seus orçamentos.
Descobriu-se que desenvolver qualquer software é um esforço complexo em um ambiente muitas vezes complexo e mutável. Algo que simplesmente não se pode controlar com os métodos de planejamento obtidos através de projetos de construção.
A abordagem cascata simplesmente não serve quando se trata de responder às mudanças no ambiente e nas necessidades de seus clientes.
O desenvolvimento ágil de software evoluiu devido a isso. Entretanto, muitas empresas ainda usavam o método tradicional de planejamento de trabalho para prever seus custos e definir orçamentos.
O Desenvolvimento Ágil de Software elimina a interrupção do trabalho, pelo menos até o último momento. Alguns proponentes ágeis até mesmo defendiam a recusa de apresentar estimativas de tempo e recursos. Afinal, de que serve planejar desta forma quando você sabe que as coisas mudam e qualquer plano é provavelmente impreciso no momento em que é criado.
Entretanto, a necessidade de controlar custos e estabelecer orçamentos não desapareceu, mesmo quando os benefícios da agilidade na entrega de software que funciona e atende às necessidades dos clientes eram óbvios.
Algo tinha que mudar, e o Planejamento Ágil foi a resposta dando aos gerentes e executivos uma forma de estimar custos e estabelecer orçamentos sem exigir que o departamento de desenvolvimento voltasse às tentativas de prever o futuro.
Como funciona?
A ideia chave para o Planejamento Ágil é vincular tudo o que é feito no desenvolvimento de volta às estratégias e objetivos do negócio.
Isto significa que o planejamento começa no topo — o nível de direção e gerência sênior — e se torna progressivamente mais detalhado no caminho para o nível das equipes que executam o trabalho.
Uma bela metáfora para este processo de planejamento é a Cebola do Planejamento Ágil.
Cebola do Planejamento Ágil
É como um lembrete visual do espectro que o Planejamento Ágil tem que cobrir em toda uma empresa.
-
O nível estratégico analisa para onde o negócio quer ir no futuro, suas metas e objetivos de longo prazo.
-
O nível do portfólio é importante nas empresas que oferecem múltiplos conjuntos de produtos. Ele analisa como essas séries de produtos oferecem aos clientes uma solução abrangente que ajuda o negócio a atingir suas metas e objetivos.
-
O nível de produto desenvolve um roadmap para um único produto (suite), detalhando onde ele precisa ir para cumprir sua parte no portfólio.
-
O nível de lançamento detalha o trabalho a ser feito em um produto e em que ordem, e apresenta as datas de entrega com base no desempenho histórico e nas durações de iteração.
-
O nível de iteração se concentra no trabalho a ser feito na próxima iteração. Este é o domínio das equipes que executam o desenvolvimento do produto.
-
O nível diário é onde as equipes se reúnem para discutir o planejamento diário de seu trabalho e o progresso para alcançar o que planejaram no nível de iteração.
Clientes no Centro
No Planejamento Ágil, o foco está continuamente no fornecimento de valor ao cliente.
A questão em todos os momentos é: eles valorizam isso? Pouco mais importa.
O trabalho que uma equipe faz é menos importante do que o valor de seu trabalho representa para os clientes.
Para garantir que o trabalho represente valor para os clientes, você quer entregá-lo regularmente para que possa receber feedback imediato e direto do cliente. Isto então permite que você se adapte conforme constrói e melhora o produto que está criando para eles.
Sim, isto significa que tudo que você planejou pode mudar à medida que o cliente precisa mudar. É por isso que o Planejamento Ágil, assim como o desenvolvimento ágil, é iterativo.
E isso não faz mal porque é o valor do cliente que você procura, não executando um plano para desenvolver algo que o cliente não precisa mais.
Colocar o cliente no centro do Planejamento Ágil é diretamente inspirado pelos dois primeiros princípios do Manifesto Ágil:
-
Nossa maior prioridade é satisfazer o cliente através da entrega antecipada e contínua de software valioso.
-
Bem-vindo às mudanças de requisitos, mesmo atrasado no desenvolvimento. Processos ágeis aproveitam a mudança para a vantagem competitiva do cliente.
Último Momento Responsável
O Planejamento Ágil favorece a tomada de decisões no último momento responsável. Pelo menos para decisões que são irreversíveis — que não têm como voltar, ou o caminho de volta seria caro.
O problema é que não tomar uma decisão tem um custo, mas tomar uma decisão muito cedo — com conhecimento e dados insuficientes — também acarreta um custo significativo.
-
O custo de não tomar uma decisão reside no custo de manter as ineficiências ou outros inconvenientes da situação atual. E estes custos podem muito bem aumentar com o tempo.
-
O custo de tomar uma decisão muito cedo aumenta o risco de tomar a decisão errada e incorre em custos de oportunidade: os ganhos que você poderia ter tido, se tivesse tomado uma decisão diferente.
Você quer adiar o refinamento (detalhamento) de novas características até o último momento responsável, porque o que precisa ser feito para uma funcionalidade mudar à medida que outras funcionalidades são implementadas. Em outras palavras: adicionar detalhes (tomar decisões) muito cedo e você terá desperdiçado o esforço quando as circunstâncias mudarem e precisar adiar essa funcionalidade, ou talvez até mesmo eliminá-la completamente.
Portanto, somente refine completamente (partes de) as funcionalidades que você definitivamente implementará durante as próximas duas ou três iterações. E apenas acrescente detalhes suficientes aos recursos que têm que esperar mais tempo para informar suas decisões de planejamento e priorização.
Entregas Frequentes
Você verá pelo Manifesto Ágil que há uma ênfase na entrega frequente de software funcional.
Da mesma forma, ele é um componente chave do Planejamento Ágil.
As entregas frequentes de funcionalidades vêm com vários benefícios. Quanto mais frequentes as entregas de software funcional, maior e mais detalhada é a resposta do cliente. Isto tem um efeito em cadeia para o planejamento da próxima iteração e evita que se afaste muito do resultado desejado pelo cliente.
Este é um dos contrastes com o desenvolvimento tradicional de “cascata” e os métodos de planejamento de divisão de trabalho antecipado.
Orçamentos e Datas de Entrega
-
Evitar estimativas de data única sempre que possível.
-
Utilizar, em vez disso, ‘intervalos’ de datas.
-
Isso refletirá as variáveis de um projeto
-
Isso basearia os cálculos preditivos usando dados históricos.
-
Tanto os custos quanto a duração do projeto não podem ser definidos com precisão no início.
-
Datas finais fixas rígidas.
-
Cada atividade tem um valor planejado.
-
A duração total do projeto é fixa — é determinista.
-
Os riscos são definidos como fixos.
-
Os custos e a duração do projeto são fixados desde o início.
-
As linhas de base do projeto para o custo, escopo e cronograma refletem as variáveis, mudanças e incertezas inerentes a cada projeto.
-
A utilização de dados históricos para cálculos (simulações de Monte Carlo) produzirá intervalos de datas finais mais realistas.
-
Os orçamentos e as datas de entrega são mais realistas. É melhor estar “quase certo do que totalmente errado”.
-
Você será mais capaz de mitigar riscos tais como: superação do projeto, custos e exposição, onde tarefas individuais podem contribuir para uma superação.
Em resumo, a Timeline Ágil seria flexível em termos de escopo e tempo (para adaptar-se às mudanças de requisitos), mas fixa em termos de recursos (equipes e, portanto, custo).
E é exatamente isso que torna possível estimar custos e determinar orçamentos sem exigir desenvolvimento para fazer estimativas!
A este respeito, o Planejamento Ágil dá o melhor de dois mundos. Mas lembre-se:
-
Foco no trabalho e não no trabalhador.
-
Em uma abordagem ágil, quem faz o trabalho é de importância secundária.
-
O trabalho em si é de primordial importância.
-
Não há necessidade urgente de atribuir papéis, planeje para equipes e não para indivíduos.
-
O fluxo de trabalho em si deve ser suave e contínuo.
-
O negócio decide as funcionalidades que quer construir e as coloca em ordem de prioridade para o negócio.
-
A(s) equipe(s) de desenvolvimento decide(m) como desenvolvê-las.
-
Juntos, eles priorizam as funcionalidades levando em conta as restrições técnicas e as eficiências.
Garantia de Qualidade Incorporada
Embora não faça estritamente parte do processo de planejamento em si, vale a pena ter em mente que, na abordagem de cascata, os testes de aceitação pelos usuários e operadores são uma etapa separada após a construção e os testes técnicos do produto pelos próprios desenvolvedores.
No Agile, a ideia é testar cedo e com frequência. Os usuários e operadores revisam e testam cada funcionalidade assim que ela fica disponível, em vez de esperar até que o produto inteiro esteja pronto.
Afinal de contas, o objetivo é entregar um software que funcione.
Quando você entrega uma funcionalidade em um ambiente ágil, ela é testada e aceita. Não isoladamente, mas no contexto do produto, como ele é cultivado até então.
Não há necessidade de um estágio separado ou de uma equipe separada para garantir que tudo se encaixe e funcione em conjunto. Tudo isso faz parte do processo padrão e já está concluído.
Isto torna o planejamento muito mais fácil e as datas de entrega mais previsíveis, pois não haverá grandes surpresas desagradáveis no final, forçando você a fazer um monte de reformulações. As surpresas são sempre limitadas ao que você fez em uma iteração e — com a colaboração e feedback do cliente em cada iteração — o risco de criar algo que o cliente não pretendia também é pequeno.
A Entrega Contínua Torna o Planejamento Ainda Mais Fácil
Um grande obstáculo ao planejamento previsível são os comprimentos que os desenvolvedores têm de percorrer para manter as funcionalidades acabadas fora do produto lançado, porque o calendário da empresa age de forma diferente. Por exemplo, quando um conjunto de novas funcionalidades deve ser lançado durante uma feira de negócios.
O problema é que manter essas funcionalidades ‘em estoque’ apresenta riscos porque o trabalho no produto não para, e incorporá-las em uma data posterior significa ter que refazer o trabalho, especialmente muitos testes.
A maneira de evitar tudo isso é adotar uma entrega contínua com funcionalidades, controlando quais funcionalidades estão disponíveis para quem. Isto permite que você desconecte o momento de lançamento aos clientes a partir do momento em que uma funcionalidade é integrada à base de códigos lançada.
Uso de Decisões Orientadas por Dados
Um componente chave do Planejamento Ágil é sua flexibilidade inerente para se adaptar às mudanças em um ambiente de trabalho.
O desafio de entregar projetos na pandemia é um grande exemplo disso. Durante a pandemia, algumas pessoas adoeceram, e estar localizadas no mesmo prédio se tornou impossível. Isto afetou todos os envolvidos no desenvolvimento e entrega de novas e modificadas funcionalidades.
Ao invés de tentar adivinhar linhas de tempo determinísticas fixas, o Agile usa dados e métricas reais para tomar decisões realistas e informadas.
Há várias ferramentas para fazer isto.
Uma ferramenta frequentemente utilizada são os quadros e métricas Kanban focados no fluxo de trabalho através do processo e utilizando-os para estimar as datas de entrega dos trabalhos em mãos e em pipeline.
Uma abordagem mais matemática é usar simulações de Monte Carlo para prever os custos e as prováveis datas de entrega. Elas são usadas há muito tempo no Gerenciamento de Projetos Lean e são uma ferramenta útil para estimar o rendimento de projetos.
A simulação de Monte Carlo utiliza dados históricos sobre capacidade e desempenho para calcular a porcentagem de chance de atingir uma meta do projeto, como custo ou data de entrega. Isto então permite avaliar o risco associado com o trabalho.
Semelhanças e Diferenças
-
O planejamento tradicional é determinístico (ou tenta ser) — o Planejamento Ágil é probabilístico aceitando as mudanças do mundo.
-
O planejamento tradicional é visto como uma opção ‘segura’ — o Planejamento Ágil é visto como uma opção ‘arriscada’. Isto é incorreto.
-
O planejamento tradicional se compromete cedo no ponto de menos conhecimento — o Planejamento Ágil se compromete no último momento responsável no ponto de conhecimento informado que também aumenta exponencialmente com o feedback contínuo do cliente.
-
O planejamento tradicional é rígido, o plano em si é tudo — o Planejamento Ágil é flexível, o plano em si é relativamente sem importância, o planejamento é tudo.
-
Os relatórios tradicionais de planejamento fixam datas de entrega, implicando previsibilidade e certeza — o Planejamento Ágil utiliza intervalos de datas preditivas utilizando dados históricos, aceitando a fluidez de uma atividade complexa em um ambiente adaptativo complexo.
-
O planejamento tradicional muitas vezes exige planos separados ou específicos para a estratégia empresarial — gerenciamento de portfólio para o planejamento diário — o Planejamento Ágil engloba a harmonização do planejamento desde a estratégia até o ‘chão da fábrica’.
-
O planejamento tradicional se concentra nas tarefas — o Planejamento Ágil se concentra no valor.
O risco com a abordagem em cascata de fazer previsões cedo, quando menos se sabe sobre o que está por vir, é que as previsões são extremamente imprecisas. A razão é que uma mudança nas necessidades do cliente significa que o trabalho que já foi feito em estágios anteriores também precisa ser refeito.
A abordagem do Planejamento Ágil é inerentemente iterativa e adaptável. O risco é mitigado com o feedback do cliente durante todo o projeto e com cada funcionalidade de trabalho entregue.
Vale ressaltar que a grande escala de alguns projetos como os realizados pela NASA seguirá uma abordagem mais tradicional de planejamento ou um híbrido de planejamento em cascata e Agile chamado Planejamento em Espiral.
Image courtesy: Nasa
Principais Funções e Responsabilidades
-
Gerência sênior responsável pelo planejamento estratégico e de portfólio.
-
Gerentes de projeto, gerentes de produto, gerentes de pesquisa e líderes de equipe de produto responsáveis pelo planejamento do produto.
-
Gerentes de projeto, gerentes de entrega responsáveis pelo planejamento do lançamento e pela ponte entre o pessoal acima e as equipes técnicas para decidir quais funcionalidades eles irão lançar.
-
Desenvolvedores, testadores, designers, responsáveis pelo planejamento de iteração e planejamento diário.
Principais Reuniões, Ciclos e Cadências de Entrega
-
As equipes discutem diariamente o trabalho do dia-a-dia. Pense na Daily no Scrum ou no início do dia no Lean.
-
Os planos de iteração obviamente seguem a duração da iteração. Por exemplo, o Planejamento de Sprint no Scrum, informado pelos resultados da Revisão de Sprint e Retrospectiva sobre o Sprint anterior.
-
Os planos de lançamento geralmente seguem uma cadência trimestral. Pense no Planejamento Trimestral de Incremento de Produtos no SAFe.
-
Os roadmaps e planos de portfólio de produtos normalmente têm um timebox de 12 meses.
-
As empresas geralmente têm planos estratégicos de 12 meses e 5 anos.
Armadilhas Comuns
Para que o Planejamento Ágil funcione, o pensamento ágil, conforme estabelecido no Manifesto Ágil, precisa estar no topo da mente de todos em toda a sua empresa, em todos os seus departamentos e em todo o seu pessoal.
-
O Planejamento Ágil se relaciona com a busca de objetivos comerciais e como estes se deslocam até o “chão da fábrica” para manter todos alinhados. Os problemas ocorrem quando um departamento está fora de sincronia com outro.
-
Frequentemente, o Planejamento Ágil é adotado com sucesso nas três camadas internas da cebola, mas não nas três camadas superiores. Isto expulsa tudo do kilter.
-
Não aceitar que o plano em si mudará inevitavelmente como ele mesmo é, iterativo e refletirá a mudança das exigências do cliente.
-
Uma fraqueza comum é o planejamento a partir de uma data fixa pré-determinada. Isto encoraja a previsão futura a partir de uma posição onde se tem o menor conhecimento.
-
Esquecendo que o objetivo é mitigar e reduzir o risco, não aumentá-lo tomando decisões ou previsões em um momento em que você não tem conhecimento suficiente para fazê-lo.
Começando
A melhor coisa que você pode fazer para ter um excelente começo em sua campanha de Planejamento Ágil é buscar treinamento e conselhos.
Não apenas para alguns, mas para todos os envolvidos no planejamento em qualquer camada da Cebola de Planejamento Ágil. Afinal, divulgar o conhecimento ajuda a espalhar a mentalidade e coloca todos na mesma página.
Dito isto, não pule para o fundo do poço com todos ao mesmo tempo.
Comece com as camadas internas da Cebola de Planejamento Ágil. Estas são as pessoas que provavelmente já estão bem versadas no planejamento de suas iterações de forma ágil.
Movam-se para fora uma camada de cada vez. Se você tiver vários grupos de produtos, você pode considerar isso primeiro para um único grupo de produtos e usar a experiência com isso para trazer outros grupos de produtos a bordo.
Leitura Adicional
-
Agile Project Management: Creating Innovative Products por Jim Highsmith.Agile Project Management: Creating Innovative Products por Jim Highsmith.
-
Herding Cats por Greg Ross-Munro
-
Forecasting: Asking the right questions for Business Agility (webinar sob demanda)
-
Delivering Business Agility without Estimation
-
Portfolio and Upstream Kanban (on demand webinar)
A vida é boa quando suas equipes Agile estão sincronizadas!
Contate-Nos hoje para uma demonstração personalizada do SwiftEnterprise! Ou inscreva-se para atualizações abaixo.
