AgileFall é um termo irônico para gestão de projetos onde você tenta ser ágil e enxuto, mas continua a utilizar técnicas de desenvolvimento waterfall. Isso normalmente produz resultados parecidos com uma mistura de cera de piso com cobertura de sobremesa.
Acabei de participar de uma reunião de gestão de projetos onde vi em primeira mão, o AgileFall acontecer. A boa notícia é que alguns ajustes no processo nos levaram de volta ao caminho certo.
A reunião aconteceu em uma empresa da Fortune 10. Estamos ajudando-os a migrar a metodologia de gestão de projetos de uma das suas mais importantes linhas de produtos de uma de suas divisões de Waterfall para Lean.
Nosso cliente, o vice-presidente de produtos, é inteligente, inovador e motivado. Sua empresa está enfrentando turbulências causadas por novos concorrentes. Ele percebeu que o desenvolvimento tradicional com waterfall não era apropriado quando o problema e a solução continham muitas incógnitas.
A linha de produto que é nosso foco tem 15 gerentes de projetos cuidando de 60 projetos. Nos últimos meses nós o ajudamos a introduzir os princípios básicos do Lean nestes projetos. São todos projetos Horizonte 1 ou 2 – que trazem novas funcionalidades para produtos existentes com foco em clientes existentes, ou são reposicionamento de produtos, ferramentas ou técnicas para novos clientes. As equipes estão criando produtos mínimos viáveis (MVPs), estão saindo do escritório para efetivamente conversar com usuários e com os stakeholders, e para obter permissão para promover reviravoltas etc. Tudo isso, fundamentos eficazes do Lean.
No entanto, em nossa última reunião, percebi que o VP de produtos ainda geria seus gerentes de projetos utilizando processos do Waterfall. As equipes só compareciam – veja só – a cada três meses para reuniões formais de revisão do cronograma. Fiquei só escutando enquanto o cliente me contava o quanto as equipes reclamavam da quantidade de relatórios que precisavam trazer para estas reuniões trimestrais. E ele estava insatisfeito com a qualidade destes relatórios porque sentia que eram escritos na noite anterior às reuniões. Como, perguntou ele, poderia conseguir que seus gerentes de produtos produzissem mais avaliações de desempenho e relatórios dentro dos prazos?
À primeira vista, pensei, o que pode ser tão ruim com relação a ter mais informações? Não é exatamente isso que queremos – tomar decisões baseadas em evidências? Estava prestes a me deixar conduzir pelo caminho sedutor de sugerir ainda mais avaliações de eficiência quando percebi que nosso cliente ainda utilizava um processo onde o sucesso era medido por relatórios, não por resultados. Era o mesmo processo de relatórios utilizados para avaliar os projetos que usavam o linear passo a passo Waterfall.
(Para ser justo, esta equipe é uma ilha Lean em uma empresa ainda dominada pelo Waterfall. Embora este grupo tenha mudado tanto a forma de pensar como o ritmo da empresa, as pessoas para quem ele se reporta ainda não entendem os aprendizados e resultados que os Agile/Lean podem oferecer. Estão apenas interessados nos relatórios.)
Para administrar tanto as equipes acima quanto as abaixo do meu cliente, precisávamos de abordagens totalmente diferentes para a gestão de projetos.
Conforme a conversa evoluiu, chegamos a um acordo sobre como gerenciar projetos utilizando alguns princípios operacionais das metodologias de gestão de projetos Lean/Agile (nunca mencionando as palavras Lean ou Agile).
- São as pessoas que estão criando valor (encontrando soluções/adequação à missão), não os processos e relatórios.
- No entanto, os processos e relatórios ainda são essenciais para os gestores acima dele.
- Conseguir que as equipes construam MVPs incrementais e iterativos é mais importante que ser obsessivo sobre documentação/relatos prematuros.
- É fundamental permitir que as equipes se concentrem no que aprenderam em suas interações com os clientes em vez de seguir cegamente um plano que lhes foi apresentado no primeiro dia.
- O progresso na obtenção de resultados (soluções/adequação à missão) não é linear e nem todas as equipes progridem na mesma velocidade.
Sem muita convicção, nosso cliente concordou que, em vez das reuniões trimestrais de avaliação, a equipe de liderança conversaria semanalmente com 4 – 5 gerentes de projetos, analisando 16 – 20 projetos. Isso significa que o ciclo de interação – apesar de ainda ser longo – passaria dos atuais três meses para, pelo menos, uma vez ao mês.
Mais importante ainda, decidimos que ele focaria estas conversas em resultados, e não em relatórios. Isso significava mais comunicação verbal e muito menos papel. As análises seriam sobre as entregas regulares, desenvolvimentos incrementais e como a liderança poderia remover obstáculos. E o time de nosso cliente continuaria a compartilhar seu sucesso com os outros times para que aprendessem uns com os outros.
Em resumo, a ideia principal era que a função do vice-presidente de produtos não seria a de encorajar o time de baixo a produzir relatórios, mas sim, de incentivá-los a obter resultados, e então, traduzir seu progresso para a cadeia superior de comando. Ao mesmo tempo que isso foi ótimo para as equipes, significou um ônus para o VP de produtos que precisava relatar o progresso alcançado para sua liderança no formato em que queriam ver.
Perto do final da reunião, tudo ficou muito claro para mim. O cliente perguntou para a sua equipe, “Seguindo adiante, quem são as pessoas certas na equipe para gerenciar um processo Lean versus um processo Waterfall?” E sorri quando concluíram que o Lean podia ser gerenciado por menos pessoas, mas que conseguissem trabalhar em um ambiente caótico de aprendizado, quando comparado ao ambiente de execução orientado a processos.
Mal posso esperar pela próxima reunião.
Steve Blank é professor adjunto na Stanford University, senior fellow na Columbia University, e docente na University of California, Berkeley. É cofundador ou um dos primeiros funcionários de oito startups de alta tecnologia, e ajudou a criar os programas da National Science Foundation Innovation Corps e do Hacking for Defense e Hacking for Diplomacy.
Fonte HBR