1. Achar que vai ser um passeio no parque
Achar que mudar para a agilidade será tranquilo é um erro enorme. Exigirá investimento financeiro, envolvimento de gestores e participação de colaboradores. Além disso, esteja ciente de que, embora a agilidade “salve” muitas pessoas desestimuladas, há algumas almas penadas que ficarão pelo caminho.
2. Falta de investimento
Não existe transformação gratuita. Você precisará investir em treinamentos, na aquisição de equipamentos e de software (licenças), em consultorias e na contratação de pessoas. Logo, achar que tudo pode ser feito no formato 0800 e boa-vontade é um erro gigantesco.
3. Luta pelo poder
Mudanças organizacionais resultam em alterações de poder. Exinguem-se unidades de negócios; outras são modificadas. É muito comum que o chamado “middle management” (média-gestão) atue como um sistema imunológico, lutando para remover a novidade do sistema e mantê-lo estável, sem mudanças.
4. Processo de construção extremamente particionado
– Vamos construir uma nova funcionalidade no software?
– Sim
O time de User eXperience (Experiência do Usuário) criará a tela; em seguida, enviará ao time de front-end e de back-end. Eles devem solicitar os dados ao time do barramento e este, por sua vez, deve solicitar ao time de banco de dados as mudanças necessárias. Uma vez que tudo estiver pronto, o time de segurança deve avaliar e aprovar e entregar ao time de infraestrutura.
Parece brincadeira, mas é verdade. Nas andanças com a Nower / K21, nós esbarramos em um time que tinha exatamente essa configuração e essa quantidade de dependências externas. Levou exatamente 2 semanas completas para colocar 1 banner no site.
Nessas horas, não há milagre; se o excesso de dependências externas (times que dependem de outros times) for mantido, não há método ou forma de trabalho que se sustente. Nesse ponto, precisaremos de muito apoio da alta administração.
Dica: Apresente métricas como o customer lead time, mas o mais importante disso, apresente o quanto a empresa deixa de ganhar ou está perdendo pelo altíssimo lead time que leva para entregar qualquer coisa.
5. Fragile ou Agilidade só na fachada
Infelizmente, é muito comum nós esbarrarmos na agilidade de fachada. O Departamento de Sistemas Corporativos muda seu nome para Squad Madrid; o gerente de projeto torna-se o Product Owner por meio de um dê-para simples. A Sprint 1 é a sprint de requisitos; a Sprint 2 é de design… Tudo tem um nome novo, mas fazemos tudo da mesma forma que antigamente.
Lembre da dica para o Rosenildo:
https://youtube.com/shorts/41mmZ7hetis?si=igFNzZfGBIlkvxhe
Uma organização, time ou processo é fragile quando:
- Quebra diante de mudanças de prioridade, tecnologia ou mercado
- Continuamos a fazer como antes, porém com novos nomes
- Depende de pessoas específicas (heróis)
- Responde a problemas com mais controle, regras e burocracia
- Lideranças que apoiam no discurso, mas não na prática
6. Métricas tradicionais para avaliar a agilidade
Enquanto consultor, algumas empresas são mais fáceis de trabalhar e, em outras, o desafio de trazer agilidade é maior. Eu estava em uma que era literalmente um mar de almirante e um céu de brigadeiro. A galera ouvia todas as sugestões e era super receptiva. Até que alguém teve uma ideia brilhante: “E se nós fizéssemos uma premiação para quem entregasse mais sprints no ano? Não precisa nem avisar a consultoria que está nos ajudando na transformação”.
O prêmio aconteceu; um time foi vencedor e o tempo fechou. Ondas gigantes e céu turbulento. Eu lembro que cheguei um dia à sala de um time que era super tranquilo e, quando fiz uma pergunta simples, recebi a resposta: “PERGUNTA LÁ PARA O TIMINHO CAMPEÃO!!!”. Foram dois meses de trabalho diário para fazer com que os times voltassem a conversar e a conviver em paz.
A raiz do problema: premiaram o time por ter entregue mais escopo no prazo, o que é uma métrica típica da gestão de projetos tradicional. Só usaram um nome bacana (sprint) em vez de ‘Pessoa-hora‘. Se for utilizar métricas, pense nessas aqui: Métricas: como medir a agilidade do seu time.
Agora, um pequeno aviso: utilizar métricas para comparar times sempre gerará competição e nunca colaboração.
Conclusão
Adotar agilidade não é implementar um método, mudar cargos ou renomear áreas. É encarar uma transformação profunda na forma como a organização pensa, decide e entrega valor. Os desafios apresentados mostram que a maior parte dos obstáculos não está nas práticas ágeis em si, mas no sistema organizacional que as cerca: estruturas de poder, modelos mentais, métricas equivocadas, processos excessivamente fragmentados e a ilusão de que tudo pode ser feito sem investimento real.
Quando a agilidade é tratada como solução mágica, fachada estética ou moda corporativa, ela se torna frágil e se quebra ao primeiro sinal de pressão. Por outro lado, quando a organização entende que o mundo muda, que o erro faz parte do aprendizado e que o foco deve estar no valor entregue ao cliente, a agilidade deixa de ser um discurso e passa a ser um diferencial competitivo.
No fim, a pergunta que precisa ser feita não é “qual framework vamos usar?” ou “O que o método diz sobre isso?”, e sim: “Que tipo de organização queremos ser?” Uma que luta para preservar o passado ou uma que se adapta, aprende e evolui continuamente. A agilidade não existe para tornar o trabalho mais confortável. Ela existe para tornar a organização relevante em um ambiente cada vez mais complexo, incerto e imprevisível.
A agilidade não existe para evitar mudanças. Ela existe porque o mundo muda.
