A resposta é simples e você já conhece, mas vou usar um slide com alguns números para exemplificar.
No post Scrum, o primeiro contato! apresentei superficialmente o que entendo ser a maior diferença entre um projeto tradicional e um projeto Ágil, Scrum, Lean ou seja lá como você queira tratar ele.
A pequena diferença em textos na verdade é uma grande diferença quando levamos este assunto para o aspecto cultural.
Participei de um webinar da Scrumdotorg que foi apresentado pelo rjocham – dois bons perfis para se seguir no Twitter.
Em um dos slides Ralph Jocham mostrou o resultado de uma pesquisa do “porque a implementação de Ágil falha” e 5 das 7 maiores causas estão ligadas, de alguma forma, à mudança cultural da empresa.
O principal motivo é: 46% dos projetos falham pois a filosofia/cultura da empresa está em desacordo com os valores ágeis.
Os outros 4 dentro dos TOP 7 são desdobramentos destes.
– 38% são causados por falta de suporte gerencial.
– 38% são causados por falta de suporte à mudança cultural.
– 36% são causados por pressão para que o modelo de projeto tradicional (waterfall) seja seguido.
– 34% falta de colaboração efetiva dos gestores.
Levando em consideração os dados apresentandos e tendo a consciência o quanto nós, seres humanos, somos resistentes a mudança não fica muito difícil entender o motivo de grande parte das falhas.
Tentando explicar usando a dita “sabedoria popular”: Uma andorinha só não faz verão.
No post Visão geral do Product Owner utilizando Metodologia Ágil, uma das frases do vídeo que trago para apresentar este assunto, em tradução livre, diz:
“Se sua organização não gosta de verdade e honestidade provavelmente ela não gostará de metodologia ágil.”
Resumindo: Segundo o resultado desta pesquisa, grande parte dos projetos ágeis falham por falta de comprometimento e/ou suporte dos executivos da empresa para mudar sua cultura.
Por fim, deixo o slide original, o vídeo e o link para acessar o Webinar no Scrum.org.
Slide original:
Nesse texto você expõe números que apontam uma série de justificativas que poderiam ser o problema, para mim o principal desafio em um ciclo ágil de trabalho é gerir o conhecimento entre todos os envolvidos, não somente durante o ciclo do projeto, mas em todo processo evolutivo da ferramenta.
Hoje, como analista de testes, uso o exemplo que muitos QAs precisam mensurar seus esforços sem ter o mínimo de artefatos de negócio, esperasse que os esforços sejam sempre levantados com base em esforço passado, conhecido como esforço de regressão, porém a mensuração de esforço é o menor dos problemas, e sim o desenvolvimento de regras – funcionais e não funcionais – ocorrendo de forma liberal, sem documentação ou formalidade, seja clássica ou não, mudanças de escopo – quebrando a metodologia – levando, assim, para problemas no final do ciclo no ambiente produtivo que acarretam em prejuízos financeiros altos, atritos entre profissionais, desvalorização do trabalho de T.I. pela empresa, imprecisão em dados gerenciais, entre outros problemas.
A codificação cowboy é utilizada em muitos lugares que possuem problemas com métodos ágeis e esse é um grande fator para os números acima, seria bacana se escreve sobre isso.
Obrigada pelo texto.