Ep. 232 - Transformação Ágil: Estratégias para escalar com eficácia

O assunto de hoje é sobre escala: o que é escalar, quando faz sentido e quando não faz sentido. Quando se fala em escalar agilidade, há pelo menos três dimensões diferentes: fazer com que a cultura se espalhe dentro da empresa, escalar o que se entende de ágil dentro de um produto, ou tratar a escala em nível organizacional. As pessoas, ao falarem sobre escalar, naturalmente imaginam levar a agilidade para todos os cantos da empresa ao mesmo tempo, o que gera disfunções como o tombamento. A escala não necessariamente significa que todo mundo caminhe para o mesmo jeito de pensar ao mesmo tempo. Pode-se escolher um produto ou um fluxo de valor e otimizar ponta a ponta, fazendo com que todos trabalhem em sintonia a partir dos mesmos valores e princípios. O assunto é polêmico porque não tem começo, meio e fim; depende do que se quer resolver, da cultura da organização e do contexto.

Muita gente trata o tema escala pela perspectiva de processo e organizacional, criando caixinhas padronizadas. Mas será que isso conversa com o negócio, com a necessidade de negócio, com o momento da empresa? Será que se está olhando o lado cultural? Há uma parte de produto e agilidade no mercado, e uma parte técnica que foi abandonada: práticas básicas de engenharia de software que impedem a agilidade. A pergunta fundamental é: você quer escalar o quê? Em qual momento você está? Às vezes nem se discutiu a necessidade de negócio do produto e já se está discutindo como roll outar times. Pode ser a discussão errada para aquele momento.

A consequência natural de escalar aquilo que se tem hoje é aumentar a complexidade do que já existia. É como pegar a Torre de Pisa, que está inclinada, e botar mais dez andares. Se não se acerta a fundação primeiro, não adianta escalar; vai-se escalar o problema. A frase do Craig Larman de que desescalar é o objetivo traz a ideia de entender qual problema se quer resolver primeiro, estruturar a coisa de um jeito legal, simplificar a forma de trabalhar, e só então fazer com que isso escale. Isso pode ser feito para um fluxo de valor, para um produto, para um departamento, para uma BU. O fundamental é evitar construir em cima do que já se tem, porque senão se está sedimentando problemas que já existiam.

Os quatro domínios da K21, criados há 12 anos, continuam válidos: negócio, cultura, organização e tecnologia. Para cada um dos quatro domínios, é preciso olhar se a coisa não está torta antes de escalar. Tentar escalar o lado técnico com cultura de comando e controle é a Torre de Pisa. Escalar sem olhar para o negócio, sendo orientado a projetos e não a resultados, é a Torre de Pisa. A torre de Pisa tem que ser olhada sob a perspectiva dos quatro domínios.

O princípio da autossemelhança, vindo do XP, é fundamental: coisas que valem para um time, dadas as devidas proporções, podem ser aplicadas para múltiplos times. Se há um problema de colaboração dentro de um time, as mesmas ferramentas de colaboração podem ser usadas entre times. Pair programming vira pair teams. O símbolo da autossemelhança é o fractal: em múltiplas dimensões, ele sempre aparece tal como ele na dimensão maior. A K21 e a Nower não são fãs de uma única técnica, método ou modelo; entendem essas coisas como um cinto de utilidades. Um modelo de escala é como um aparelho ortodôntico: cada empresa tem sua arcada dentária diferente, e a solução precisa ser construída em cima de problemas que se quer resolver e inspirações em coisas existentes.

Antes de discutir escala, faz sentido discutir qual a estratégia de transformação que se busca, qual alavanca se quer mexer. Os quatro domínios são um bom frame para isso. Uma vez discutido o caminho, então se olha para o cardápio de soluções. O princípio da autossemelhança também se aplica: primeiro, ter times multidisciplinares, com todos os conhecimentos dentro, onde profissionais do tipo T são mais importantes que especialistas numa coisa só. Ao escalar, observa-se que times tendem a se especializar, reproduzindo o mesmo problema de silos. Os três A's para expandir a equipe são: aprendizado, autonomia e automação. O maior problema organizacional em escalar está em dependências, que geram filas e aumentam o lead time. Resolver dependências significa criar mais autonomia: se o time depende de outro porque não sabe fazer, é falta de aprendizado; se sabe fazer mas não está autorizado, é falta de autonomia; se depende de uma ação do outro que poderia ser automatizada, é falta de automação. A expansão pode ser horizontal, tocando mais ponta a ponta o produto, e vertical, envolvendo priorização e mudança de processos organizacionais.

Multidisciplinaridade é a ausência de dependência externa: um time que consegue gerar valor ponta a ponta, fala com o cliente diretamente, cujo propósito é resolver o problema do cliente e não passar bastão para o time do lado. O livro do David Epstein, Generalistas Triunfam no Mundo Especializado, aborda isso. A origem dos silos organizacionais remonta à Revolução Industrial, quando se passou a agrupar pessoas por tipo de habilidade para maximizar a taxa de ocupação individual, criando departamentos e uma infinidade de filas. O sistema organizacional como um todo é pouco produtivo, e a empresa escalou a Torre de Pisa que ficou mais torta ainda. A origem de todos esses problemas está em crenças de gestão.

Existe um trade-off consciente entre eficiência financeira e fluxo. Há um modelo mais eficiente para a conta do financeiro fechar e outro mais eficiente para o fluxo fluir. A pergunta que se faz é: quanto custa ter um designer em cada time? Mas a próxima pergunta deveria ser: quanto custa não ter? É uma decisão econômica, contextual, que precisa ser feita para cada habilidade, não para o modelo como um todo. Não adianta fazer só a primeira pergunta; tem que fazer a segunda e decidir com base no resultado das duas.

Nos últimos dois ou três anos, o dinheiro ficou mais caro, a pressão financista aumentou, e a tônica é fazer mais com menos. Cargos estão sendo eliminados, a conta não fecha. Mas o lead time, que há três anos era de 200 dias, hoje é 120, o que ainda é muito lento para produto digital. A conta não fecha porque 120 dias ainda é caro e lento. O cenário é um recrudescimento do mercado que faz o lead time piorar e a questão financeira ficar mais crítica. As empresas não sabem o que fazer: não podem contratar, mas o lead time vai piorar e elas vão perder clientes. O movimento de economia foi guiado pelo CFO no primeiro momento, mas agora se percebe que a conta também não fecha só com olhar financeiro. Volta-se a discutir os conceitos mais básicos: qual é o resultado buscado de maneira mais consciente.

Estabelecer métricas antes de fazer um movimento é essencial. O Fit for Purpose ajuda a decidir quais métricas usar: redução de lead time, satisfação do cliente, ganho, economia. Não é uma métrica só, mas um painel enxuto. É como fazer TDD: o primeiro teste antes do desenvolvimento. As pessoas ficam apaixonadas pela solução e passam meses desenhando, mas o problema é o mesmo. O modelo de gestão, os sistemas de incentivo, estimulam cada um a ter uma visão umbilical. Escalar é também evoluir o modelo de gestão; sem mexer nisso, não se alcançam as métricas.

O básico bem feito antes de escalar inclui: ter boas métricas, clareza do que se quer alcançar e guard-regras do que não pode piorar. Depois, avaliar se os times precisam performar melhor, se o portfólio precisa ser reorganizado, ou se a estratégia precisa ser rediscutida. São três caminhos válidos, dependendo do problema. No Advanced CSPO, a ordem começa com o propósito: qual é a contribuição da organização para a sociedade, da área, do produto. Aí se entende o fluxo de valor, ponto a ponto, e com conceitos de Flight Levels, se identificam gargalos e dependências.

Sobre frameworks de escala: o Scrum at Scale, criado por Jeff Sutherland, é uma forma simplista de escalar poucos times próximos, mas não é ideal para cenários muito complexos. O SAFe é um dicionário de práticas que já existiam, organizado como peças de quebra-cabeça. É popular porque empresas tradicionais e engessadas veem qualquer melhoria como um mundo: se o lead time era de um ano e cai para três meses, já é maravilhoso. Mas para quem já atravessou a ponte para a agilidade, o SAFe é quase um passo atrás, porque engessa coisas que já foram resolvidas. O SAFe é uma bicicleta de rodinha: traz conforto, cadências fixas, um mapa claro para o executivo, mas não é o destino final. O Scrum foi desenhado para ser incompleto por definição, e o SAFe fez o oposto: ser absolutamente completo, o que gera o efeito oposto. A comparação mais adequada é com o PMBOK: a utilidade é real, mas o problema é que as pessoas querem implementar tudo. O simples é que vai fazer evoluir no complexo.

O LeSS, Large Scaled Scrum, criado por Craig Larman e Bas Vodde, é o mais revolucionário: o mínimo do mínimo possível para escalar. Adiciona uma reunião a mais e, acima de 80 pessoas, um papel a mais. É extremamente simples e parte da ideia de resolver dependências em vez de lidar com elas. Porém, é tão puritano que é muito difícil de adotar; não se conhece um caso de LeSS adotado no Brasil. Na prática, a K21 e a Nower usam muitos elementos de Kanban e Flight Levels, que se propõem evolucionários. A crítica comum a LeSS, Nexus e Scrum at Scale é a oversimplification da complexidade corporativa: é lindo, mas quase utópico para cenários com milhares de funcionários e muitas burocracias. Isso explica por que o SAFe teve mais adoção: responde melhor a um passo de escala dentro de um contexto onde já se praticava planejamento trimestral.

Na perspectiva evolucionária, a ideia é começar com o que se tem e encontrar o primeiro ponto para melhorar. Transformar tudo de uma vez raramente dá certo; nenhum case de tombamento funcionou. O evolucionário permite aprendizado ao longo do caminho. No tombamento, o grau de estresse é tão grande que as pessoas entram em pânico e ninguém aprende. Qualquer processo ruim fica médio daqui a dois meses, bom daqui a seis meses; o lance é o ponto de partida. A grande sacada do ciclo curto é encurtar o tempo entre aprender algo e colocar em prática. O ciclo curto pode ser uma semana, 15 dias, um mês, um trimestre, mas deve ser mais curto do que o que se tem hoje. Nesse ciclo, deve-se trazer resultado ou aprendizado; se não trouxe nem um nem outro, é preciso discutir os problemas.

A definição de um produto ou serviço mais amplo é um dos aspectos mais evolucionários. Um banco pode ter 25 produtos só de cartão, com 25 líderes de produto olhando para uma coisa que, no fundo, é um produto só, totalmente componentizado. Sem visão coesa de macro produto ou plataforma, é difícil focar times e entregas. O lead time de uma semana que existia na Globo era possível porque havia uma visão muito coesa de produto. Não é porque a característica é mais revolucionária que não se pode pegar pequenos elementos e já trazer ganho.

Na ótica do Kanban e dos Flight Levels, a primeira coisa é conhecer o problema. Várias vezes as pessoas usam frameworks de escala mas ainda não criaram uma visão de fluxo ponta a ponta. Se se cria essa visão, começa-se a ver onde as coisas estão paradas: 18 coisas aguardando ir para produção, meses paradas por um processo de implantação. Talvez esse seja o gargalo organizacional que deveria ser atacado. O pensamento sistêmico conecta tudo: achar pontos de alavancagem, que dizem qual métrica medir para ver se a reorganização está trazendo resultado.

Garrido gosta muito do LeSS, da forma como o planejamento e a review são feitos de maneira colaborativa, e de elementos do que Henrik Kniberg apresentou no Scrum Gathering de Paris em 2013 sobre coordenação, comunicação e autonomia. Duas perguntas fundamentais: qual o problema que se quer resolver e qual o problema que se vai criar com essa iniciativa. Toda modificação no fluxo de trabalho gera benefícios e desalinhamentos. O que importa é ter visibilidade, transparência e tranquilidade de que se vai errar e, em ciclo curto, com melhoria contínua, resolver e melhorar. Simplicidade sempre ganha. O simples é maravilhoso. Adicionar coisa é fácil; difícil é tirar. Para ambientes extremamente complexos, desescalar é a ideia.

Resumo dos pontos: primeiro, cuidado para não construir a Torre de Pisa com as coisas erradas. Segundo, olhe pelos quatro domínios, porque a Torre de Pisa pode estar em cada um deles. Terceiro, parta do propósito para ter pensamento sistêmico e entender por onde começar. Quarto, faça evolucionário: estenda as cadeias de valor e escolha por qual começar a escalar ou corrigir. Quinto, defina a métrica a partir do propósito e da cadeia de valor. Flight Levels é uma maneira de conectar estratégia à execução. O LeSS traz a base: aumentar a autonomia dos times com os três A's e ter produtos mais amplos. Finalmente, cultura da experimentação e melhoria contínua, que significa ser menos arrogante, estar preparado para ajustar o desenho continuamente.

Duas dicas finais: primeiro, tornar as disfunções conscientes. Qualquer processo de escala que não torna o implícito explícito tem chance enorme de falhar. Pode ser numa análise de fluxo, nas métricas, na transformação. Se a disfunção não for consciente, nunca se fará um trade-off em cima dela. Segundo, cuidado ao olhar o fluxo a partir da visão do próprio time. Na escala, é importante ter uma visão de portfólio como um todo, do ponto a ponta. O time está dentro de um silo organizacional e pode estar tomando decisões com uma visão particular que não reflete o ponto a ponta. Muitas empresas usam como lead time apenas 30 ou 40 dias de um pedaço do fluxo, que é um cycle time, não o lead time real. Falar de escala sem essa visão pode criar premissas erradas e escalar a Torre de Pisa de verdade.