Há cerca de 1 semana postei no LinkedIn meu artigo Ágil. Porque tantas tentativas falham? e tive a honra de ter este post compartilhado por uma amiga e grande profissional da área de Testes de Software.
Em seu compartilhamento – que pode ser acessado por aqui – ela fez 5 questionamentos a respeito de outros pontos que, certamente fazem com que projetos ágeis falhem. Além disso ela pontuou graves consequências que tentativas mal executadas podem trazer.
Separei os questionamentos em tópicos e agrupei-os de forma a tentar expor de forma adequada tomando por base o framework Scrum.
Ao começar a escrever percebi que este post ficaria muito grande então decidi criar o que chamei de “artigo expandido”.
Tratei os 5 questionamentos em outros 2 posts e coloquei a referência para eles aqui. Assim você pode ler somente a parte que mais lhe interessa, mas o ideal é que tudo seja lido para um melhor entendimento da conclusão deste post.
Aqui: Scrum. Gestão do Conhecimento e Mudanças de Escopo, tratei dos 2 pontos abaixo:
- Gestão do conhecimento durante o ciclo do projeto e no processo evolutivo.
- Mudanças de escopo.
Aqui: Ágil. Um pouco sobre documentação de regras, testes e comunicação escrevi sobre:
- Documentação das regras.
- Como mensurar testes.
- Atritos entre profissionais.
Juntando tudo e falando das consequências.
Como é possível ver nos posts em que tratei os tópicos acima, existem muitas questões – que algumas tratei superficialmente e outras nem sequer mencionei – para que o modelo Scrum seja implementado com sucesso.
É necessário interesse de todos os envolvidos, não só em mudar a cultura da empresa, mas também em querer entender/estudar o Scrum como framework.
É imprescindível ter um “Dono do Scrum” na empresa. Esta pessoa é responsável por ler, estudar, explicar, ajudar, guiar e fazer o que for necessário para que o Scrum seja absorvido por todos. Esta pessoa é o tal “Scrum Master”.
Sem o entendimento dos papéis e responsabilidades de cada um, certamente o que acaba sendo implementado é um modelo que não estará, nem de longe, seguindo algum tipo de metodologia ágil, tampouco o Scrum.
Neste momento certamente acabamos entrando na Codificação “cowboy”, ou GoHorse. Em um ambiente que não faz qualquer gestão do conhecimento, que não tem a menor idéia de qual é o “escopo” (visão do produto). Que não tem ninguém oficialmente responsável pelo produto, que não faz documentação de regras e com isso, não é possível ter estimativas confiáveis.
Neste percurso, certamente surgirão muitos atritos entre os profissionais e pra finalizar este ciclo, certamente chegaremos a um estágio que teremos total imprecisão de dados gerenciais, altos prejuízos financeiros e como consequência de todo este conjunto, haverá a total desvalorização do trabalho de T.I.
Para encerrar:
No artigo “Metodologia Ágil. Porque tantas tentativas falham?” pontuei 5 dos 7 motivos mais comuns, segundo a pesquisa, que levam às falhas em projetos ágeis. Neste aqui tratei os 2 que faltavam para completar o “Top 7”. São eles:
- 46% dos projetos falham por falta de experiência com métodos ágeis.
- 38% dos projetos falham por práticas e processos ágeis inconsistentes.
Mas vou adicionar outros 3 motivos que estão na pesquisa e que entendo termos discutido durante este “artigo expandido”.
São eles:
- 30% problemas de comunicação.
- 30% falta de disposição do time para seguir o framework.
- 25% colaboração inefetiva.
Com isso discutimos 10 dos 13 motivos presentes na pesquisa. Nada mal heim? 🙂
Um resumo deste “artigo expandido” é que:
A falta de conhecimento e/ou de interesse no entendimento do framework ou na sua implementação também podem trazer consequências graves para as empresas.
Slide que mostra o resultado da pesquisa citada:
