Scrum: 10 situações de quando ele poderá (e certamente irá) fracassar

O Scrum é uma poderosíssima ferramenta para execução de projetos, mas, se falhar no equilíbrio “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 visão ou as fronteiras da visão do produto, gerando Sprints intermináveis 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 execução. Mas ele não consegue estabelecer prazo”. Eu disse a ele que o problema era que nossos usuários-chave não conseguiam responder a uma pergunta básica: “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 interminável – o que por si só já soa incoerente, pois projeto é um esforço temporário para a construção de um produto ou serviço.

Não caia na cilada de muitos agilistas que dizem que projeto ágil não tem estimativa de prazo e nem cronograma. No mundo Agile existe uma série de técnicas e artefatos que permitem prover este tipo de informação (recomendo fortemente leituras dos autores Mike Cohn e Ken Schwaber).

dez-situacoes-projetos-scrum-fracasso

2) Focar no que não 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 são feitas simplesmente não me importam muito e acabam não resolvendo meu problema”.

Respondi sobre a palavra-chave do que a Sprint deve produzir: VALOR. Não adianta pegar um projeto e fracionar em 10 Sprints, sendo que a maior parte delas não agrega valor ao produto e apenas nas últimas é possível 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 princípios do Manifesto Ágil é que indivíduos e interações devam prevalecer sobre processos e ferramentas, não faz nenhum sentido ter um Product Owner que não se comunica com o Time.

Se não há sinergia, sintonia e o conceito de “Whole Team”, o fracasso é certo!

4) Interferências externas ou mesmo do Product Owner impondo o que deve caber ou não 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 negociação são belas artes do Scrum. Se os integrantes do Time Scrum não tiverem domínio destas artes ou não tiverem força para brecar ruídos 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 não.

Negociação é uma arte do Scrum, mas negociar qualidade é PROIBIDO !
Se o tempo realmente é uma restrição, foque sempre numa entrega de VALOR e QUALIDADE

6) Sprints curtas demais obrigando o Time Scrum trabalhar em ritmos insustentáveis

Outro caso de comprometimento da qualidade e violação dos valores do Manifesto Ágil. Fazer horas-extras pode até ser bom e produtivo no primeiro dia. Mas depois fatores fisiológicos (cansaço, sono acumulado) e psicológicos (saudades do pai, da mãe, do namorado, da namorada, do cachorro, do jogo da TV) diminuem o rendimento, consequentemente podendo comprometer a qualidade.

Tente encontrar a duração ideal da Sprint, onde o time trabalhe em ritmo sustentável e entregue valor.

7) Time de desenvolvimento sem maturidade ou experiência para se auto-organizar

Neste caso, mais do que nunca, é necessário 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-organização torna-se caos

Muito manjado que o Scrum Master é um líder que serve o time – não chefia, não micro-gerencia – mentora e remove impedimentos. Mas não se deixe simplesmente ficar sentado passivamente assistindo tudo acontecer.

Não chefiar não significa não monitorar, não 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 nível, mentore com a ajuda do time aqueles que estiverem num nível de maturidade/disciplina menor.

9) Scrum Master fazendo micro-gerenciamento, quebrando a sinergia e desmotivando a equipe

Aqui é a situação inversa. É o Scrum Master que acredita ser o chefe da equipe, delega e controla as atividades não permitindo o time ser auto-organizado.

É aquele cara que prega as atividades no Kanban e sai colocando os nomes dos responsáveis pelas tarefas.
É aquele cara que todo dia usa o Daily Scrum como reunião 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) não trabalhando com o conceito de time unificado (“Whole Team”)

O famoso “Eu ganhei, nós empatamos e vocês perderam”.

Gasta-se mais tempo se preparando para se isentar de possíveis fracassos e menos tempo na interatividade que um time de alto nível 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 nível de coesão.

Abraços e até a próxima !

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"


7 Comentários

Robson
1

Acho que você pode mudar o nome da matéria para: “Desenvolvimento de Software: 10 situações de quando ele poderá (e certamente irá) fracassar”… Todos esses problemas rodando qualquer outra metodologia iriam acontecer! 😀

Cilas
2

Vou incluir mais um:
11) Não aproveitar as reuniões de retrospectiva para melhorar o processo vigente! É natural querermos evitar conflito, mas também é muito desmotivante trabalhar sabendo que o processo atual da empresa drena boa parte da agilidade (+valor +qualidade +produtividade) que o Scrum implanta. Então é importante usar todas as estratégias possíveis para tentar levar a agilidade para além do time Scrum.

Vitor Massari
3

Olá Robson,
Sim. É fato que esses problemas são comuns em outras metodologias.
Foquei no Scrum, pois muitos agilistas o vendem como a solução de todos os problemas e, de fato, isso não é verdade !
Abraços,
Vitor

Vitor Massari
4

Olá Cilas,
Ótima colocação.
Executar a retrospectiva apenas como uma formalidade e não aproveitar as lições aprendidas para a melhoria contínua do processo é um verdadeiro desperdício !
Abraços,
Vitor

Carlos Bridi
5

Olá Vitor,
Primeiramente parabéns pela publicação, realmente, esclarecedora e abrirá os “olhos” de muitos que não vêem aonde erram no Scrum.
Gostaria de questionar, estou fazendo um TCC e farei uma comparação simples com o Scrum e o modelo Waterfall para ver qual melhor se aplica no gerenciamento de projetos. Sua publicação irpa me auxiliar na parte de listar algumas desvantagens e atenções que devem se manter, questiono: Foi embasado em algum artigo cientifico ou até mesmo revistas a publicação, ou vivesse isso em campo ?
Abraços

André Luis Celestino
6

Olá, Vitor.
O artigo ficou muito bom, parabéns.
Só queria comentar sobre dois itens abordados no texto. O item três, no qual fala sobre o distanciamento do Product Owner, realmente ocorre em algumas ocasiões, como no Desenvolvimento Ágil em escala. Um mesmo Product Owner não poderá atender múltiplas equipes ágeis pela falta de tempo, disponibilidade ou deslocamento. Neste caso, o distanciamento é natural, desde que haja estratégias para manter a comunicação e a disseminação de informação sempre constantes.
A respeito do item quatro, só gostaria de complementar que as interferências ou imposições podem (ou devem) ser evitadas na cerimônia do Sprint Planning. Nessa reunião, o time de desenvolvimento pode prover estimativas, feedbacks e restrições na Sprint de forma que os equívocos de prazo ou recursos sejam minimizados.
Abraço!

F. Souza
7

Estranho quando alguém compara os processos ágeis unicamente com o cascata… Quer dizer que antes dos processos “ágeis” só existia esse processo? Por que não se fala de processos iterativos como o RUP ou UP, por exemplo, para se comparar também??? Esses processo também têm pontos fortes e são muito bons em certas situações, podendo serem utilizados em conjunto com processos ágeis…

Deixe seu comentário

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