---

Superando a falta de compromisso, a gestão de mudanças e os desafios do trabalho em equipe! A resposta pode surpreender você!

A maior fraqueza dos modelos de melhoria de processos utilizados antes do Scrum era esta: Concentravam-se principalmente em demandas organizacionais que atendiam aos interesses da própria liderança.

Entre essas demandas estavam monitoramento, conformidade e previsibilidade. Não havia qualquer foco em atender bem aos clientes e melhorar o moral dos funcionários.

Assim, membros das equipes de gestão de software e diversas partes interessadas internas e externas buscavam estabelecer um prazo fixo de entrega e acompanhar facilmente o progresso das fases de engenharia de software.

Puniam as pessoas quando algo saía do planejado e esperavam resolver os problemas emergentes antes da data prevista de conclusão do projeto.

Além disso, áreas isoladas executavam fases completamente separadas da engenharia de software. Por exemplo, a equipe de desenvolvimento era totalmente independente da equipe de testes (verificação). A maioria das pessoas que deveriam trabalhar pela mesma missão empresarial nem sequer se conhecia pelo nome.

Você imagina por que nossas organizações tinham essa mentalidade de isolamento, em vez de se concentrarem na missão do negócio e na maturidade profissional dos funcionários?

A razão é simplesmente a gestão matricial . A gestão matricial é uma estrutura de gestão organizacional e de funcionários presente nas empresas desde a década de 1970. À primeira vista, a ideia que diferencia uma organização ou gestão matricial parece inteligente.

A liderança cria uma estrutura organizacional reunindo funcionários com competências funcionais e técnicas semelhantes na mesma área isolada ou, na melhor das hipóteses, em áreas vizinhas.

O modelo de entrega de projetos em Cascata numa organização matricial

Na época, era comum ver os chamados Centros de Competências nas empresas, cada um representando uma área independente e autônoma.

Uma área para desenvolvedores C++, outra para administradores de bancos de dados e outra área de garantia da qualidade completamente separada, em outro país, e assim por diante. Vai entender!

O maior desafio da estrutura matricial era este: para entregar um projeto de software sem o framework Scrum e sem Scrum Masters, os gerentes precisavam tomar funcionários emprestados temporariamente das áreas isoladas.

Esses funcionários nem sequer ficavam fisicamente junto às equipes de projeto: permaneciam nas salas de seus respectivos Centros de Competências.

Quando os projetos terminavam, essas equipes temporárias eram desfeitas e os participantes seguiam para novas atividades em outros projetos.

Por isso, o valor de negócio pretendido pelos projetos de software em andamento nunca era a prioridade máxima dessas áreas independentes.

Elas tendiam a enxergar o trabalho como itens a marcar numa lista, um para este projeto, outro para aquele.

A liderança e o modelo matricial não ensinavam como profissionais deveriam se comprometer com o negócio para melhorar os resultados, incluindo vendas, receita e lucro.

Um artigo da McKinsey & Company no McKinsey Quarterly também ilustrou claramente essa ilusão de otimização de custos associada à organização matricial .

A Gartner estimou que organizações de todo o mundo vinham, anualmente, gastando 600 bilhões de USD para recuperar seus sistemas de TI de trabalhos de manutenção não programados e defeitos.

Agora, vamos visualizar brevemente como aconteciam a gestão de mudanças e o tratamento de impedimentos nos projetos de software. Como ocorriam num projeto com o Modelo Cascata, numa organização matricial e sem o processo Scrum.

Sim. Você acertou.

Gestores e funcionários tratavam mudanças, impedimentos e erros como exceções indesejadas que nem deveriam ter acontecido.

Por isso, mudanças num projeto de software se tornavam sinônimo de atrasos. Em geral, criavam um efeito dominó de atrasos em cascata. As equipes procuravam alguém para culpar pelos defeitos e impedimentos.

Por fim, como as áreas isoladas não tinham um mecanismo para analisar, corrigir e aprender com os erros, continuavam repetindo os mesmos enganos.

Além disso, continuavam aumentando o volume de dívida técnica enquanto tentavam lidar passivamente com seus problemas.