Falhas em projetos é culpa da Cultura e não da Metodologia

Bom, estava pensando ontem durante o curso de certificação de Scrum, o maior problema da falha na construção de SW são as pessoas e não a metodologia em sí.
Pensem da seguinte forma:
Cascata, todos sabem que esse tipo de projeto não dá muito certo, ainda mais no esquema de escopo fechado, isso porque em todo o ciclo de vida do projeto as prioridades, os requisitos e o conhecimento seja ele por parte do fornecedor ou do cliente mudam, melhoram e o sistema tende a mudar.
Vendo as metodologias ágeis (Não estou apenas falando de SCRUM, não importa se é Scrum, XP, FDD, Crystal e etc...), quando falo metodologias ágeis quero dizer o Manifesto Ágil em si.
O que nos diz o manifesto ágil?

• Indivíduos e interação entre eles mais que processos e ferramentas;
• Software em funcionamento mais que documentação abrangente;
• Colaboração com o cliente mais que negociação de contratos;
• Responder a mudanças mais que seguir um plano.

Ou seja, mesmo havendo valor nos itens à direita, valorizamos mais os itens à esquerda.

Fonte: Improve IT

Sinceramente vejo que muitas empresas, seja elas de pequeno, médio e grande porte dão muito mais valor as ferramentas e processos do que as pessoas.
Tanto que normalmente quem trabalha (principalmente em fábrica) é um "recurso", um Code Monkey que pode ser descartado a qualquer momento e substituído por outro.
E isso é um erro, pessoas são importantes, quando você deixa de motivar as pessoas de sua equipe elas tendem a sair, ou seja, não é só dinheiro que tira um cara bom do projeto e sim o ambiente no qual ele está instalado (Não estou dizendo nada sobre trabalhar de graça, dinheiro não importa e etc), se o cara é motivado de qualquer forma, ele sente que tem participação e importancia naquele determinado projeto o funcionário tende a estar mais motivado, produzir mais, estudar mais, porém, se a cultura da empresa preza que o cara é apenas um "recurso humano" e deixa ele meio que de canto (típico: "Vai fazendo aí"), o cara deixa a produção quase no zero, não quer saber de nada e provávelmente se ver outra oportunidade ele vai embora da empresa, isso é fato.
Nesses meus 5 ano de experiência tive diversos gerentes de projetos, daqueles mais arrogantes aos mais humildes, pessoas que trabalharia de novo e pessoas que nunca mais gostaria de ver na vida, pensando porque grande parte dos gerentes de projetos tendem a ficar assim:

1 - O gerente normalmente tem pouca ou nenhuma experiência e está sozinho;
2 - Comando-Controle, ele quer controlar tudo que alguém vai fazer;
3 - Status, o gerente está no topo da cadeia e todo mundo abaixo é serviçal.

E o que as metodologias ágeis vão me ajudar em uma cultura assim?
Provavelmente se ninguém mudar, não vai ajudar nada, na verdade a forma de melhorar um ambiente assim é começar mudando a forma como as pessoas pensam, isto é, o Cliente tem que estar 100% envolvido no projeto (não tem desculpas do tipo, ahhh ele está acostumado a fazer o levantamento junto ao analista de requisito e depois ele vai embora e só volta depois de 1 ano para ver o que aconteceu), a equipe não pode ficar tendo conflitos internos como acontece no modelo Cascata, como assim? vou mostrar o modelo cascata e dizer como ocorre esses conflitos:


Você tem a fase de Requisitos do sistema, requisitos de SW, design, Programação, Testes e Manutenção.
Normalmente o Analista de Requisitos de SW não gosta do Analista de Requisitos do Sistema porque ele faz a análise "Errada", o Design não gosta do Analista de Requisito de SW porque não era "necessário" para montar as telas do Sistema, o Programador não gosta do Design porque as telas são complexas e coloridas, o programador também odeia os Testers porque eles acham falhas, os Testers detestam os programadores porque não fazem certo e TODOS odeiam o Cliente que é o cara que está pagando.
Este exemplo eu vi com o Alexandre Magno e é a mais pura verdade, todos estão separados, assim que chega para o programador é como se a parte acima estivesse pronta e o projeto "terminado" e não é bem assim.

As metodologias ágeis forçam as pessoas a cooperar, o "Status" (Entendam Status como: Gerente, Coordenador, Arquiteto e etc) morre, o que existe é o Time, o time é responsável por fazer aqui andar, o time tem responsabilidades e o principal não é uma pessoa que vai ser cobrada, é o time todo, a idéia de individualidade deve desaparecer, o ScrumMaster não é necessáriamente um cara tecnico ou um Gerente de Projetos, o ScrumMaster é um cara que vai facilitar a vida do time e forçar que o time cumpra o que o Scrum diz, o Cliente tem que estar envolvido, seja de forma direta como de corpo presente, seja por um representante, o Cliente ou a pessoa que irá representá-lo no caso do Scrum em particular é o Product Owner (PO), o ScrumMaster não é o cara que a todo momento sozinho conversa com o PO, o time participa, o time faz as reuniões junto e o time aprende a ser auto-organizado, ou seja, o time se sente parte do projeto, o time evolui e o time sabe se organizar.
Muitas pessoas afirmam que isso não funciona, o famoso: "No meu projeto não se aplica", isso porque "dói" você mexer na zona de conforto, "dói" dizer que você não tem mais um poder soberano e só você manda, "dói" dizer que o time também decide o que vai dar para entrar em um Sprint ou não e principalmente "dói" mostrar ao cliente que ele não vai poder mexer em um Sprint em andamento, que pode cancelar um Sprint, se e somente se, o Sprint estiver comprometido com a mudança, ou seja, sair da zona de conforto é algo que dói e o pessoal acha comodo trabalhar em um modelo que o cliente não muda requisito porque tem uma multa gigante caso ele o faça, coloca uma gordura enorme no ciclo de desenvolvimento e o time além de desmotivado, transforma o projeto em um laboratório de pesquisa (Ou seja, testa tudo que há de novo no mundo da tecnologia que ele utiliza, mesmo que seja ultra-alpha 0.1.1_01) e muitos acabam como o próprio Alexandre diz, na famosa Síndrome do Estudante, vai deixando pra depois porque o tempo é grande e na última semana vara a madrugada fazendo porque foi deixando pra lá.
O fato é que qualquer metodologia ágil funciona SIM, desde que você Scrum Master treine o pessoal, ensine, mostre as vantagens, para o cliente, mostre quanto ele está gastando no modelo de escopo fechado com a gordura que você vai precisar colocar, mostre para ele que não vai poder ter mudanças pois não é algo previsto, mostre que levantar um sistema todo no começo provavelmente não dará certo.
Para a equipe, mostre para eles as vantagens de ser comprometidos com o projeto além do PO e do Scrum Master, mostre que eles fazem parte do corpo do projeto e que são importantes, não mais recursos, mas membros que fazem o projeto andar.
E Scrum Master cuidado para nunca cair no Comando-Controle, você não manda, você mostra, você opina, você tira dúvidas com o time e com o PO e você FACILITA a vida do time e não dá ordem para eles.
Mostre que o PO e o Time tem que estar comprometidos, que eles são toda a essência e importância do projeto e é claro, você já sabe que no papel de Scrum Master, você também tem que ter foco e estar comprometido.
Resumindo: Ouço muito o pessoal achando que Agile é apenas uma Buzz Word, uma modinha que não dará certo e que depois de um tempo você simplesmente esquece, bom, isso não é verdade, se você usa um Scrumbut, ou seja, tudo o que você acha legal, e o que "dói" você não pratica, realmente seu projeto e prazo vão estourar e realmente a metodologia não vai funcionar e é mesmo culpa dela? É duro sair da zona de conforto, mas os resultados serão totalmente positivos.