10 erros na implantação do Scrum que você não quer cometer
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:
- 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 grosso modo 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. - 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. - 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. A principal motivação da equipe no Scrum 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). - 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 da Sprint. Além disso, o relato de desempenho diário faz com que a equipe se cobre mutuamente impulsionando a produtividade. - 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!”. - 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. - 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 as 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. - Criar sprints estanques
Toda 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. - Atrasar o prazo final das sprints
Scrum é timebox, é “quanto consigo fazer até o final da 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. - Ter um Scrum Master sem autoridade (grupos matriciais)
O Scrum Master precisa de autoridade suficiente para fazer o fluxo do Scrum ser executado na empresa. Se uma autoridade externa influenciar na alocação, impuser prioridades ou simplesmente retirar membros da equipe fica muito difícil o SM conseguir formar uma equipe de alto desempenho. Mas quando a equipe+SM não tem autoridade para determinar as atividades e prioridades dentro da 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
Muito bom o texto.
Realmente as empresas não entendem que os valores do Scrum precisam ser mantidos para que ele funcione como “promete”.