10 erros na implantao do Scrum que voc no quer cometer

By Eli Rodrigues / 2011/11/11 / 6 Comments

(http://www.dinamusgp.com/elirodriguesblog/wp-content/uploads/2011/10/cartola_magica.jpg)

Muitas empresas de software tem buscado a

soluo mgica no Scrum, mas no esto obtendo o resultado esperado. A maioria delas, aps alguns meses, desiste do framework e volta ao ad-hoc, culpando-o pelo fracasso. Mas ser que essas empresas esto implantando corretamente? Pelo que tenho visto, a maioria tem feito adaptaes no framework que tiram algumas de suas caractersticas essenciais. Por exemplo, o intenso ciclo de comunicao garante alinhamento de expectativas; a constante reviso de escopo garante coeso no projeto; as entregas intermedirias buscam atendimento da necessidade do cliente e correo de falhas antes do final do projeto; o conceito de timebox fora a equipe a ter o que entregar, evitando o prolongamento de atrasos. Ora, esses benefcios so provenientes dos princpios embutidos no Scrum e adaptar o processo pode trazer resultados desastrosos. Mas quais so os erros mais frequentes? Fiz um levantamento de erros comuns e que levam a implantao do Scrum ao fracasso: 1. Vestir a capa de scrum, mas trabalhar cascata Sprints so timeboxes, ou seja, um tempo fechado em que se realizam entregas parciais do projeto. As entregas so priorizadas para que, ao final do tempo, exista uma sada, alguma entrega. Montar sprints como etapas ou fases de um projeto um erro. Dessa forma perdem-se os benefcios do ciclo de melhoria contnua (que muito lembra o PDCA), mais conhecido como iterativo-incremental, que grosso modo significa entregar parcialmente e agregar valor ao produto a cada ciclo, atravs da melhoria contnua. Portanto, importante que as entregas sejam parciais e evolutivas. 2. Impor prazo de cima para baixo A definio de prazos arbitrrios uma prtica condenada tambm pelo PMI, deve-se envolver os executores das atividades na fase de Planejamento. O Scrum no precisa de nada disso, ele trabalha com sprints e invs de um prazo fechado. Precisam-se de entregas priorizadas para que a equipe decida o que vai ser entregue, caso no prazo no seja possvel terminar tudo. Existe muita polmica em relao a essa questo, pois as pessoas se sentem desconfortveis em afirmar que a equipe poder no entregar tudo, mas no mundo real muitas equipes no realizam as entregam na data combinada e atrasam os projetos. O Scrum no quer dizer que a equipe vai fazer corpomole e deixar de entregar as coisas, pois existe um monitoramento dirio das atividades e as entregas so parciais. Desse modo, no haver aquela presso do ltimo dia, mas uma presso a cada sprint, reduzindo o risco de um atraso maior. Alm 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 prioritrios A mudana de prioridade entre projetos no combina muito bem o com o agile, pois ele tem como premissa o trabalho integrado, colaborativo e

priorizado. A principal motivao da equipe no Scrum vem do agrupamento, do cumprimento de metas e da cobrana mtua, parmetros estimulados pelo Scrum de um modo geral. Alm disso, lies aprendidas, sincronia e alto desempenho sero perdidos com a troca de componentes (de pessoas). 4. No fazer reunio diria na reunio diria que se faz a gesto da equipe, do desenvolvimento das entregas, da qualidade e dos problemas. No cumprir essa prtica rompe com os ciclos de comunicao, acompanhamento e pe em risco a entrega do Sprint. Alm disso, o relato de desempenho dirio faz com que a equipe se cobre mutuamente impulsionando a produtividade. 5. No enderear e resolver os impedimentos No Scrum, as pessoas so incentivadas a comentar o trabalho que esto fazendo diariamente (como descrito acima) e tambm qualquer impedimento que esteja causando impacto em suas atividades. Se voc no resolver os impedimentos com muita seriedade, elas simplesmente vo parar de reportar, no cumpriro os prazos e eventualmente at boicotaro o processo. Neste caso, a frase mais comuns nos corredores : Eu j falei, mas ningum faz nada!. 6. Fazer a reunio diria sem o quadro de acompanhamento Sem o quadro de acompanhamento fica impossvel controlar o andamento do trabalho. Todo tipo de Controle precisa de uma linha de base de comparao, no caso do Scrum essa linha de base o quadro de acompanhamento. 7. No gerar o grfico de burndown O grfico de burndown uma das ferramentas mais poderosas de comunicao do Scrum. Permite que clientes, gestores e equipe tenham uma viso 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 no existe controle, sem controle no existe sucesso. 8. Criar sprints estanques Todo sprint deve ter um objetivo, mas no entregas fixas e invidivisveis, pois h perda de agilidade. Quando uma entrega est travada (com dificuldade para ser implementada), a equipe pode decidir passar para a prxima entrega, enquanto os impedimentos so resolvidos, ou montar uma fora-tarefa para resolver o impedimento . Isso ajuda a chegar no prazo final com alguma entrega pronta, apesar dos percalos. 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 fora 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 presso deve estar totalmente voltada para a entrega. 10. 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 alocao, impuser prioridades ou simplesmente retirar membros da equipe fica muito difcil o SM conseguir formar uma equipe de alto desempenho. Mas quando a equipe+SM no tem autoridade para determinar as atividades e prioridades dentro do sprint, o resultado totalmente fora do esperado. A maior dificuldade para as organizaes tem sido mudar o dilema: melhor ter um prazo ou entregar um produto funcional ao final de um perodo? melhor ter um escopo congelado ou entregar um produto que corresponde s necessidades do cliente? melhor ter atas de reunio e relatrios ou fazer uma comunicao simples e entregar o produto no final do projeto? Esses princpios tm dado bons resultados em vrios lugares ao redor do mundo, analise se sua empresa est realmente seguindo os princpios certos, o melhor indicador so os resultados (entregas e clientes satisfeitos), a metodologia pouco importa.

2014 Gesto de Projetos na prtica.