You are on page 1of 3

Scrum: 10 situaes de quando ele poder (e certamente ir) fracassar

O Scrum uma poderosssima ferramenta para execuo de projetos, mas, se falhar no equilbrio Flexibilidade x Disciplina, o tombo pode ser feio.

Veja abaixo algumas causas onde certamente seu projeto Scrum ir fracassar: 1) Dificuldades em se estabelecer a viso ou as fronteiras da viso do produto, gerando Sprints interminveis e impossibilitando estabelecer prazo Certa vez um executivo, ao qual eu me reportava, disse: Vitor, est provado que esse lance de Scrum funciona muito bem na execuo. Mas ele no consegue estabelecer prazo. Eu disse a ele que o problema era que nossos usurios-chave no conseguiam responder a uma pergunta bsica: De onde quero que meu produto parta at onde eu quero que ele termine? Sem isso, voc sempre vai trabalhar pensando no curto prazo, no imediatismo e tem grandes chances de ter um projeto interminvel o que por si s j soa incoerente, pois projeto um esforo temporrio para a construo de um produto ou servio. No caia na cilada de muitos agilistas que dizem que projeto gil no tem estimativa de prazo e nem cronograma. No mundo Agile existe uma srie de tcnicas e artefatos que permitem prover este tipo de informao (recomendo fortemente leituras dos autores Mike Cohn e Ken Schwaber). 2) Focar no que no agrega tanto valor ao produto Certa vez uma gerente de produtos que participava de um workshop meu, disse: Esse lance de Sprints at que legal, mas algumas entregas que so feitas simplesmente no me importam muito e acabam no resolvendo meu problema. Respondi sobre a palavra-chave do que a Sprint deve produzir: VALOR. No adianta pegar um projeto e fracionar em 10 Sprints, sendo que a maior parte delas no agrega valor ao produto e apenas nas ltimas possvel ter feedback do cliente final. Muitos agilistas principiantes acabam fatiando o produto em diversas entregas, mas erram no valor agregado nestas entregas.

3) Distanciamento entre Product Owner e o restante do Time Scrum Ora, se um dos princpios do Manifesto gil que indivduos e interaes devam prevalecer sobre processos e ferramentas, no faz nenhum sentido ter um Product Owner que no se comunica com o Time. Se no h sinergia, sintonia e o conceito de Whole Team, o fracasso certo! 4) Interferncias externas ou mesmo do Product Owner impondo o que deve caber ou no dentro de uma Sprint, sem obter o feedback do time de desenvolvimento O famoso Top-Down ou mais conhecido como goela abaixo. Flexibilidade e a negociao so belas artes do Scrum. Se os integrantes do Time Scrum no tiverem domnio destas artes ou no tiverem fora para brecar rudos externos que atrapalhem estas artes, corre-se o risco de comprometimento da qualidade. 5) Negociar qualidade Deixa-se de lado o valor da Sprint e entrega-se o que d para entregar apenas para cumprir um prazo, pouco importando se a qualidade boa ou no. Negociao uma arte do Scrum, mas negociar qualidade PROIBIDO ! Se o tempo realmente uma restrio, foque sempre numa entrega de VALOR e QUALIDADE 6) Sprints curtas demais obrigando o Time Scrum trabalhar em ritmos insustentveis Outro caso de comprometimento da qualidade e violao dos valores do Manifesto gil. Fazer horas-extras pode at ser bom e produtivo no primeiro dia. Mas depois fatores fisiolgicos (cansao, sono acumulado) e psicolgicos (saudades do pai, da me, do namorado, da namorada, do cachorro, do jogo da TV) diminuem o rendimento, consequentemente podendo comprometer a qualidade. Tente encontrar a durao ideal da Sprint, onde o time trabalhe em ritmo sustentvel e entregue valor. 7) Time de desenvolvimento sem maturidade ou experincia para se auto-organizar Neste caso, mais do que nunca, necessrio o apoio e coaching do Scrum Master para o desenvolvimento do time. Um time inadequado vai gerar um produto inadequado.

8) Scrum Master omisso, permitindo que a auto-organizao torna-se caos Muito manjado que o Scrum Master um lder que serve o time no chefia, no microgerencia mentora e remove impedimentos. Mas no se deixe simplesmente ficar sentado passivamente assistindo tudo acontecer. No chefiar no significa no monitorar, no tomar atitude diante das dificuldades ou mesmo da disciplina do time. Acompanhe o Kanban, escute ativamente o que est rolando no Daily Scrum, certifique-se de voc tem o time ideal e de alto nvel, mentore com a ajuda do time aqueles que estiverem num nvel de maturidade/disciplina menor. 9) Scrum Master fazendo micro-gerenciamento, quebrando a sinergia e desmotivando a equipe Aqui a situao inversa. o Scrum Master que acredita ser o chefe da equipe, delega e controla as atividades no permitindo o time ser auto-organizado. aquele cara que prega as atividades no Kanban e sai colocando os nomes dos responsveis pelas tarefas. aquele cara que todo dia usa o Daily Scrum como reunio de reporte e querendo saber o detalhe de tudo o que est no Kanban. 10) Time Scrum (Product Owner, Scrum Master e Time de Desenvolvimento) no trabalhando com o conceito de time unificado (Whole Team) O famoso Eu ganhei, ns empatamos e vocs perderam. Gasta-se mais tempo se preparando para se isentar de possveis fracassos e menos tempo na interatividade que um time de alto nvel deveria ter. No Scrum acertam todos juntos, erram todos juntos e nas retrospectivas das Sprints o time sempre ter a oportunidade de refletir sobre o que deve ser mudado e melhorado para atingirem um alto nvel de coeso.