15 armadilhas comuns do Scrum - Site Campus

15 armadilhas comuns do Scrum

15 armadilhas comuns do Scrum

Scrum é um framework que pode lhe trazer muitos benefícios quando usada da maneira correta. Porém, algumas armadilhas comuns podem aparecer pelo caminho.

Scrum é muito viável para diversos tipos de projetos.

No entanto, é errado dizer que o Scrum é a solução perfeita para resolver todos os problemas que temos e ter sucesso em todos os projetos, sem nenhum tipo de impedimentos ou momentos críticos, como qualquer outra metodologia.

Se a equipe não estiver bem preparada para o que pode enfrentar quando utiliza Scrum em seus projetos, esses problemas podem trazer outros problemas consigo.

Usando outras palavras, Scrum pode trazer muitas armadilhas que impactam os resultados de nossos projetos e podem fazer todo a utilização do Scrum ir por água abaixo.

Vamos falar abaixo das 15 armadilhas mais comuns:

Excesso de planejamento inicial – A equipe Scrum deve iniciar um desenvolvimento imediato do projeto com as primeiras necessidades que foram identificadas pelo Product Owner e não fazendo longas e longas reuniões de planejamento para definir cada fase futura do projeto.

Focar nas ferramentas – Ferramentas não são importantes, pessoas e processos são. Lembra disso, né? Assim, não há necessidade de foco e preocupações nas ferramentas. Encontrar a ferramenta apropriada é apenas um obstáculo para começar logo, por isso, as equipes devem começar com o desenvolvimento de imediato.

Tentar resolver todos problemas na reunião diária – Daily Scrum não serve para debater todos os problemas entre os membros das equipes nem para encontrar soluções únicas para esses problemas. O foco dessas reuniões sempre deve estar bem definido para encontrar aquilo que está impedindo que o time de desenvolvimento avance. O Scrum Master, com seu papel de liderança, deve buscar planos de ações após as reuniões para remover esses impedimentos.

Muito tempo planejando e gerenciando os stakeholders – Scrum requer equipes com auto-organização para seu trabalho. Portanto, os papéis de liderança em um projeto Scrum não devem tentar gerenciar cada atividade de um membro da equipe de desenvolvimento ou ficar atribuindo atividades diferentes todo o tempo. Por outro lado (obviamente) espera-se que a equipe seja proativa e não fique esperando suas tarefas serem delegadas por alguém o tempo todo.

Scrum Master como um desenvolvedor do projeto – Scrum Master é uma função especializada no Scrum. Um Scrum Master é uma liderança facilitadora para que um projeto Scrum gere valor, ele não é um desenvolvedor ou um testador. Assim, não devem ser atribuídas funções técnicas ou de desenvolvimento para esse personagem.

Impor prazos e recursos – As equipes Scrum sabem melhor do que ninguém o que é necessário para completar uma determinada Sprint, por isso, ninguém deveria tentar impor prazos ou prescrever os recursos antes que eles mesmos possam colocar isso na mesa. A discussão disso é sempre bem vinda nesse caso, mas utilizar técnicas para isso é muito mais apropriado.

Distribuição errada do time – O Scrum funciona bem quando a equipe se comunica bem. Distribuir o time de forma complexa, deixando as pessoas longes para discutir o projeto pode decretar a morte de seu projeto. Comunicação é tudo e quando você pensa na composição do time Scrum, precisa pensar também na forma como ele irá se comportar junto.

Não integrar o Product Owner – A presença do Product Owner em reuniões diárias, de planejamento e retrospectivas é essencial, pois ele é a ponte entre a equipe técnica e as partes interessadas. Garantir que ele esteja próximo e com laços de confiança com a equipe de desenvolvimento faz as coisas fluírem muito mais rapidamente no projeto.

Empilhar trabalho – O Scrum segue o modelo iterativo e incremental de desenvolvimento, onde a equipe pré-decide o que fazer em cada Sprint conforme as prioridades do cliente. Com isso bem claro, nem a administração nem as partes interessadas devem tentar sobrecarregar a equipe do projeto com mais trabalho, pois isso irá resultar na diminuição da eficiência das entregas, ou ainda, menos entregas.

Individualidade acima do coletivo – A equipe Scrum trabalha em sintonia e afinada entre si. Logo, as pessoas não devem tentar trabalhar além de suas funções e nem mesmo sobrecarregar a si mesmo para “resolver sozinho”. Menos sempre é mais para gerar valor.

Falhar ao reiniciar Sprints – Embora o cancelamento de uma Sprint costuma ser raro, pode ser tentador tentar e esperar até que tudo esteja perfeito ou pronto antes de voltar ao trabalho normalmente. As equipes devem imediatamente voltar ao trabalho.

Comprometer a qualidade – A pressão para entregar cada vez mais pode comprometer a atenção que o time dá para a qualidade. É importante garantir que a forma como é organizado e conduzido o trabalho do projeto não irá impactar na entrega final ao cliente.

Product Owner especificando a solução – Os problemas surgem ao longo de um projeto e isso é normal. O Product Owner não deve tentar surgir como a resposta para todas as soluções, esperando que a equipe fará sempre tudo de seu jeito. A equipe Scrum já é formada pensando em pessoas que possam resolver os problemas que surgem de forma proativa e responsável.

Deixar de aprender – Scrum acredita no desenvolvimento constante e isso também requer aprendizagem constante por parte dos membros da equipe. A busca por conhecimento deve ser estimulada para garantir que a equipe sempre terá tudo o que é preciso para dar conta do projeto.

Mudar o time frequentemente – Uma equipe Scrum deve ser organizada e de alto desempenho para gerar valor. Mudar membros com frequência não só reduz a eficiência e produtividade, mas também desmotiva os membros da equipe que continuam no projeto.


 

Sobre o Autor

William Meller é fundador do Portal Sucesso Jovem, profissional de TI e projetos e voluntário no PMI.

Carreiras Site Campus


#
Compartilhe!
Fale com o Site Campus!

Tags: , , , ,