12 Sinais de Riscos em Projeto Scrum

Riscos em Projeto Scrum

Você por acaso já parou para pensar numa série de riscos que seu projeto está correndo e que as vezes, levado pela correnteza das rotinas diárias você nem se dá conta?

Umas das poucas coisas que podemos ter certeza em um projeto é que estamos correndo diversos riscos que podem levar o projeto ao fracasso e, algumas vezes, quando o problema acontece, é tarde demais para conseguirmos contornar a situação.

Com base em experiências passadas, eu compilei 12 sinais de riscos em projeto scrum que podem indicar que o projeto pode fracassar.

Fique atento aos seguintes sinais:

1 - O Product Owner Não tem o Poder para Tomar as decisões

O Product Owner PRECISA estar engajado e com poderes necessários para sua tomada de decisão!

Caso o Product Owner não tenha a autoridade necessária para tomar as decisões que serão necessárias durante o projeto, o risco de re-trabalho é muito grande, pois a responsabilidade da priorização do Backlog (o que norteia todo o trabalho do time Scrum) é dele. Se ele não tiver autoridade na empresa para tal, no momento que o resultado do sprint ou release for apresentado para a pessoas que realmente tem esta autoridade, esta pessoa pode solicitar alterações e re-priorizacões sem fim.

Sem isso, não tem jeito de avançar.

2 - Product Owner NÃO sabe exercer sua função!

Como mencionei no risco 1, é muito importante que o Product Owner seja alguém com autoridade e liberdade de decisão na empresa, porém, quase na mesma proporção de importância é necessário que ele saiba exercer este papel.

O Product Owner que for designado PRECISA receber treinamento nos processo ágeis e como o Scrum funciona!

3 - Alocação do Time não está otimizada para o Sucesso!

É muito importante que o time do projeto tenha uma alocação balanceada de recursos.

De nada adianta você ter uma equipe multi-disciplinar (pessoas com habilidades complementares, conhecimentos diferentes entre si e que se complementam) se todos forem muito inexperientes (Juniores).

Também de nada adianta ter uma equipe toda composta por profissionais altamente experientes (Seniores), se este não possuem os conhecimentos específicos necessários para a total execução do projeto.

O ideal que a equipe seja multi-disciplinar e tenha uma balanceamento de maturidade necessária para conseguir obter o máximo de eficiência  no desenvolvimento.

4 - Estimativas do Projeto NÃO foram providas pelo time do Projeto

Eu vejo muitos projetos Scrum falharem neste ponto.

É comum ver as estimativas sendo feitas por uma equipe que não é a mesma que vai desenvolver o projeto (muito comum isso acontecer em "Fábricas de Software").

O correto é que o time atual seja totalmente envolvido durante o processo de coleta de requisitos e faça-os revisar as estimativas usando alguma métrica como Story Points, UCP ou até APF.

5- Relase Planning Inexistente

É por conta deste tipo de atitude que o pessoal do gerenciamento tradicional acaba tendo razão sobre alguns aspectos que acabam acontecendo no gerenciamento ágil.

Gestão Ágil NÃO significa que não deve haver planejamento algum. O planejamento do Release é muito importante para o correto alinhamento dos objetivos finais do projeto com os objetivos de entrega de cada Sprint.

  • Evite o jargão “Vamos direto, confie em mim”
  • Eduque seu time a fazer o Release Planning e até a Iteração 0
  • Contacte todo mundo que for preciso, DBA, Infra etc

6 - Testers incluídos só no final do projeto

Isso é muito acontecer com pessoas que recém migraram do gerenciamento tradicional para o gerenciamento ágil. No gerenciamento tradicional, cascata, é comum que todo o desenvolvimento seja feito primeiro e, então, entre em uma fase de testes.

Esta prática pode ser mortal para um projeto ágil.

  • Os Testers são a chave para o sucesso, inclua-os desde o Release Planning
  • Inclua testes em cada Iteração. Sim, precisa!

7 - O Gerenciamento como Impedimento: Deveria ser o contrário, certo?

A gerência deve se concentrar em remover impedimentos, corrigir problemas de alocação de equipe, otimização de papéis e melhorar as habilidades da equipe, fornecendo ferramentas e treinamentos adequados.

O Scrum Master deve ter toda a autoridade necessária para poder desempenhar o papel de facilitador do time, removendo estes impedimentos. Se o Scrum Master não tiver esta autoridade junto a gerência da empresa, isso pode se tornar um problema enorme.

8 - SCRUM MASTER preocupado apenas com Status Report para o chefe e não para o time

O time scrum é o coração do projeto. É o principal músculo vital do projeto ágil e este não deve ser deixado à deriva. O time deve estar totalmente alinhado com o andamento do projeto, impedimentos e todas as informações pertinentes em relação ao desenvolvimento do mesmo.

Por isso é muito importante que todos participem das Daily Scrum, que o Scrum Master ganhe a confiança do time e então reporte o status para o chefe!

9 - Código de Má Qualidade começam a Imergir!

Quando isso começa a acontecer é sinal de que algo está errado. É um importante sinal de alerta para você rever os processo de qualidade do time:

  • Eduque o time a utilizar técnicas de qualidade como TDD, Integração Contínua, Daily Check-ins e Design Patterns.
  • Diminua o Débito Técnico através de Code Review

10 - Equipe Desorganizada

Você deve saber que a base do SCRUM é a Auto-Organização do Time.

Então faça isso funcionar!

Uma das principais dicas que posso dar para isso é rodar as Retrospectivas junto com todos da equipe. Isso deixa todo mundo alinhado com os acontecimentos, com a lições aprendidas e todos ganham em maturidade. a Auto-Organização só é possível com maturidade.

11 - Falta de Visibilidade do Progresso e dos Impedimentos!

Isso é parecido com o risco número 8, porém aqui é pior. No risco 8 o problema quando o Scrum Master só reporta o progresso e impedimentos para o seu chefe. Este sinal de alerta, é quando não está sendo mostrado para ninguém.

  • Quebre o Trabalho em pequenas iterações
  • Rode as Daily Scrums TODO DIA
  • Tenha um Definition of Done claro e conciso

E o mais importante: DEIXE VISÍVEL A TODOS!

12 - Falta de Priorização Adequada do Product Backlog

O Product Backlog é o mapa que a equipe deve seguir, é por onde todo o trabalho é direcionado.

Se apontar para a direção errada, todos vão para o lado errado. A correta periodização é FUNDAMENTAL!

  • O Product Owner precisa estar sempre olhando para o próximo passo do projeto
  • O Product Owner precisa revisar o progresso em cada iteração.

Fique atento a estes sinais em seu projeto.

São problemas comuns em empresas que recém adotaram Scrum, ou que estão começando a adotar metodologias Ágeis. Qualquer um destes sinais podem indicar que seu projeto está correndo sérios riscos.

Uma recomendação que faço é que, se possível, sempre que estiver prestes a iniciar um projeto Scrum, imprima e cole em algum lugar visível estes 12 riscos, de modo que possa monitorar estes sinais e corrigir tês que o pior aconteça.

Para facilitar a impressão, você pode fazer o download do infográfico dos 12 Sinais de Perigo clicando aqui.

Espero que este artigo seja útil e salve muitos projetos em perigo 🙂

Se gostou deixe seu comentário abaixo.

Seja Ágil!

arrow