Chega a ser engraçado em 2019 um cara que é PMP® há 10 anos e trabalha com times ágeis utilizando Scrum há 9 anos, escrever um artigo com este título. Mas mesmo que ninguém admita, fato é que PMBOK®, mesmo com seus PMPs, PMOs, softwares de gestão maravilhosos e toda a governança, não funcionou com projetos de software.

Pois é, “projetizamos” a TI, criamos inúmeros indicadores, novas funções, gestão de mudança complexa e ainda assim falhamos. Será que podemos dizer que “deu errado” mesmo com tantas empresas utilizando e milhões e milhões de projetos entregues neste modelo? Sim, podemos!

Não estou aqui para julgar ou menosprezar o trabalho de tanta gente boa no mundo, que fizeram e ainda fazem projetos neste modelo, mas o fato é que a gestão de projetos no Brasil virou um “me engana que eu gosto”. Em TODAS as grandes corporações que tive contato existiam METAS e indicadores claros que impactavam o dinheiro/bônus de todos em cima das entregas dos projetos. O que criamos? Um bando de gente perseguindo o farol verde no projeto. Ninguém preocupado com o consumidor final, tampouco com o software funcionando e gerando o ROI para qual este projeto foi concebido. Já dizia na Bíblia da Transformação em JB capitulo 4 versículo 8: “Diga-me como me medirás e eu te direi como trabalharei”.

E no cenário “finge que me engana e eu finjo que acredito” temos Gerentes de Projetos certificados que estudaram pra caramba e já sabem que não vão aplicar nem 15% do conhecimento de gestão de projetos na vida real. Este gerente de projetos também não é, e nunca foi empoderado por executivos. Também criamos o PMO que na essência é lindo, mas na prática virou auditoria de GP e assim segue o jogo corporativo.

Não pode estourar prazo, nem custo, nem escopo, mas para o farol ficar verde, com uma change request pode mudar tudo. Breaking News! “O projeto vai atrasar e não bateremos a META, depois de 1 ano de projeto só descobrimos isso há 1 semana da entrega”. Ok, já sabemos como lidar, sempre acontece isso, vamos lá, tomem nota: War-Room, força-tarefa, carteirada, “crachazada”, madrugada, final de semana, reunião de status diário, checkpoint 2 vezes por dia, deixa a família de lado, abaixa a cabeça, liga o GO HORSE::MODE INSANE e “vualá”, projeto “entregue” verde.

Alguém já viu esse cenário acima? Sabe o que vai para produção e consequentemente para a sustentação? Um lixo. Sabe o que se cria? Projeto pra “evoluir” o projeto (que na verdade é pra refazer). O mundo corporativo se enganou e ainda se engana neste modelo. Por que esse modelo não funciona? Posso elencar uma lista de motivos, mas vou fazer uma analogia de software com construção civil para falar de um dos principais motivos: “requisitos”.

Eu como prefeito gostaria de fazer um viaduto que passe por cima da rua A, ligando a rua B com a rua C, com isso eliminaremos o cruzamento e consequentemente melhoraremos o trânsito em 45% na região.

Claro que existem incertezas neste projeto, mas a grande maioria facilmente mitigável com todo conhecimento da engenharia civil moderna.

Perguntas:

Existe alguma possibilidade de no meio da construção do projeto, com meio viaduto construído:

• Alguém dizer que ele tem que virar para algum lado ao invés de ser um cruzamento que vai reto? Resposta: Não.
• Sair alguma norma de órgão regulador dizendo que o projeto agora tem que ser diferente, utilizando plástico ao invés de cimento? Resposta: Não.
• O seu concorrente, prefeito da cidade vizinha lançar um viaduto disruptivo e por isso você precisará fazer um APP para o seu viaduto e colocar uma roda gigante no topo dele para atender os habitantes? Resposta: Não.
• Frente as mudanças de mercado, eleição do Bolsonaro, aprovação da reforma da previdência, esse viaduto não fazer mais sentido e agora ter que mudar pra um túnel com trilhos para trem? Resposta: Não.

Se este viaduto fosse um software, TODAS estas respostas são ou poderiam ser SIM.

Isso só falando de requisitos, fora tantos outros fatores de insucesso de projetos, sendo o maior deles a comunicação. No gerenciamento de projetos o gerente de projetos faz estimativas, reporta, faz status e o time (se é que tem time) “só” executa. O time é induzido pela hierarquia a dar boa notícia, não existe franqueza nem transparência, todo mundo tem medo de dizer que vai atrasar, custar mais ou mudar. A comunicação, quando existe, não é real, nem franca. Mas.... Porém... Entretanto...

Chegou o salvador da pátria, a bala de prata! Metodologias ágeis... Framework Scrum... Agora vamos fazer o dobro na metade do tempo e vamos trocar o Project por Post-iT, Kanban e Jira.

Pessoal o Scrum não está funcionando na maioria das empresas assim como o modelo anterior não funcionava e exatamente pelos mesmos motivos. Scrum é fácil de entender e MUITO DIFÍCIL de implantar corretamente. As pessoas estão focando todas as energias em Kanban, post-it, reunião diária, fazer o GP virar Scrum Master e o Analista de Requisitos virar PO. Receita pronta do FRACASSO(se você fez isso ou está fazendo, ainda existe esperança de mudar).

Como você tem tanta certeza que o Scrum não vai funcionar JB?

Sabe o Scrum Guide que é “tipo” o “PMBOK do Scrum” (risos) com 17 páginas? Ótimo! Lá tem essa resposta, mas na parte que ninguém se preocupa, pois não é glamurosa, e vai de encontro diretamente com o que o Executivo e Gestor de TI menos sabe fazer, GESTÃO DE PESSOAS. Ali no comecinho do Scrum Guide tem os 3 pilares do Scrum e os valores do Scrum.

PILARES

Pilar é um elemento estrutural usado para sustentar e distribuir o peso. Ou seja, sem os pilares uma construção não se sustenta e o Scrum sem os pilares também não se sustenta.

Pilares do Scrum: Transparência, inspeção e adaptação.

Agora vou dar exemplos de que não existem os pilares do Scrum na vida real dos projetos no Brasil na maioria das grandes empresas:

Transparência – Você acredita que somos transparentes hoje nos nossos projetos? Estimamos a realidade? Acordamos a realidade? Comunicamos a realidade? Reportamos em todas as esferas a realidade? Todo mundo sabe e pode saber o que está acontecendo nos nossos projetos? Não, tudo na base do corporativismo e mentiras.

Inspeção – O trabalho sendo desenvolvido é inspecionado diariamente em todas as etapas como em uma linha de produção? Não! Somente depois que acaba o desenvolvimento existe um time que testa sem muita referência e aí surge a frase maravilhosa TA PRONTO, só falta testar. E o tempo de teste cai de 10 dias pra 10 horas e a qualidade é ignorada para atingir o farol verde.

Adaptação – Change request, comitê, aditivo contratual, e-mail, formalização, chancela do presidente, de acordo do papa, formalização de 5 diretorias, tudo em 3 vias autenticadas no cartório, pronto, agora pode mudar o requisito. Custo real da mudança R$ 5.000,00 custo do processo de gestão de mudança R$ 35.000,00.

VALORES

Em ética, valor denota o grau de importância de alguma coisa ou ação, com o objetivo de determinar quais são as melhores ações a serem tomadas ou qual a melhor maneira de viver (ética normativa), ou para determinar a importância de diferentes ações. https://pt.wikipedia.org/wiki/Valor_(%C3%A9tica)

Valores do Scrum: Coragem, Foco, Comprometimento, Respeito e Abertura/Franqueza (a tradução que você preferir para Openness).

Ou seja, antes de tomar alguma ação você precisa analisar se esta ação fere algum valor e sempre tomar decisões baseada nos valores. Isso vale para pessoas, culturas, empresas e para o Scrum.

Agora vou dar exemplos de que não existem os valores do Scrum na vida real dos projetos no Brasil na maioria das grandes empresas:

Coragem – Todo mundo sabe que não dá, mas ninguém tem coragem de dizer. Quando acontece o obvio, problemas, aí começa a caça às bruxas (quem é o culpado?), war-room, go horse e vocês já sabem o final da história.

Foco – O mesmo time que está “dedicado full-time” em um projeto também atende outros 5 projetos, sustentação e reuniões de novos projetos.

Comprometimento – Não existe compromisso com uma data que o time não deu, de um requisito que o time não entende, custando algo que o time não concorda.

Respeito – Nesse quesito até onde eu vivi consegui ter o mínimo, único desrespeito é passar projeto pra sustentação sabendo que está passando uma bomba. Costumo chamar isso de tráfico de drogas rs..rs..

Abertura/Franqueza – Se você falar a verdade será visto como o pessimista, não veste a camisa, desmotivado.

Ou seja, não fazemos o básico, vivemos na gestão do medo, baseamos tudo na mentira, todo mundo sabe que é mentira, mas não tem coragem de dizer a verdade, principalmente para gestores e executivos.

Já viram ou ouviram falar de uma área de TI que sem base nenhuma pra pedir orçamento do ano faz “estimativas de grau zero” (nome bonito para “um chute pessimista com 100% de gordura”). Após isso, quando chega perto do último quarter e não gastou todo orçamento, aí faz uma “força tarefa de gastos” pra conseguir realizar o orçamento para não ter menos orçamento no ano seguinte? (eu já ouvi falar uma vez, acho que foi em Londres, uma lenda sobre isso).

A transformação organizacional só vai acontecer se formos justos e sinceros. Temos que aprender a desenvolver, testar, errar e mudar (PDCA?). Temos que aprender a aceitar o erro, aprender com ele e mudar rápido. Enquanto não aceitarmos o erro e medirmos os times por farol verde ele sempre será verde, mesmo que seja mentira.

Antes de pensar em times ágeis, escalar o Scrum, pense e reflita sinceramente se vocês já conseguem hoje ter os pilares e valores do Scrum na essência na sua empresa.

Sim?

Então ficou mais fácil, agora só falta:

• Desburocratizar;
• Deshierarquizar a empresa dando poder para o time;
• TREINAR o time todo em Scrum (se possível certificar com CSM e CSPO);
• Engajar o “C-Level” da empresa;
• Fazer um planejamento organizacional com o RH.

Vale ressaltar que lugares que já possuem os pilares e valores do Scrum na cultura da empresa (como muitas startups onde o CEO é parte do time que executa), se você usar qualquer método, processo ou framework terá resultados incríveis, não apenas com o Scrum. No fim do dia estamos falando de gente e poucas pessoas entenderam isso.