Por Eli Rodrigues,
Muitas empresas de software tem buscado a “solução mágica”
no Scrum, mas não estão obtendo o resultado esperado. A maioria delas, após
alguns meses, desiste do framework e volta ao ad-hoc, culpando-o pelo fracasso.
Mas será que essas empresas estão implantando corretamente?
Pelo que tenho visto, a maioria tem feito “adaptações” no
framework que tiram algumas de suas características essenciais. Por exemplo, o
intenso ciclo de comunicação garante alinhamento de expectativas; a constante
revisão de escopo garante coesão no projeto; as entregas intermediárias buscam
atendimento da necessidade do cliente e correção de falhas antes do final do
projeto; o conceito de timebox força a equipe a ter o que entregar, evitando o
prolongamento de atrasos. Ora, esses benefícios são provenientes dos princípios
embutidos no Scrum e adaptar o processo pode trazer resultados desastrosos.
Mas quais são os erros mais frequentes? Fiz um levantamento
de erros comuns e que levam a implantação do Scrum ao fracasso:
1) - Vestir a capa de scrum, mas trabalhar cascata
Sprints são timeboxes, ou seja, um tempo fechado em que se
realizam entregas parciais do projeto. As entregas são priorizadas para que, ao
final do tempo, exista uma ”saída”, “alguma” entrega.
Montar sprints como etapas ou fases de um projeto é um erro.
Dessa forma perdem-se os benefícios do ciclo de melhoria contínua (que muito
lembra o PDCA), mais conhecido como iterativo-incremental, que grossomodo
significa entregar parcialmente e agregar valor ao produto a cada ciclo,
através da melhoria contínua. Portanto, é importante que as entregas sejam
parciais e evolutivas.
2) - Impor prazo de “cima para baixo”
A definição de “prazos arbitrários” é uma prática condenada
também pelo PMI, deve-se envolver os executores das atividades na fase de Planejamento.
O Scrum não precisa de nada disso, ele trabalha com sprints e invés de um prazo
fechado. Precisam-se de entregas priorizadas para que a equipe “decida” o que
vai ser entregue, caso no prazo não seja possível terminar tudo.
Existe muita polêmica em relação a essa questão, pois as
pessoas se sentem desconfortáveis em afirmar que a equipe “poderá não entregar
tudo”, mas no mundo real muitas equipes não realizam as entregam na data
combinada e atrasam os projetos. O Scrum não quer dizer que a equipe vai fazer
“corpo-mole” e deixar de entregar as coisas, pois existe um monitoramento
diário das atividades e as entregas são parciais. Desse modo, não haverá aquela
pressão do último dia, mas uma pressão a cada sprint, reduzindo o risco de um
atraso maior. Além do mais, a equipe fica ciente de que deve fazer primeiro o
que for prioridade e que SE for preciso, entreguem parcialmente, mas jamais
deixem de entregar no prazo.
3) - Realocar membros da equipe para outros projetos “mais
prioritários”
A mudança de prioridade entre projetos não combina muito bem
o com o agile, pois ele tem como premissa o trabalho integrado, colaborativo e
priorizado. Toda a motivação da equipe no Scrum (segundo minha percepção) vem
do agrupamento, do cumprimento de metas e da cobrança mútua, parâmetros
estimulados pelo Scrum de um modo geral. Além disso, lições aprendidas,
sincronia e alto desempenho serão perdidos com a troca de “componentes” (de
pessoas).
4) - Não fazer reunião diária
É na reunião diária que se faz a gestão da equipe, do
desenvolvimento das entregas, da qualidade e dos problemas. Não cumprir essa
prática rompe com os ciclos de comunicação, acompanhamento e põe em risco a
entrega do Sprint. Além disso, o relato de desempenho diário faz com que a
equipe se cobre mutuamente impulsionando a produtividade.
5) - Não endereçar e resolver os impedimentos
No Scrum, as pessoas são incentivadas a comentar o trabalho
que estão fazendo diariamente (como descrito acima) e também qualquer
impedimento que esteja causando impacto em suas atividades. Se você não
resolver os impedimentos com muita seriedade, elas simplesmente vão parar de
reportar, não cumprirão os prazos e eventualmente até boicotarão o processo.
Neste caso, a frase mais comuns nos corredores é: “Eu já falei, mas ninguém faz
nada!”.
6) - Fazer a reunião diária sem o quadro de acompanhamento
Sem o quadro de acompanhamento fica impossível controlar o
andamento do trabalho. Todo tipo de Controle precisa de uma linha de base de
comparação, no caso do Scrum essa linha de base é o quadro de acompanhamento.
7) - Não gerar o gráfico de burndown
O gráfico de burndown é uma das ferramentas mais poderosas
de comunicação do Scrum. Permite que clientes, gestores e equipe tenham uma
visão real e atualizada do projeto todo. Ele pode ser feito tanto para os
Sprints quanto para os itens do Product Backlog e ajuda a prever a data final
do projeto. Lembre-se, sem linha de base não existe controle, sem controle não
existe sucesso.
8) - Criar sprints estanques
Todo sprint deve ter um objetivo, mas não entregas fixas e
invidivisíveis, pois há perda de agilidade. Quando uma entrega está travada
(com dificuldade para ser implementada),
a equipe pode decidir passar para a próxima entrega, enquanto os
impedimentos são resolvidos, ou montar uma força-tarefa para resolver o impedimento
. Isso ajuda a chegar no prazo final com alguma entrega pronta, apesar dos
percalços. Sem flexibilidade, a chance de atrasos é muito maior.
9) - Atrasar o prazo final dos sprints
Scrum é timebox, é
”quanto consigo fazer até o final do sprint”. Isso força a equipe a pensar
sempre em entregas funcionais e aceitas pelo cliente, a buscar alternativas, a
se superar. Mudar essa perspectiva para “quando consigo entregar um grupo de
funcionalidades” pode levar a equipe a atrasos. A pressão deve estar totalmente
voltada para a entrega.
10) - Ter um Scrum Master sem autoridade (grupos matriciais)
O Scrum Master precisa de autoridade suficiente para
planejar, organizar, comandar, coordenar e controlar as atividades de sua
equipe. Se uma autoridade externa influenciar na alocação, impuser prioridades
ou simplesmente retirá-los da equipe fica muito difícil o SM conseguir formar
uma equipe de alto desempenho, como é esperado. Mas quando a equipe+SM não tem
autoridade para determinar as atividades e prioridades dentro do sprint, o
resultado é totalmente fora do esperado.
A maior dificuldade para as organizações tem sido mudar o
dilema: é melhor ter um prazo ou entregar um produto funcional ao final de um
período? É melhor ter um escopo congelado ou entregar um produto que
corresponde às necessidades do cliente? É melhor ter atas de reunião e
relatórios ou fazer uma comunicação simples e entregar o produto no final do
projeto?
Esses princípios têm dado bons resultados em vários lugares
ao redor do mundo, analise se sua empresa está realmente seguindo os princípios
certos, o melhor indicador são os resultados (entregas e clientes satisfeitos),
a metodologia pouco importa.
Eli Rodrigues tem a carreira
dedicada a projetos. É membro ativo do PMI, construindo e
compartilhando conhecimento através de
cursos, palestras, artigos e da execução de projetos.
Nenhum comentário:
Postar um comentário