Gerenciar projetos ágeis é muito mais que colar post-its em parede

Olá amigos do PTI!

Sabia que gerenciar projetos ágeis é muito mais que colar post-its em parede?

Percebo que, para muitas pessoas, gerenciamento ágil ainda é sinônimo de:

  • Post-its em parede (já falei isso, certo? ;-))
  • Jogar “aquele baralhinho” para estimar
  • Só funciona em projetos de “escopo aberto”
  • Equipes que se “autogerenciam”
  • Falta de documentação

Quando na verdade a agilidade está muito mais relacionada com um estado de arte e com os princípios do Lean. Se você realmente quer gerenciar projetos de uma maneira ágil, você já pensou se:

  • Você está adotando o caminho mais simples, objetivo e sem desperdícios para o seu projeto?
  • Você está disposto a encurtar o seu ciclo de aprendizado e melhoria contínua (PDCA), desta forma identificando mudanças ou mesmo expondo problemas mais rapidamente?
  • O seu planejamento é feito de forma colaborativa com o seu cliente ou você faz o cliente produzir artefatos somente para seguir a metodologia “cover my a..”?
  • Você permite que sua equipe estime de forma consensual e colaborativa ou você mesmo inventa um monte de atividades da sua cabeça, define os prazos e só delega tarefas para sua equipe?
  • Você acredita que para definir o escopo de um projeto são necessárias páginas e páginas, ou conseguimos delimitar as fronteiras e os grandes deliverables e ir refinando o escopo no decorrer do projeto (lembre-se sempre que escopo elaborado progressivamente é diferente de escopo aberto)?
  • Você gerencia ou lidera pessoas? O que você tem feito para desenvolver o melhor que existe dentro de cada membro da sua equipe?
  • As documentações e artefatos formais produzidos pelo seu projeto possuem alguma finalidade? Possuem algum valor? Seu Project Charter precisa ter 15 páginas e sua declaração de escopo ter 892 páginas? Se sim, te faço a seguinte pergunta: “Por que?”. Se a resposta for: “Porque a área de escritório de projetos e/ou governança exige desta forma”, pare tudo! Qualquer artefato formal produzido precisa ter um sentido, um valor agregado e não somente um puro exercício de desperdício para atender área X ou área Y. Desperdício custa caro p/ empresa e é um dinheiro invisível que literalmente vai para o ralo.

Depois de sua reflexão sobre os pontos acima, permita-me lançar algumas percepções e opiniões:

  • Gerenciamento ágil não se resume somente a Scrum
  • Não existe o método “one size fits all”, duvide sempre de quem vende isso!
  • PMBOK não é “inimigo” do ágil. São complementares.
  • Waterfall não é “inimigo” do ágil (Lembra do que eu falei sobre “one size fits all”).
  • Desperdício, burocracia em excesso e metodologia “cover my a..” são “inimigos” do ágil.

Onde quero chegar? Bom, como já disse que não acredito no “one size fits all”, a grande arte de gerenciar um projeto é usar o melhor das ferramentas que você tem disponíveis na mão e isso pode significar:

  • Usar Scrum puro e 100% em um projeto
  • Usar Scrum e Kanban em um projeto
  • Usar só Kanban
  • Usar Scrum e utilizar práticas de gerenciamento de custos descritos no PMBOK
  • Usar FDD e XP em projetos de ERP
  • Usar Watefall em uma determinada fase do projeto e métodos ágeis em outras etapas
  • Utilizar gerenciamento ágil com artefatos de gerenciamento formal como Microsoft Project

Em resumo, você pode criar o seu modelo, seja ele puro ou híbrido. Mas não saia criando modelos híbridos ou “metodologias” porque você leu isso em algum lugar descrito como “Nova Tendência”. Não tem nada de novo, a expressão tailoring (ou tailor-made) em projetos, que significa combinar as melhores ferramentas de acordo com o projeto, existe há anos! Use o que resolve o seu problema de gestão! Use o “remédio certo” para a “cura do seu problema”! Se for um método puro, muito bom! Se for um método híbrido, tão bom quanto!

Também evite criar modelos apenas para seu marketing pessoal! Crie algo que ajude a entregar valor e qualidade dentro das restrições do seu projeto. E lembrando que como não acredito no “one size fits all” (mais uma vez!), este modelo pode servir apenas para um único projeto, não sendo a “cura milagrosa” para todos os projetos da humanidade.

“Vitor, espera aí! Gerenciamento ágil com Microsoft Project? Aí você forçou a barra! Isso viola os princípios do Manifesto Ágil e vai contra…..”

Ops, calma lá! É perfeitamente possível converter a imagem deste post em um artefato formal dentro do Project. Mas claro, precisamos mudar um pouco o mindset. Não será convertido em um artefato com 20.000 linhas que representam atividades literalmente inventadas pelo gerente de projeto. Mas será convertido em um artefato 100% coerente com os princípios ágeis, permitindo inclusive a gestão de custos através do EVM (Earned Value Management).

Como fazer isso? É papo para um próximo artigo. 🙂

Vitor Massari

Mais artigos deste autor »

Profissional com mais de 15 anos de experiência em projetos de software. Sócio-proprietário da Hiflex Consultoria, profissional PMP e agilista, acredita no equilíbrio entre as várias metodologias e frameworks voltados para gerenciamento de projetos.
Lema: "Agilista convicto sempre, agilista obcecado jamais"


3 Comentários

Renan Colebrusco
1

Realmente ainda há uma certa confusão quando o assunto é desenvolvimento ágil. Como relatado no texto, muitos adotam práticas desnecessárias ou acabam deixando de lado algumas relevantes.

Elio
3

Excelente artigo… meus parabéns. Em Agência Full Service, temos que adaptar o gerenciamento para cada tipo de atividade. No Marketing Digital, entregas constantes e necessidades que surgem durante uma campanha (que não podem esperar, afinal erros custam caro), e para área de DEV (Sites ou Aplicativos) é totalmente diferente (projetos são planejados para serem entregues com 60, 90 ou 120 dias)

Deixe seu comentário

Seu endereço de e-mail não será publicado. Campos com * são obrigatórios!