Por que sua abordagem atual para escalar o ágil não está funcionando?

Você tem problemas para escalar sua agilidade? Você não está sozinho. Mesmo organizações que têm sucesso ágil em setores isolados têm dificuldade em escalar a agilidade para a organização como um todo. Os desafios se expressam em padrões familiares. Algum destes parece familiar?

1. A cópia do modelo de outra organização não funciona;
2. O design da organização entra em conflito com o objetivo de agilidade;
3. Tentar "copiar e colar" o que funciona para uma equipe em todas as equipes;
4. Otimizar de forma independente diferentes partes da organização;
5. Investir pouco em práticas de engenharia ágil.

Neste artigo, discutiremos os desafios sistêmicos mais comuns para aumentar a agilidade e finalizamos com o desafio de comparar entre a abordagem desses desafios por estruturas de escalonamento populares.

Copiar o modelo de outra organização não funciona

Sustentar o ágil em escala requer uma mudança na estrutura organizacional, nas políticas de trabalho e no comportamento. Como qualquer outra mudança em escala, esta é uma tarefa desafiadora.

Uma solução rápida é copiar uma abordagem bem-sucedida usada por outra organização. Embora isso possa trazer benefícios a curto prazo, com o tempo, essa abordagem provavelmente não será bem-sucedida.

Por quê? Porque não há atalhos em uma jornada ágil. Você deve trabalhar com o que a agilidade significa para você e como você trabalhará para apoiá-la; você não pode copiar as respostas de outra pessoa porque as perguntas (ou desafios) delas são diferentes das suas.

Ao buscar escalonar a agilidade na organização, as pessoas na empresa precisam ter uma nova maneira de trabalhar. Para que isso aconteça, eles terão que criar seu próprio processo que funcione em seu contexto específico. Quando as pessoas criam o processo, elas aprendem o que funciona para elas e em seguida, uma nova cultura "a forma como fazemos as coisas aqui" irá emergir.

Implementar o modelo de outra pessoa é como fornecer uma resposta antes de conhecer a pergunta, o que provavelmente não será bem-sucedido. Em vez disso, considere iniciar com um processo mais simples que funcione em seguida aproveite-a usando o Controle de Processo Empírico e uma estrutura que torne transparente para todos o que melhorar, essa estrutura é chamada Scrum.

Há uma história que, em 2001, a Toyota queria publicar um livro chamado "The Toyota Way". Ao ouvir isso, seu CEO disse que ele se opunha ao título, sugerindo que ele deveria ser chamado de "The Toyota Way 2001", porque no ano que vem sua maneira de trabalhar teria mudado.

A verdadeira agilidade permite que uma organização se adapte continuamente a um mundo em mudança. Quando você tenta usar atalhos para a agilidade copiando o "modelo" de outra pessoa, na melhor das hipóteses você será simplesmente uma pobre imitação de onde ela estava em algum momento no passado.

O design da organização entra em conflito com o objetivo de agilidade

As organizações buscam agilidade para melhorar sua capacidade de adaptação às mudanças nas condições de mercado. A maneira ágil de fazer isso é aprender mais rápido que seus concorrentes. Conseguir isso no nível da organização requer que a empresa tenha um design otimizado para aprender rapidamente e se adaptar à mudança.

O design organizacional que otimiza a agilidade fornece os seguintes benefícios:

• Melhor transparência no desempenho de produtos e serviços, possibilitando melhor gerenciamento da execução da estratégia;
• Melhor capacidade de alocar equipes e dinheiro para alcançar resultados específicos, alinhados com a estratégia;
• Decisões mais rápidas, possibilitadas por pessoas que estão mais próximas do problema e podem tomar decisões com as informações certas no momento certo;
• Melhor aplicação do capital e das pessoas às mudanças nas condições de mercado;
• Uma cultura organizacional que define e alcança altos objetivos.

Todas essas coisas parecem boas, mas não acontecem por acaso. O design da organização deve estar especificamente alinhado com o objetivo de adaptabilidade. O design organizacional tradicional é otimizado para diferentes objetivos, geralmente em torno da utilização de recursos e da previsibilidade dos resultados. Isso pode impedir sua capacidade de se adaptar aos seguintes cenários:

• A preferência por previsibilidade significa que ao se concentrar em criar planos detalhados e medir o desempenho em relação à eles, os desvios dos planos serão atendidos com esforço para levar ao cumprimento do plano, não adotando o plano para novas realidades.
• A tendência de punir os desvios dos planos reduz a transparência, de modo que as informações que mostram que o plano pode estar errado ficam ocultas o máximo de tempo possível, a fim de evitar punições.
• As preferências por controle hierárquico significam que as decisões são tomadas com base no nível de uma pessoa na organização, não em sua proximidade com o problema a ser resolvido ou com o cliente a ser atendido. Isso pode atrasar a tomada de decisões.

Vamos ilustrar isso comparando o projeto de um carro de Fórmula 1 com um de corrida de rally off-road:

Um carro de Fórmula 1 é otimizado para velocidade e manobrabilidade em um circuito conhecido e bem pavimentado que é rigidamente controlado. Embora possa ter que lidar com climas variáveis, tem uma equipe dedicada para lidar com problemas mecânicos, e não há desafios para encontrar rotas.

Uma equipe de rally off-road, como as que competem no Rally Dakar, devem levar todas as suas próprias peças de reposição. Eles devem lidar com condições de rota variáveis e serem capazes de improvisar para alcançar sua meta mais rapidamente do que outros concorrentes.

Tanto os carros de Fórmula 1 quanto os pilotos de off-road têm velocidade como meta, mas o grau de incógnitas em um rally off-road significa que a equipe e o carro devem ser altamente adaptáveis. Os carros de Fórmula 1 são mais rápidos, mas apenas porque operam em um ambiente muito mais controlado. Se estivessem em um rally, iriam quebrar e sairiam da prova quase que imediatamente.

Organizações no mundo de hoje se encontram em uma corrida muito mais parecida com um rally off-road do que uma corrida de Fórmula 1, na qual a adaptabilidade às mudanças de condições determina o vencedor.

Um design organizacional comum é a hierarquia.

Conforme observado acima, a hierarquia otimiza a conformidade eficiente com um plano no qual os desvios do planejamento são rapidamente identificados e eliminados.

John Kotter destaca alguns outros objetivos importantes da hierarquia.

... o desafio é que, tanto a nível filosófico como prático, a hierarquia (com seus processos de gestão) se opõe à mudança. Ela se esforça para eliminar anomalias, padronizar processos, resolver problemas de curto prazo e alcançar a eficiência do cronômetro em seu modo atual de operação…

A agilidade, por natureza, tem que assumir que existem condições nas quais o plano está errado e precisa ser revisado ou descartado. Isso está ameaçando uma organização hierárquica, não se pode otimizar o controle e a eficiência e ao mesmo tempo otimizar a adaptabilidade e a velocidade do aprendizado. Portanto, se fizer mudanças superficiais no design organizacional, a antiga meta sistêmica permanece.

Quando a iniciativa de dimensionamento começar a desafiar as estruturas de poder atuais, ela provavelmente será prejudicada porque o sistema tentará manter seu antigo objetivo. As pessoas irão se apoiar aos atuais acordos e políticas de trabalho padrão e as usarão para refutar a nova maneira de trabalhar. Isso não acontece porque as pessoas não querem mudar, mas sim porque o sistema em que trabalham espera que elas resistam.

Tentar "copiar e colar" o que funciona para uma equipe em todas as equipes

Outro equívoco comum é que escalar a agilidade significa que apenas as equipes precisam mudar, enquanto o sistema de gerenciamento, a estrutura e as políticas organizacionais e a cultura geral da organização podem permanecer basicamente as mesmas. As organizações que assinam essa crença escalam a agilidade copiando e colando as equipes do Scrum: Cada novo Time Scrum adiciona um Product Owner (Dono do Produto) com sua lista de pendências de equipe, uma Equipe de Desenvolvimento e frequentemente um Scrum Master também.

Essa estratégia começa a falhar rapidamente quando várias equipes Scrum precisam trabalhar em um único produto. A medida que adicionam mais equipes Scrum, é preciso coordenação e em resposta a isso, adicionar mais processos e mais funções de coordenação para gerenciar dependências. Cada equipe adicionada tem a tendência de otimizar localmente sua própria entrega sem considerar o todo.

Adicionar mais processos faz com que todos sintam que o processo é responsável por garantir que as coisas estejam certas, o que destrói a propriedade e a responsabilidade das equipes. Melhorar o processo é o problema de outra pessoa. Adicionar transferências entre equipes e clientes também destrói a empatia do cliente e reduz o entendimento das equipes sobre o produto.

Por fim, backlogs acumulados reduzem a transparência do progresso em todo o nível do produto e exigem mais status e reuniões de alinhamento. Tudo isso, adicionando a complexidade, reduz a adaptabilidade da organização.

Otimizar diferentes partes da organização de forma independente

Tentar escalar a agilidade na hierarquia se concentra em fazer com que as estruturas existentes funcionem de maneira ágil, isso mantém as pessoas e equipes isoladas umas das outras. Ter equipes funcionalmente isoladas, como uma equipe ágil de análise de negócios, uma equipe de arquitetura ágil, uma equipe de gerenciamento de projetos ágil ou uma equipe de DevOps são o resultado. Contudo, equipes que não podem entregar nada por conta própria. Um problema semelhante existe quando as equipes se concentram em componentes únicos, resultando em uma equipe de banco de dados ágil, uma equipe de UX ágil ou uma equipe Java ágil, nenhuma dessas equipes pode oferecer algo de valor por conta própria.

Supor que, aumentar o desempenho de cada uma dessas equipes separadamente aumentará o desempenho do todo, é um erro, pois ignora o problema crítico de como as equipes trabalham juntas para produzir um produto de trabalho:

Há muitos lugares em que diminuir o desempenho de uma peça melhora o desempenho do todo. O desempenho de um sistema depende de como as partes interagem, nunca de como as partes agem separadamente.

Professor Russell L. Ackoff (Recriando as organizações . Oxford University press 1999.)

Sem a capacidade de criar um produto funcional, as equipes não podem saber se estão criando uma solução que atenda às necessidades do cliente. Isso é uma premissa verdadeira mesmo quando não estamos escalando o ágil, entretanto, seu impacto é amplificado durante o processo. Para resolver esse problema, as equipes precisam ter uma multifuncionalidade e um componente ligando as equipes, assumindo a responsabilidade de resolver o problema de um cliente, para fornecer a eles uma solução completa.

Isso significa:

• Projetar a organização em torno de produtos para oferecer melhores resultados aos clientes, sem atrasos;
• Criar uma organização focada em produtos que consistem em equipes de recursos que trabalham em um único produto;
• Mudar para uma organização de linha multifuncional onde as equipes multifuncionais relatam para gerentes multifuncionais;
• Introduzir um sistema de orçamento no qual o Product Owner (Dono do Produto) tem poderes para tomar decisões de investimento com base no feedback recebido do mercado e dos clientes ou usuários;
• Mudar o sistema de gestão e a cultura para que eles valorizem o trabalho colaborativo e multifuncional das equipes e expandam continuamente as capacidades de ambas as equipes e membros da equipe, capacitando-os a resolver problemas e apoiando-os à medida que aumentam suas capacidades.

Pouco investimento em práticas de engenharia ágil

Enquanto muitas organizações entendem que precisam contratar coaches para trabalhar com equipes ágeis, ajudando o time de desenvolvimento, Scrum Masters e Product Owners a melhorar suas formas de trabalhar, muitos não entendem a importância de contratar coaches para melhorar a excelência técnica praticada por aqueles mesmas equipes. Como resultado, a organização não pode escalar porque não pode sustentar ou melhorar a qualidade do código.

No desenvolvimento de software ágil, o ponto principal é que o software é flexível o suficiente para que possa alterado rapidamente, com baixo custo, disponibilidade de validação para entender se ele oferece o que é esperado. A maneira de conseguir isso é criando software de alta qualidade usando práticas de engenharia ágeis. Mesmo com todos os processos, post-its, Scrum Masters e design organizacional ágil desejado, sem um software de alta qualidade e alta competência em práticas de engenharia ágil, a parte do processo só pode chegar a metade do caminho.

A escalar a agilidade requer automação efetiva do processo de criação e teste, para iniciar e também, a automação completa de todo o pipeline de entrega. Escalar também exige que o produto que está sendo construído tenha uma arquitetura desacoplada, de modo que qualquer parte do produto possa ser facilmente alterada ou substituída. As práticas de controle de versão também são importantes. O desenvolvimento baseado no trunk-based, especialmente a eliminação do recurso de ramificação e integração contínua, é essencial para que as equipes se coordenem de maneira eficaz e para evitar que as dívidas técnicas cresçam de forma invisível e traiçoeira, e estes pontos são apenas um começo.

Para escalar as estruturas é necessário adotar abordagens diferentes para esses desafios - uma comparação entre SAFe, LeSS e Nexus

As diferenças entre diferentes estruturas de dimensionamento refletem diferenças filosóficas profundas sobre os principais desafios no escalonamento da agilidade. O SAFe tenta ser minimamente disruptivo para não provocar conflitos, por isso tenta adaptar-se ao máximo à organização. O LeSS considera o design organizacional existente como a barreira fundamental para desenvolver um produto com várias equipes, de modo que ele lida com isso de frente. O Nexus não tenta resolver o problema da organização, em vez disso, se concentra no desenvolvimento de produtos grandes com várias equipes trabalhando juntas. Essas diferenças são expressas na tabela a seguir com comparações sobre como elas mapeiam os cinco desafios:

Conclusão: escalar a agilidade significa desenvolver agilidade organizacional

Não se pode aumentar a agilidade copiando os outros. É preciso aprender por si mesmo que processo, estrutura e políticas funcionam em seu contexto específico. Para sustentar e aumentar a agilidade, as pessoas na organização precisam apropriar-se de seu processo para que possam melhorá-lo com o tempo e, para que isso aconteça, as pessoas precisam fazer parte da criação do processo desde o início.

Ao longo do caminho, é preciso procurar oportunidades para fazer algumas alterações:

• Mudanças no design organizacional: Novos acordos de trabalho, políticas e uma nova estrutura organizacional podem ser necessários para que o foco se mova para maximizar o valor em vez da utilização. O valor flui horizontalmente em uma organização, não verticalmente, pois a maioria das organizações é estruturada.
• Mudanças nas habilidades: As pessoas provavelmente precisarão aprender novas práticas para poder entregar com frequência um produto de alto nível que é co-criado com seus clientes.
• Mudanças de comportamento: as pessoas serão convidadas a trabalhar em equipes reais que se apropriam dos resultados da equipe.

Agilidade não é um tipo de processo, ferramenta ou estrutura que as organizações adotam, é uma maneira de pensar e trabalhar que envolve a experimentação e o aprendizado. Não há atalhos que evitem todo o trabalho duro, mas a boa notícia é que o aprendizado e a experimentação podem ser divertidos, e tornam a navegação no desconhecido menos assustadora. Não é preciso ter todas as respostas, basta ter um objetivo e uma disposição para experimentar coisas novas.

Sobre os autores

Cesario Ramos trabalhou no desenvolvimento de produtos ágeis desde 2001. Atualmente, trabalha no mundo todo como um especialista em desenvolvimento de produtos e coaching de organização ágil. Trabalhou em várias organizações, incluindo alta tecnologia, grandes bancos, seguros e telecomunicações. Cesario é o autor do livro "EMERGENT - adoção Enxuta & Ágil para um ambiente de trabalho inovador" e co-autor do livro "Scrum Patterns". Regularmente dá palestras em conferências em todo o mundo e co-organiza as conferências do LeSS. Também é um Instrutor Certificado de LeSS e Treinador de Scrum Profissional no Scrum.org. Em 2010 fundou a AgiliX, uma empresa de consultoria, que fornece consultoria e treinamento em todo o mundo.

Kurt Bittner tem mais de 30 anos de experiência na entrega de software de trabalho em ciclos curtos e impulsionados por feedback. Ajudou uma ampla variedade de organizações a adotar práticas ágeis de entrega de software, incluindo grandes organizações bancárias, de seguros, manufatura e varejo, bem como grandes agências governamentais. É ex-analista do setor de tecnologia da Forrester Research. Seu foco é ajudar as organizações a criar equipes fortes, auto-organizadas e de alto desempenho que ofereçam soluções que os clientes adorem. É autor de quatro livros sobre tópicos relacionados ao desenvolvimento de software, incluindo o Nexus Framework for Scaling Scrum. Mora em Boulder, Colorado e atua como vice-presidente de soluções corporativas para Scrum.org.