M1: Bom dia, boa tarde, boa noite. Vamos começar mais um episódio dos agilistas e hoje nós vamos falar de um tema que é extremamente relevante, a gente percebe tanto por perguntas de ouvintes, podcast e eventos, e principalmente, os nossos clientes, que é como ficar ágil. No final das contas, eu diria que é a grande pergunta de todo mundo que ouve o podcast. No fundo, de uma forma ou de outra, as reflexões sempre tem a ver com esse grande tema que é como a minha empresa consegue ficar mais ágil, como pode fazer uma gestão de pessoas diferente, como pode se organizar de forma diferente, como faz para ficar ágil. E é curioso pelo seguinte, por um lado a gente fala muito isso aqui, não existe uma prescrição de como ficar ágil, é um caminho que as empresas vão ter que seguir, ter que achar o próprio caminho e isso vai depender muito da história da empresa, depender fundamentalmente do contexto de cada empresa. Uma expressão que eu tenho usado muito nos episódios, que acho super bacana que faz parte de complexidade, os caras falam que essas transformações complexas são context bound, são totalmente dependentes do contexto onde acontecem. Se por um lado fica muito claro que é perspectiva e que as empresas têm que achar o caminho delas, por outro lado, falar só isso deixa quem quer fazer essa mudança com uma sensação de estar sozinho, está perdido, sem referência, de ficar pensando: o que eu faço. E é claro, todos os nossos episódios estão tentando de alguma forma mostrar possíveis caminhos e ações, mas o que a gente queria falar hoje é tentar organizar um pouquinho essas possíveis ações, numa espécie de framework, se é que eu posso chamar assim. Essa vai ser uma das primeiras perguntas que eu vou fazer para os convidados que apresentarei em instantes, mas o que a gente pretende hoje é mostrar uma organização de como você ir avançando rumo a tornar a empresa mais ágil, como você pode enxergar se está em uma trajetória de mudança, o que você deve almejar nessa trajetória, quais os pilares com os quais você deve se preocupar. Sem mais delongas, eu queria apresentar os convidados, pedir para eles se apresentarem. Estamos aqui com a Ias, que já é conhecida do público, beleza Ias?
F1: Oi pessoal, tudo bem? Bom estar de volta, vocês já me conhecem, mas aqui na DTI eu cuido dos pilares de design de produto e atuo como consultora com nossos clientes.
M1: Estamos aqui com nosso ídolo, Régis.
M2: Ídolo da minha mãe, esposa e filhos: pessoal, bom estar de volta. Sou Régis, aqui da DTI, trabalho com consultoria de agilidade e gerente de contas.
M1: Régis hoje não vai falar de OKRs, a gente proibiu.
M2: Por mais que eu insistisse, não foi permitido.
M1: Em algum momento vai aparecer, Régis. Não tem jeito. Estamos aqui com o Lucas.
M3: Boa noite, pessoal. Prazer em falar com todos e hoje, eu estou tentando responder a perguntar sobre o que faço aqui na DTI. Acho que, mais que nunca, nós estamos juntos com nossos clientes, respondendo essa pergunta, de como nos tornar realmente ágeis. Acho que é isso que estou fazendo no meu dia a dia.
M1: Exatamente. Então a minha primeira pergunta é essa. A gente usa muito uma metáfora de que você fica ágil sendo ágil, fala sobre como a liderança tem que ser diferente, como a própria organização tem que ser diferente, como é esse processo, é contínuo. Como eu disse anteriormente, que tipo de ajuda alguém pode ter poder ter para poder trilhar esse caminho, que tipo de referência pode ter. A primeira que faço é essa, a gente vai fazer uma síntese de um caminho que a gente acredita que deve inspirar as empresas. Você chama esse caminho de framework, o que você chama isso? Fala um pouquinho mais sobre isso, para tentar dar um sabor do que é.
M3: A gente, como eu falei, tenta responder essa pergunta cada vez mais, e estava até conversando hoje mais cedo, eu, Ias e o Régis. De tanto responder, a gente já tem uma resposta atual. A gente vê que essa resposta vai sempre evoluindo, todos os dias, como qualquer processo ágil, mas hoje, fundamentalmente, tem trabalhado com os nossos clientes em três dimensões bem fortes, suportadas por quatro pilares muito bem definidos. Queria até pedir para Ias, ela apresenta isso muito melhor que eu, que falasse para a gente quais são essas três dimensões que a gente tem trabalhado e como a gente concretiza essa questão de se tornar ágil. Baseado em quais três dimensões a gente faz isso, Ias?
M1: Só apertar a Ias um pouquinho, são três dimensões e quatro pilares do que? É um framework? Não que isso seja tecnicamente tão importante, mas é uma referência? Como você chama isso?
F1: Me apertaram bem agora.
M3: É um slide, Ias. Cabe em um slide.
F1: É uma imagem. Mas sem brincadeira. Talvez a palavra framework dá impressão de que é um caminho já prescritivo, segue essa regra que vai dar certo. E, nesse sentido, não é essa nossa intenção com essas três dimensões e esses quatro pilares, mas é uma orientação, um caminho de preocupações que uma empresa tem que ter. Essas três dimensões tem que ser olhadas e os quatro pilares tem que ser reforçados. Então, para falar um pouquinho e tirar a curiosidade do pessoal, a gente começa com as três dimensões. Quais são elas? Uma primeira geração, muito inicial para uma organização, é agilidade de times. A dimensão de team agility. É realmente ter times ágeis na organização. Parece simples, mas pelo tanto que a gente já conversou, até mesmo no podcast, pela experiência que a gente tem, não é tão trivial formar times ágeis de verdade. Tem que garantir que tem times ágeis, que atuem dentro dos princípios, das práticas ágeis, já é um grande desafio em si mesmo. Muitas vezes as organizações tem que começar por aí, criando seus primeiros times ágeis que começam a mudar a organização aos pouquinhos. O que acontece, muito provavelmente, é que a organização vai passar a ter vários desses times, e apenas ter agilidade dentro do nível do time não é mais suficiente, porque você não quer que os times estejam atuando em silos, sozinhos, individualmente. Você quer que eles, juntos, gerem valor, e aí entra nossa segunda dimensão, que é a agilidade de times de times, as coisas que a gente tem que pensar para garantir maior sincronização entre esses times, maior geração de valor, como eles estão organizados, começam a surgir estruturas diferentes, papéis diferentes, algumas práticas e ritos também específicos para esse conceito de time de times.
M3: Ias, só um parêntese, tem um negócio muito legal nessa segunda dimensão, que tem muita gente menosprezando isso, e até o aprendizado que é um dos grandes conceitos da agilidade, hoje está nessa dimensão de times, que não é tão trivial, como um só time. O que eu estou querendo dizer com isso é que um time que convive todo dia, aprender com as suas tentativas e seus erros, é uma coisa quase que direta, agora um conjunto de times, que é uma coisa muito mais complexa, muito mais oblíqua, aprender com que ela produziu nos últimos sprints ou nas últimas interações é algo bem mais desafiador. Essa dimensão do aprendizado é uma das coisas que eu acho bem legal, já mostra um exemplo concreto, uma complexidade maior da segunda dimensão em relação a primeira.
F1: Com certeza, aumenta bastante o desafio do que a gente tem que pensar em termos de práticas para garantir essa cultura ágil entre os times. A terceira dimensão, que é talvez a mais ampla e desafiadora, é o enterprise business agility. A gente está falando da agilidade da organização como um todo, de mudanças estruturais que tem que acontecer para habilitar uma cultura ágil. Então, a gente sabe criar times ágeis, culturas ágeis, algumas mudanças já acontecem, mas muito provavelmente a organização vai ter que parar para refletir sobre algumas dessas práticas de contratação, remuneração, incentivo, de liderança, hierarquia, para que esses elementos sejam favoráveis a agilidade, e não o contrário, não impeçam que a agilidade aconteça. Então, essa dimensão tem muito a ver com o que a gente fala no episódio do true agile, que é levar essas práticas e conceitos ágeis para além do formato de trabalho do time, mas um formato organizacional.
M3: É importante enfatizar que não é uma jornada sequencial. Não estamos falando que a empresa tem que ficar fera a nível do time, tinha que estar um brinco primeiro, para depois o agrupamento de times ficar bonito e, depois, a organização toda ser impactada. Na verdade, o que a gente está tentando sistematizar, em conhecimento, é como uma empresa que não é ágil fica ágil. É essa a perguntar que a gente quer responder. A gente pode contar essa história de vários pontos de vista, de baixo para cima, com uma empresa ficando ágil ao colocar um time, depois outro, depois outro, e a medida que isso vai crescendo, vai tomando conta da organização, e quando a organização percebe, ficou ágil. Você pode contar de cima para baixo, uma organização, por meio de sua liderança, enxerga a necessidade de ficar mais ágil e começa a dar direcionamentos nesse sentido e mais autonomia para as pessoas, e começa, a partir de uma visão da liderança, a instituir seus times. Mas, no fundo, tanto se você começa de baixo para cima como de cima para baixo, vê que tem três aspectos, chamados de dimensões, que fazem parte dessa jornada. Para fazer isso a contar do time ou da liderança, tem que entender que tem uma dimensão, que é o time funcionando, uma dimensão que é o time interagindo com outros da organização, e uma dimensão que é a dimensão da liderança, que é a cultura da organização como um todo. Então, essas três dimensões são sensibilizadas, mudadas, afetadas, ao mesmo tempo na jornada de transformação. É essa a grande descoberta, a grande diferença de falar em agilidade no nível de organização, a gente entender que tem ações acontecendo simultaneamente nessas três dimensões que você quer, de fato, uma transformação.
M1: É muito legal isso, eu ia realmente fazer essa pergunta, porque, dependendo, se a gente não explicita isso, fica parecendo um modelo tradicional de maturidade com três níveis. Eu estou no nível um, dois e três. São aspectos que você tem que considerar continuamente em toda jornada, o tempo todo, você pode estar mais forte em um e menos forte em outro, em uma área da empresa está bem em uma e bem em outra, por isso que acho importante salientar isso. Isso vai depender completamente do contexto, que acontece dentro da própria empresa. Vão ter áreas da empresa que, naquele momento, tem que ter muito mais preocupação com o aspecto do que outra área, concordam?
F1: Plenamente.
M3: Concordo com isso que você falou, que cada organização vai fazer isso da sua forma, mas uma coisa, já completando o modelo que todo mundo precisa ter, na nossa visão, é minimamente quatro pilares para estruturar essa mudança acontecendo nessas três menções. O primeiro deles, que eu vou explorar, é o de governança. A gente vê, conversando com as pessoas, o cliente, colegas de trabalho: não, governança, como assim, todo mundo tem governança. Ok, todo mundo já tem governança em maior ou menor grau, ainda mais grandes empresas. Mas essa governança é ágil? Até mais do que ser ágil, ela corrobora para que os times continuem atuando de forma ágil ou incentiva que os times sejam verdadeiramente ágeis, que consigam atuar verdadeiramente no nível lá de sense and respond e o que a gente vê é que muitas empresas têm dificuldade nesse pilar, porque ou não têm, por incrível que pareça, uma governança, coisa que parece um pouco caótica, com os times ágeis atuando de forma ágil, porém de forma pouca organizada ou minimamente com pouca visão de longo prazo. É como se a empresas ficasse super ágil, com dez startups, mas pouca garantia que vão entregar a estratégia que a empresa quer fazer, ou então o outro extremo, muito comum quando existem mudanças, é os times ágeis, mas a governança é algo totalmente cascata. O que é governança cascata? Um PMO tradicional cuidando de portfólio de projetos, que os times ágeis estão executando. Daqui a pouco vou falar sobre pilar de produto.
M1: O curioso é que, desde que comecei a trabalhar com ágil, 20 anos atrás, que esse tipo de visão existe. Se eu não sou ágil, não tenho processo nenhum, se eu sou ágil, qualquer tentativa de disciplinar e algumas interpretações viram como se fosse uma coisa anti ágil. Ou o cara fica apegado ao passado dele de forma muito rígida, como você disse, ou no mundo dos ágeis, cria uns times que chamam de squads, mas continuam fazendo gestões exatamente iguais era antes, com respostas exatamente iguais, ou o cara pensa que é ágil. É engraçado que essa governança está em si, no peso de processos mais burocráticos. A comunidade ágil reage muito forte a essa palavra. Concorda, Régis? Quando fala governança, o cara agilista raiz fala: sai para lá com governança.
M2: E se a gente falar de burocracia, que a gente, na verdade, não está querendo eliminar, mas da desnecessária, tem um nível ali em que as duas coisas se entrelaçam, a governança e a burocracia. Eu não estou fazendo uma defesa cega nem de um nem do outro, mas tem um nível que é benéfico. Por exemplo, quando um time vai fazer uma entrega e depende do outro, que se comprometeu a fazer determinada entrega, mas não vai entregar, por alguma coisa que vai acontecer, tem que, no mínimo, comunicar isso. Só isso, em um nível muito básico, é uma burocracia necessária. O time tem autonomia, tem objetivos, está orientado, mas quando você enxerga que esse time depende da entrega de um outro time, já cria necessidade de estrutura que antes não existia para realizar esse sincronismo. Qual é a nossa salvaguarda? Como a gente não é fã de burocracia, pouca burocracia e barreira por barreira, a gente vai colocar esses controles em um nível que estejam a serviço da entrega. Esse é o grande segredo, com cuidado para fazer a governança ágil, ou até chamada a burocracia ágil. Mas tem jeito de se colocar na estrutura. Naturalmente, essas estruturas aparecem como mais necessárias, e tem como você utilizá-la sem trair os princípios.
M1: Isso é perfeito, porque, em um extremo, alguém pode falar que fazer uma reunião diária é burocracia, se o cara achar que qualquer coisa é burocracia. Depende de alguma forma ter alguma norma.
M3: Tem uma visão muito clara, na minha visão, que a governança ágil precisa viabilizar a real autonomia dos times e autonomia de um time ágil, dentro do contexto da formação digital, só vai ser genuína, no sentido de alcançar um resultado, se aquele time tiver capacidade de gerar valor, de forma minimamente autônoma. Isso é muito difícil na prática. Por isso quando o Régis coloca que a gente vai precisar de alguma estrutura para cuidar disso é porque é um problema de muito difícil solução, se não tiver gente dedicada pensando nisso. Quando a gente fala em problema de difícil solução, imagina o seguinte: eu tenho três times orientados tradicionalmente a projetos, que estão trabalhando na empresa, e eu estou achando que esses times estão gerando pouco valor. Eu agora sou responsável pelo pilar de governança junto com algumas pessoas, o que a gente vai fazer? Eu quero maximizar a capacidade desses times de gerar valor no tempo, e para fazer isso, muito provavelmente, eu vou ter que mexer na estrutura desses times, vou ter que quebrar algumas tensões organizacionais, silos de departamentos ainda antigos que exigem que cada time tenha representante de um departamento e vou mexer nesse time para que eles sejam orientados a um fluxo de valor, de modo que eu maximize a geração de valor. Estou falando isso para tangibilizar o que a gente acredita que é governança ágil, é fazer isso e é um trabalho difícil, por isso que a gente justifica ter uma pessoa ali, olhando. E se vai ser ágil, esse time tem que ter um backlog de coisas para fazer, que é a governança. Eu tenho itens para fazer para ir destravando os outros times. Mais para frente, se der tempo hoje ainda, vamos falar do squad de liderança ágil, que atua muito forte com esse tipo de governança. Só para não alongar demais na governança, eu queria perguntar para Ias, porque sei que é o pilar que ela mais gosta, seguindo o pilar de governança, o que vem dentro dessa sistematização que a gente tem colocado da agilidade em escala?
F1: Eu não sei nem se pode ter um pilar favorito, mas o meu é o de produto. Sou levemente obcecada com esse pilar, porque o que significa o pilar de produto? É uma cultura de times que gerenciam produtos, não que entregam softwares, e isso é bastante simples falando, mas é uma mudança muito grande. Às vezes o ágil pode ser encarado no primeiro momento como uma alternativa para entrega de software. Eu entrego software mais rápido e melhor, mas não é só isso que a gente está buscando. O que a gente está buscando de fato é construir produtos digitais que geram valor, que os clientes querem, desejam, gostam de usar, tenham um prazer, que traga o resultado. Para fazer isso, você precisa fazer uma boa gestão de produto, precisa de times que tenham metodologias, que tenham práticas não só para desenvolver software, mas para gerir produtos, ou seja, para acompanhar métricas, fazer pesquisa com os clientes, para estar o tempo inteiro monitorando esses produtos, coletando feedback, experimentando, testando hipótese, então é todo um grupo de novas capacidades, novas habilidades, novos processos que têm que ser incorporados nesses times ágeis para esse pilar de produtos ser de fato efetivo, e a gente ter times ágeis criando produtos incríveis e não só entregando software.
M1: E é super crítico isso que você comentou. Aquela história da evolução contínua, em um dado momento, a organização até se beneficia muito de simplesmente ser capaz de entregar software continuamente. Aquilo não deixa de ser um primeiro sucesso, mas é claro que isso é muito restrito, porque aquele software tem que existir em função de alguma coisa, algum resultado. Essa dimensão traz isso, não deixa você esquecer onde quer chegar, criando grandes produtos, e não fazer software e pronto. O que é importantíssimo, mas se ficar sem objetivo claro, não vai gerar valor.
F1: Uma coisa que gosto bastante de falar com nossos clientes é que para esse pilar de produto florescer já muda logo na definição e formação do time. Quando você forma um time, vai construir um aplicativo. Esse time já está automaticamente orientado a entrega de um software. Se você orienta um time para ser formado, para dar um jeito no cliente, abrir uma conta o mais rápido possível, você já está formando um time com uma ambição maior de produto, realmente atingir valor, gerar esse valor. Se ele vai construir um aplicativo, no final das contas, vai ser um meio para ele atingir isso. Acho que já tem essa diferença crítica até na própria formação do time. Qualquer missão dada é de puramente construir um software ou de gerar um valor importante para o seu negócio?
M2: Nessa dimensão de produto. Essa transformação acontece em três dimensões, você tem que pensar em produto na dimensão do time, como o time pensa aquele produto que está entregando, na dimensão de times de times, seja porque vários times estão alocados no mesmo produto, os produtos têm essa relação, não estou entregando o produto que entrega valor para o próximo da cadeia, e nessa visão de produto da organização, como um todo, encaixa com a última fala da Ias. Nas três dimensões de times, de times de times, e de organização, de agilidade organizacional de negócios, você tem ações, ritos e práticas específicas para esse pilar. Tem ainda a mesma coisa no pilar de governança e os outros dois pilares que eu acho que a gente não falou e que vai acontecer igual.
M3: Exatamente, e o pilar de produtos, só para a gente passar para o próximo, nessa dimensão que o Régis comentou, do enterprise business agility é, em última instância, a implementação da estratégia da empresa, seja no curto ou longo prazo. Como a empresa traça seus road maps de produto, no curto prazo ela está gerando valor para sustentar o negócio dela, sobreviver e fazer a lojinha rodar, mas também está criando todo um arcabouço de longo prazo e então, até para a gente entrar no próximo pilar, que é o que vai sustentar isso tudo, do ponto de vista de tecnologia, que é o pilar de engenharia. A gente traz esse terceiro pilar, muito forte e, na minha opinião, tão importante quanto os demais mesmo. Isso é muito interessante, eu falo com a turma de pessoal que trabalha no pilar de governança ainda tem um desafio adicional que é garantir o equilíbrio entre os pilares. Quando você pega uma organização que está muito forte em um pilar mas fraca em outro, ela vai ficar meio disfuncional e o resultado normalmente não é o que a empresa quer ter. Os pilares são muito complementares nesse sentido. Então, no pilar de engenharia, a gente está falando de todo o arcabouço técnico que precisa para implementar essa estratégia da empresa dentro de produtos digitais. A gente está falando de arquitetura, software, de devOps, de nuvem, devSecOps, de todas as técnicas, processos e ferramentas que a gente precisar para sustentar esse pilar de produto. É como se a gente pudesse pegar os nossos arquitetos, que são as principais pessoas que sustentam esse pilar, e eles tivessem esse desafio. Como eu vou garantir a operação dos meus produtos digitais dentro das melhores práticas que existem hoje no mercado, mas como vou construir também essa ponte para o futuro próximo ou para o futuro daqui alguns anos, garantindo uma sustentabilidade do road map de produto alinhado com a estratégia do negócio. É um pilar super desafiador e toda empresa praticamente tem uma área de arquitetura, mas a gente vê poucas empresas tratando esse pilar de engenharia com essa amplitude que a gente julga necessária para escalar toda dessa estrutura.
M1: Só um comentário que eu queria fazer é que esse pilar é subestimado, no seguinte sentido: tem arquiteto, não tem dúvida que as empresas pensam nisso, mas é impossível cumprir a promessa da agilidade e a intenção é muito realmente liberação de valor, via ativo digital. É impossível você se inspirar na Netflix e na Amazon sem você investir o suficiente para quebrar os legados, ter devOps, poder fazer experimentação. É um negócio às vezes até incoerente. Se você foca só na governança e cria cultura de produto, mas você tem uma série de gargalos e obstáculos que impedem de cumprir essas promessas, você não vai cumprir essa promessa. Eu gosto de falar isso porque, até conversando com um cliente, essa é uma visão pragmática. Eu sempre falo no podcast dos céticos e pragmáticos, não é porque Televox está na moda, é porque realmente não tem jeito de cumprir a promessa, fazer experimentação e entrega contínua, colocar uma coisa no ar e voltar rápido, se você não investe no pilar de engenharia. Claro, vai investir continuamente, não é que você vai ficar construindo todo um pilar e, da mesma forma, como o Régis explicou, esse pilar também vai evoluindo conforme a empresa concede, vai depender e ser mais simples se você está cuidando dele, primeiramente, no âmbito só de um time, e vai ser mais complexo quando começa a integrar vários times, igual o resto dos pilares, mas continua sendo algo que não se pode negligenciar. Não é isso, Régis?
M2: Tem um exemplo, minha memória é meio ruim, mas acho que é do Spotify, que ilustra bem a importância da área de engenharia na agilidade de escala, que parece que são organizados, se você pensa no aplicativo do Spotify, para computador, tem uma turma que é responsável pela busca de músicas ser a mais eficiente possível, buscar por letra, alguns critérios para ser mais efetivo. Tem um outro time que vai cuidar as recomendações, ou seja, daquilo que o Spotify te sugere baseado naquilo que você escutou. Tem um outro time que é baseado na experiência da qualidade do áudio mesmo, o streaming. Tem vários times dentro de um mesmo produto trabalhando em paralelo e se não me engano, por isso que falei que minha memória às vezes me trai, eles só conseguiram esse nível de independência quando quebraram a estrutura técnica deles para permitir que cada time pudesse desenvolver e publicar de forma independente do outro. Existe uma decisão racional de qual arquitetura vamos utilizar que destrave o valor dos times. Se não me engano, eles foram para os serviços para desacoplar as bases de dados e às vezes a gente não enxerga isso, que a decisão de engenharia que você toma tem influência e resultado direto no quanto de valor que seus times conseguem entregar. Obviamente que a partir do momento que você tem mais de um time, um conjunto de times, você vai precisar de uma pessoa ou de um conjunto de pessoas olhando para esse pilar em níveis de consolidação da organização mais altos para poder tomar essas decisões, sejam em nível maior do que o próprio time.
M1: Já falamos de três pilares, governança, produto e engenharia. Eu peço a Ias que fale do último sem o qual nada aconteceria.
F1: Por último mas, de forma nenhuma, menos importante, o pilar de pessoas. Essa brincadeira toda que a gente está falando são as pessoas que estão fazendo. Então essa transformação vai acabar criando na organização novos papeis, novas práticas, vai exigir novos comportamentos, vai mudar muita coisa em como as pessoas se relacionam. É necessário pensar, e com muito carinho, nesse pilar de pessoas, como a gente está capacitando os colaboradores para atuarem nesse novo cenário, como a gente está dando segurança psicológica para eles enfrentarem esses desafios, riscos e eventuais erros que vão acontecer, contratando, retendo talentos, como está criando uma estrutura que permite também aprendizado, melhoria contínua dessas pessoas, para que elas também se sintam empoderadas nessa jornada, envolvendo-as, claro, nessa transformação. Está por último, mas a gente vê o quão crítico é, para que todos os outros aconteçam.
M3: Eu comento que esse pode ser chamado de pilar Peter Drucker, que fala que a cultura come a estratégia no café da manhã. É como se a gente tivesse que ter um foco muito forte com as pessoas, porque estamos falando de transformação cultural, do novo mindset para atuar, mesmo que a empresa já venha trabalhando com nível de times ágeis muito forte, se ainda não está trabalhando nas outras dimensões que a gente colocou, da interação entre os times e, principalmente, do enterprise business agility, vai vir muita mudança na forma de pensar, no mindset. Quando a gente falar de mudar a forma que a gente vai aprender, baseado nas interações dos times ágeis, a mudança é muito forte. Se a gente não tiver um foco pesado nas pessoas, entender que as pessoas estão passando por mudanças e vão passar a se comportar um pouco diferente, vão ser avaliadas de forma diferente. Por exemplo, nessa estrutura, o resultado da tribo é muito mais importante que o resultado do squad. Pode acontecer, e eu já vi acontecer várias vezes na prática, de um squad, em determinado momento, sacrificar totalmente o tempo de suas entregas em prol da tribo, do resultado dos times, de forma mais ampla. Mas imagina se as pessoas daquele squad são avaliadas pelo resultado do squad, e não pelo resultado da tribo, ou da organização? Como fica o incentivo para as pessoas? A coisa não fecha. Se você não toma cuidado nesse aspecto, inclusive emocional do ser humano, essa mudança não vai acontecer, ou vai ser de forma muito forçada, e na prática não vai parar de pé, vai ser um castelo de cartas que, com qualquer turbulência, cai para trás.
M1: É engraçado, uma das coisas que a gente mais fala, sobre gente, e a verdade é que se as pessoas não mudarem seus próprios modelos mentais de enxergar o mundo, aprender a lidar com incerteza, elas nunca vão nem aceitar esse modelo que a gente está falando, esse caminho não linear que a gente sugere vai agredir muita gente, pelo jeito que a pessoa está acostumada a se comportar. Fazendo uma breve síntese, porque quero partir para um próximo tema que acho super relevante, a gente falou até agora o seguinte: eu quero ficar ágil. Para ficar ágil, existem três dimensões com as quais eu devo me preocupar o tempo todo, continuamente, que são a agilidade no nível time, sincronização de times e nível corporativo. Enquanto me preocupo com isso, tem pilares que o tempo todo tem que ser reforçados em função de dados, que tem a ver com governança, engenharia, gente e produto. Ainda assim, como as pessoas gostam de enxergar o caminho mais claro, ainda fica a pergunta: como eu começo? Tudo bem, a minha situação é particular, mas tem algum tipo de caminho inicial que eu deveria trilhar, ainda que a partir daquele caminho meu contexto vai influenciar fortemente e eu vou estar seguindo meu caminho, vai ter negócio com mais pressão e ter que ir mais rápido, negócio com menos pessoas vai mais devagar, tem negócio que é mais customer do que outro. Enfim, o contexto vai mudar tudo, mas tem algum tipo de recomendação para começar?
F1: Eu acho que o Lucas vai ser um bom candidato para responder essa pergunta capciosa. É só para dizer para desencargo de consciência, para a gente deixar isso bem claro. Isso tem que ser tratado como uma iniciativa ágil em si mesmo. Se você olha para isso que a gente está falando, essas três dimensões, para esses quatro pilares, você imagina logo de cara: legal, deixa eu fazer um plano de como vou impactar cada um deles e fazer um cronograma para dentro dos próximos dois anos eu resolver todos os meus problemas, em todas as dimensões, em todos os pilares. Já deu ruim, por natureza. Se a gente está falando de transformar a empresa para se tornar mais ágil, aceitar que a mudança é ágil em si mesma, que ela exige aprendizado, revisão de rota o tempo inteiro e exige a sensibilidade para conseguir experimentar, eu acho que é extremamente importante e é bom sempre falar.
M1: Não vai ter um marco, um dia que a gente foi ágil.
M3: Muita gente gostaria que tivesse. Mas a gente acredita que não.
M2: Se a empresa chamar marco.
M3: Exatamente, talvez seja o único. Respondendo a sua pergunta, a melhor forma de começar, na nossa visão, é pela liderança. A gente acredita que, se há uma iniciativa ágil e a gente precisa realmente avançar, precisa que a liderança se comporte assim. O que deve ser feito no primeiro momento é que a liderança seja um squad ágil, e isso é muito importante, porque tem vários desdobramentos essenciais que vão ajudar a desenvolver a estratégia dessa transformação. Primeiro desdobramento é, se o time se comporta de forma ágil, todas as equipes vão enxergar na liderança um comportamento a ser buscado. Você tem o primeiro passo muito forte para mudança cultural e quebra de paradigmas. Se você tem um squad de liderança ágil, esse squad vai ser habilitador, não prescritivo. Ele vai buscar olhar para organização e habilitar, porque a empresa pode estar em diferentes níveis ainda, e começar já com esse squad. Lembra que a gente falou, que as três dimensões não são modelos de maturidade, então a gente precisa trabalhar de uma forma baseada em onde estou hoje. Seria como se esse squad trabalhasse assim: se sou squad, preciso ter um backlog. Minha missão é facilitar e viabilizar a transformação digital através das práticas de agilidade em escala. Como vou fazer? Primeiro, um diagnóstico de onde estou e avaliar os times? Vou ver se estou bem no pilar de engenharia, no de pessoas, se não estou? Esse squad de liderança, através do que a gente chama de enterprise backlog, vai priorizando as ações para poder estruturar os quatro pilares de tempos em tempos, aumentando o nível de maturidade em cada uma das dimensões.
M1: Só um comentário. Acho tão importante e interessante salientar, porque tem duas implicações, uma muito do que você falou e uma um pouco mais escondida. Esse é o time que quer fazer a mudança acontecer e já faz acontecer fazendo-a de forma ágil. Esse time não começa com cronograma detalhado, começa com backlog, a tentar colher resultados em curto prazo, aprender com o que colheu. Isso, por si só, já é o próprio time dando mensagem para a organização e mostrando, por exemplo, como atuar e servindo como habilitador. Outra mudança grande é que esse time é do alto nível, por promover mudanças fortes na organização, mas sendo ágil, tem que estar próxima da ação. Isso é fundamental. Você tem que estar muito mais perto da ação. Por isso acho interessante mostrar essas duas coisas acontecendo. O Lucas respondeu bem objetivo, de um lado, tem uma empresa que pretende ficar ágil e já começa com um time que começa a ser ágil, ter backlog, com processos de aprendizado e muda a expectativa de como isso vai acontecer dentro da própria empresa, e se aproxima de onde a ação acontece, mas essa minha frase implica na ação acontecer em algum lugar. De que forma essa ação começa a acontecer também? Deixar para o Régis agora. De um lado, começo a formar esse time. O que eu faço lá? Não tem prescrição, mas me fala, Régis, o que eu faço ali?
M2: Eu não sei se eu vou responder exatamente a sua pergunta, porque, para nós, ficou evidente que esse é o primeiro passo de um negócio que não é sequencial. É a primeira preocupação, você ter uma liderança que esteja engajada, que entenda os valores e como a organização vai passar a operar e esteja disposta a operar dessa forma. Por isso que é o primeiro passo. A gente está falando que as dimensões são sensibilizadas simultaneamente, então você não precisa esperar, não faz sentido, no squad de liderança, estar perfeitamente azeitada no seu dia a dia, funcionamento como um squad ágil para você começar a times ágeis. Então, na verdade, concomitante a essa transformação da liderança, se a empresa não tem nenhum squad ágil, ela tem que buscar ter um squad verdadeiramente ágil para começar a exercitar a dimensão do time. A gente já defende que esse time seja colocado para resolver um problema que seja relevante e que ele seja colocado, tendo em vista o que a gente chama de um trabalho de taxonomia, ou seja, de mapeamento do fluxo de valor da organização, das dores existentes nesse fluxo de valor atualmente, e a partir dessas dores, esses times sejam alocados com uma missão de resolver, de sensibilizar ou de melhorar o fluxo de valor naquele ponto que ele está alocado. A partir do squad de liderança desse time ágil, eu diria que estão aí as melhores sementes para começar a fazer esse movimento. Não sei se o Lucas gostaria de completar.
M3: É isso mesmo. Uma vez que o time está ali, vivendo e destravando os desafios que os times ágeis que estão trabalhando nos produtos digitais estão encontrando, a coisa vai tomando corpo e a gente acredita muito e está vendo na prática isso acontecer, com vários dos nossos clientes, que é o dia a dia que vai dizer a pauta prioritária desse time. Não dá para falar, cada organização é um organismo vivo e vai responder de forma diferente. Vão ter empresas que vão precisar trabalhar muito mais, por exemplo, na dimensão enterprise, porque isso vai gerar muito mais valor no processo digital. Em outras empresas, pela característica do negócio, isso talvez não seja tão relevante e é muito melhor, vai fazer muito mais resultado, pelo menos no curto prazo, azeitando mais a interação entre os times, porque isso pode estar até de forma caótica hoje, dependendo do cenário que a empresa está trabalhando. Quando olhar os pilares, é a mesma coisa. Você vai ter empresas que a aceitação da mudança vai ser muito mais fácil e o seu esforço no pilar de pessoas talvez seja menor. Vai ter outras que você precisa até começar do zero, fazer até uma campanha até mais ampla de mudança, porque o choque cultural pode ser muito grande. Mas se a estratégia da empresa mostrar que precisa fazer isso porque quer realmente ser digital, precisa passar por essa transformação, vai ter que enfrentar e pegar o boi pelo chifre. De novo, acho que a beleza e ao mesmo tempo a grande dificuldade disso é que a gente tem uma convicção muito clara do primeiro passo, mas não tem visibilidade nenhuma para generalizar o segundo, terceiro e o quarto passo. Vai depender muito da organização.
M1: Eu acho interessante, porque é o que a gente sempre fala. Da palestra que falo de business agility, sempre falo que a gente tem que ter um processo de mudança que convide a ação, e o processo de mudança tradicional, muitas vezes, causa imobilização, porque cognitivamente é quase impossível saber o que a empresa vai virar, já que, pelo que a gente falou, imagine, na medida em que você começa a ter uma dinâmica de novos times surgindo e uma liderança habilitadora que vai removendo obstáculos e promovendo mudanças que permitam que esses times floresçam, isso vai fazendo com que a empresa tenha ações em todos os pilares e em todas as dimensões que a gente disse. Isso é um negócio completamente vivo que vai acontecendo e, por exemplo, às vezes, essa dimensão pessoas, alguém vai evoluir. Isso acontece na DTI, é muito comum ter uma evolução de uma certa prática de gestão excelente dentro de uma tribo e, daqui a pouco, aquela prática vai se espalhar pela empresa. Ao mesmo tempo você pode ter uma evolução de governança em algum lugar, e aquilo vai espalhar. O que eu estou querendo ilustrar é que realmente é algo extremamente dinâmico e que não cabe à liderança controlar isso, cabe à liderança observar, sentir, responder, habilitar, tirar as tensões organizacionais e ser esse jardineiro que a gente fala sempre. Isso é muito difícil de se compreender, até que você faça. Para mim, isso é o grande problema do ágil, que torna a sua adoção tão difícil. Dá uma sensação de desconforto tão grande. Quem começou o episódio pensando que finalmente teria uma prescrição, termina desse jeito.
F1: Já desligou, já fechou o episódio.
M1: Isso que eu acho engraçado. Eu pediria aos ouvintes que, se você der esse estímulo inicial para seu sistema e começar a trabalhar como habilitador disso tudo que a gente está falando, usando os pilares de dimensões para lembrar continuamente que não pode negligenciar e de onde pode chegar, naturalmente esse organismo vai evoluindo e virando um organismo ágil. É curioso, porque quando a gente pensa no fardo de alguém pensar no que vai ser feito, dá vontade de desistir. É sempre essa sensação, ainda mais as organizações extremamente complexas, enormes, que existem.
M3: Vou fazer até uma provocação, um pedido para você. Uma das coisas que mais gosto na vida é de passar tarefa para os outros e acompanhar o plano de ação. Estou brincando.
M1: Vai cair aqui.
M3: O João está aqui e vai nos ajudar. Brincadeiras à parte, isso que você falou é importante. O pessoal que está escutando isso, muita gente buscando informação, acho que vale depois a gente trazer mais especialistas em cada um dos pilares, que estão vivendo isso na prática, para ter um foco. Não sei se cabe em um podcast inteiro, mas dá para ter um foco dos problemas mais concretos que cada pilar desse vivencia. Eu não estou generalizando que todas as empresas vão ter os mesmos problemas, mas acho que os tipos de problemas que as empresas estão tendo hoje, para distanciar esses pilares de forma verdadeira, como você comentou, a área de engenharia é muito mais que arquitetura, e como fazer isso na prática, quais são as barreiras para isso, os cases de sucesso acontecendo, em maior ou menor grau, a governança ágil a mesma coisa, como a gente debruça nisso de forma mais concreta e vê isso acontecendo. Em um momento oportuno, seria legal a gente aprofundar nesses pilares, para ajudar a tangibilizar mais para o pessoal que está escutando como, na prática, isso sai do lugar.
M1: Perfeito. Com certeza, acho que seriam episódios bem ricos. Pessoal, chegamos ao final, gostei muito da conversa, eu volto ao que falei anteriormente, isso parece um pouco com (inint), em que você começa querendo algum tipo de prescrição. Vamos montar um time, botar um time verdadeiro, vamos fazer isso, aquilo. Ok, na medida em que você vai avançando, a empresa vai ficando viva e isso vai acontecer de uma forma muito mais natural do que parece. Isso vai ficando natural, porque vira uma tarefa de muitos times e muitas pessoas, uma inteligência coletiva cujo o squad de liderança está sendo apenas um facilitador, alguém tem visão sistêmica, um conector, e não alguém está tendo aquela responsabilidade quase impossível de controlar e saber tudo que vai acontecer de antemão. Então, em vez disso causar angústia, devia causar alívio, porque a responsabilidade está distribuída e compartilhada. Um abraço para todos.
