Saiba tudo sobre cultura ágil pelos experts da dti.

Ouça e acompanhe nas plataformas abaixo.

SoundCloud
Spotify
iTunes

M1: Boa tarde, boa noite. Estamos aqui em mais um episódio dos agilistas. Estou aqui com o Vinição.

M2: E aí, pessoal, tudo bom?

M1: E com Felipão.

M3: E aí, galera, beleza?

M1: Apresentando eles informalmente, porque eles já são íntimos de quem está ouvindo o podcast. Então, gente, o tema que eu queria trazer hoje era a gente discutir um pouquinho mais sobre pensamento sistêmico, que é um tema que é muito relacionado ao tema que a gente abordou no último podcast sobre complexidade. A principal mensagem do último podcast era a de que a gente tem que admitir que existem tipos de problemas para o quais a gente não consegue estabelecer uma relação de causa e efeito tão claro e que a gente tem que fazer uma experimentação, e que isso é uma verdade difícil de ser aceita, principalmente, por quem é mais inteligente e tem mais visão analítica. O que a gente queria falar aqui agora, um pouco, que é sobre o pensamento sistêmico, é mostrar o que também para essa categoria de problema é possível reconhecer certo padrões que a literatura chama de arquétipos, que vão te dar uma dica do que você poderia fazer para mudar o comportamento daquele sistema.

M2: É o tentar reconhecer um padrão que é emergente ali. Não é porque o sistema é complexo que é difícil de ter previsibilidade de relação de causa e efeito que não dá para fazer nada.

M1: Exatamente. Esse negócio é engraçado, porque existem brigas entre as escolas, existem as vaidades dos autores, divergências.

M2: Alguns autores colocam um corpo de conhecimento, de complexidade, de forma geral, colocando pensamento sistêmico, teoria de jogos e uma série de teorias. O próprio (inint) [00:02:03] já falava na década de cinquenta em várias coisas que estão relacionadas a isso.

M1: Ao pensamento sistêmico, não é?

M2: É.

M1: Mas o que eu acho interessante é isso. Nós não somos puristas. Então, alguém pode ouvir isso de que é impossível conciliar exatamente a teoria da complexidade (inint) [00:02:20] com um pensamento sistêmico. Assim, a gente está menos preocupado com isso e mais preocupado em compartilhar com vocês conhecimentos práticos que a gente tenta usar aqui na DTI e nos nossos clientes a partir dessa leitura e desse estudo constante que a gente faz. Antes de entrar nos arquétipos, eu queria dar um exemplo que eu acho que ilustra bem isso. O que aconteceu no mundo do software até começar o movimento agilista, digamos assim, se a gente for pensar? O mundo do software foi caracterizado pelo quê? Cada vez mais você tinha a TI tentando fazer software de uma forma cada vez mais prescritiva, com metodologias que, depois, foram chamadas de metodologias pesadas, ou seja, que descrevia o processo inteiro de cabo a rabo e o que você tinha que fazer, quais os entregáveis, e a despeito de cada vez mais você ter tecnologias cada vez mais prescritivas e que detalhavam tudo o que tinha que ser feito, o cenário da TI era horroroso.

M2: É como, às vezes, até você mesmo comenta, quando esse pessoal enxergar o desenvolvimento de software, vai falar assim, “Nossa, é muito caótico”, até puxando para o lado de teoria de sistemas e falando assim, “Não, nós temos que trazer esse negócio mais para o lado da ordem, não é?”, e aí começou uma série de descrições aí.

M1: Exatamente. Se você pensar na atividade de desenvolvimento de software, ela é relativamente nova. Então, o primeiro passo que os caras tentaram foi colocar ordem nisso, igual a gente fala ali no outro podcast.

M2: É pegar os ensinamentos da lei de engenharia, de arquitetura. Você vê até pela nomenclatura. Você vê engenheira de software ou arquiteto de software, uma série de coisas desse tipo.

M1: Você tirou isso da minha boca. Engenharia de software foi um termo que foi cunhado à luz de tentar fazer o desenvolvimento de software virar uma prática tão segura quanto o desenvolvimento de software. O que está por trás muito da engenharia, quando você tenta fazer virar uma engenheria, é o quê? Olha, eu vou detalhar tudo muito bem detalhado, depois é uma mera questão de execução. Por que eu estou falando isso aqui? Porque a despeito disso ter sido feito durante anos, você chegava nos anos dois mil e tinha relatórios mostrando que a maior parte dos projetos era um fracasso total, tanto do ponto de vista de prazo quanto de custo, e até pior, do ponto de vista de não atender à necessidade do cliente. Por que eu estou dando esse exemplo? Ele é o típico exemplo de você estar preso em um ciclo vicioso do qual você não consegue sair justamente porque você não tem uma visão sistêmica do que está acontecendo. Porque a forma de atuar a cada fracasso era sempre fazer um pouco mais do mesmo remédio, que era qual? Especificar um pouco mais, já que o jeito anterior deu errado. Então, assim, eu já participei de projetos com especificações de 700 páginas, e se um projeto desse der errado, o que você faz no próximo, se você pegar esse paradigma? Você especifica mais ainda, planeja mais ainda, detalha mais ainda.

M2: Inclusive, isso estende até um comportamento de um arquétipo, de um (inint) [00:05:44], que a gente vai falar daqui a pouquinho.

M1: Você vai lá e assina tudo com sangue para poder garantir.

M3: E é engraçado, é o que eu falo em alguns (inint) [00:05:54], que é coaching que a gente faz aqui na DTI, que uma das coisas que eu vejo que mais provoca um fracasso nesse modelo prescritivo e de tentativa de ser preditivo é, justamente, não levar em consideração que o mundo de desenvolvimento de software é um sistema altamente complexo, com n variáveis, e, às vezes, você tenta atacar uma variável apenas e nessa tentativa de prescrever tudo, a gente tem um grande problema, porque o time de desenvolvimento por si só já é um sistema altamente complexo com n variáveis, onde coisas podem acontecer e não é tão fácil de controlar, mas quando a gente pensa que a gente tem uma etapa, eu sempre falo que o problema é com a temporalidade das coisas. A gente tem uma etapa, mas fica três a seis meses para fazer uma especificação de 700 páginas, igual você está falando. Talvez, seja o único momento em que você leva em consideração uma variável muito importante, que é o cliente, que é o negócio. Aí você fica ali um ano desenvolvendo sem levar em consideração uma variável muito importante desse ambiente complexo, que é o cliente, que é o negócio. Coisas podem estar acontecendo nesse negócio que podem ir transformando aquela especificação enorme que você fez e validando, tomando ela altamente volátil.

M1: Sim. Então, mas o que eu queria mais salientar aqui, só para poder fechar a minha introdução, já está bem grande, é por que eu falei que você entra em um ciclo vicioso aí? Porque cada vez que dá errado, o paradigma é olhar e pensar o seguinte “Eu fiz a especificação errada” ou “Fulano não tinha experiência suficiente para fazer uma especificação, deveria ter enxergado que, na verdade, era necessário isso”, ou “A equipe não soube estimar bem os prazos”, “A equipe foi incompetente para isso”, “O usuário foi incompetente para pedir”. Enquanto alguém não olhar de uma forma um pouco mais distanciada o comportamento que emerge desse relacionamento entre as partes que estão tentando fazer esse software, ele não vai conseguir quebrar esse ciclo vicioso e, na verdade, esse ciclo vicioso é quebrado, e é isso que a metodologia ágil propõe no final das contas, ele é quebrado você admitindo que é errado procurar o escopo como sendo o seu principal objetivo. Então, na verdade, esse ciclo vicioso é quebrado você tendo uma posição de humildade, de saber que não sabe escopo e criar um tipo de incentivo para todo mundo que está naquele sistema, que seja o de procurar um resultado. “Estamos fazendo esse software para melhorar o atendimento. Vamos colocar a hipótese e vamos descobrir o que faz melhorar o atendimento”. E aí esses agentes, atores, o nome que a gente der, vão se organizar em torno desse objetivo e vão ter muito mais chance de aprender o que, realmente, é importante para gerar valor para o cliente, no caso, do que anteriormente, onde eles estavam fixamente procurando um determinado escopo, mesmo que aquele escopo não entregasse valor nenhum. Então, tudo isso aqui para fazer o seguinte, tem muitas situações em que você, aliás, eu diria que a maior parte das situações, o Vinição citou o (inint) [00:09:05] aí. Tem alguma frase, acho que é do (Demis) [00:09:08] mesmo, em que ele fala que as pessoas nunca batem o sistema. Oitenta ou noventa por cento dos problemas que você tem, na hora que você vai olhar você está preso a algum tipo de arquétipo que força aquele comportamento da pessoa.

M2: Só tem uma pessoa que pode bater o sistema, as pessoas que estão na função de gestão e direção, que são capazes de alterar a estrutura realmente do sistema.

M1: Exatamente. Não é que elas batem o sistema, mas elas conseguem, igual eu estava lendo até ontem, por coincidência, que é que a pessoa fica assim, “Ah, mas o que eu faço, então, já que o sistema está ali, acontecendo?”. Você pode criar estímulos e criar certas estruturas do sistema, mudar o relacionamento entre os agentes, mudar o símbolo de auto-organização, que aí vai acabar mudando o comportamento daquele sistema. Para ficar mais claro, eu sugiro então, Vinição, que você cite um tipo de (inint) [00:10:08], que eu chamo de arquétipo documentado, que acontece no sistema e mostra qual seria uma possível ação da liderança, já que a gente não quer deixar os líderes angustiados.

M2: Tem um (inint) [00:10:30] em que a dona (inint) [00:10:30] cita, que é fix that failed. Por que fix that failed? No sentido de que você tenta fazer ações sem reestruturar o sistema e o comportamento de feedback do sistema, tende a procurar um resultado, às vezes, pior ainda. Como assim? Vamos perguntar um exemplo de departamentos de empresa. Vamos pegar o desenvolvimento de software. Imagina que você tem três atores aí, as pessoas que especificam, por exemplo, as pessoas que codificam, desenvolvedores, e as pessoas que sustentam o sistema de produção, em termos de acompanhar os servidores. O cara que fica, muitas vezes, ali de noite, final de semana, então, é difícil. Então, cada um desses departamentos ou atores, muitas vezes, tem objetivos que são locais, que são metas ou objetivos daquela parte do sistema. Se você olhar só aquela parte, parece que está fazendo sentido, mas quando você olha no todo, muitas vezes, não faz. Então, por exemplo, a preocupação, as metas de quem está, vamos dizer assim, fazendo a documentação, é documentar, muitas vezes, o mais detalhado possível. Então, o cara vai se preocupar muito com isso, o máximo possível, mesmo que, vamos dizer assim, demore muito tempo, aquele requisito nem faça mais sentido e por aí vai. Já o desenvolvedor, muitas vezes, é cobrado por entregar o mais rápido possível também o código para poder ser colocado em produção, não importa que o código seja esse. E o departamento de operações, muitas vezes, tem que sustentar e não deixar o sistema cair de jeito nenhum, não dar problema de performance, que está vinculado com servidores e por aí vai. Então, por exemplo, imagina no caso do desenvolvedor. Se ele é cobrado, se a gestão começa a pressionar ele para entregar mais rápido mais código, o que ele vai fazer igual o Felipão às vezes fala, que é assim, ele vai começar, às vezes, a abandonar o (inint) [00:12:35].

M1: Só um negócio. O fix de que você está falando aí é tipo assim, a gestão acha que o negócio vai atrasar e aí ela vai e cobra um prazo a mais?

M2: Ela tenta fazer uma intervenção para poder ter resultado e resolver o problema.

M1: Posso dar um exemplo claro disso? O Felipão já deve ter visto isso. O Felipão pode falar de fix that don’t fail, porque ele é bom para chegar em equipes que estão precisando de ajuda, mas uma coisa muito clara é o quê? Botar mais recurso. Isso é típico fix that fail.

M3: É uma piadinha clássica de que nove mulheres não vão fazer um filho em um mês.

M1: Mas não é verdade? O que mais acontece em um time que está com o perigo de não cumprir um prazo?

M3: É abandonar rito, é tentar aumentar a capacidade da equipe, ainda que seja aquele desejo artificial.

M1: Mas só um comentário. Esse exemplo é interessante, porque, olha só, a gente tem que voltar sempre para tentar mostrar para quem está ouvindo o que isso tem a ver com o pensamento sistêmico. Eu acho interessante, porque quando você bota mais um recurso e acredita, simplesmente, que ele tem um efeito sozinho de acelerar o desenvolvimento, é como se você ignorasse completamente justamente o efeito sistêmico que ele tem nas interações entre os diversos elementos. Eu acho que é um exemplo bem interessante, porque, imagina, quando você bota mais um cara ali dentro, ele causa um distúrbio.

M3: Ele gera uma série de necessidades que nem existiam ainda.

M1: O líder vai dedicar um tempo a ele. Ao dedicar tempo a ele, vai parar de dedicar tempo a um cara. O líder vai ficar um pouco mais estressado do que ele estava.

M2: Quando é só um está até bom. Muitas vezes, a gestão vai lá e bota cinco de uma vez.

M1: Faz uma conta aritmética. É como se lineariza. Isso é interessante, porque isso é uma linearização completa do problema. Esse nove mulheres fazem o filho é uma linearização completa. Eu boto mais dois caras aqui e está resolvido, porque eu vou aumentar a velocidade tantos por cento. Na verdade, ele vai diminuir a velocidade.

M3: Pelo menos, no curto prazo.

M2: Inclusive, Shuster, você falou e é bem interessante, porque uma das características do pensamento sistêmico é, exatamente, esse entendimento e aceitação que existe uma série de coisas que não são lineares. Você acabou de falar uma característica bem importante. Se você não entende isso aí, você vai ficar fazendo contas e raciocínios completamente lineares, tipo esses que você acabou de falar. Um outro exemplo que você também já meio que falou um pouquinho no início desse episódio é, exatamente, o outro fix. “Nós falhamos na última entrega, então vamos detalhar mais”. Por isso que eu coloquei essa figura do departamento de especificações. Já que não funcionou, então o que eu tenho que fazer? Eu tenho que detalhar mais ainda, o outro fix that fail.

M3: Olha que interessante. Enquanto o Shuster falava ali, eu comecei a lembrar vividamente de um caso dessas intervenções que eu fiz de um time que estava com alguns problemas, e foi exatamente isso. Quando a gente pensa em um sistema com diversos atores e diversas variáveis, houve, nesse caso, uma tendência em acreditar que a única variável que estava afetando a possibilidade de entregar o sistema no prazo era a performance do time. Então, quando eu cheguei no time, todos esses anti (inint) [00:15:53] que vocês citaram estavam instalados no time. O time estava inchado, porque antes dessa intervenção acreditou-se que “Ah, não, o time está com baixa performance, então vamos aceitar a baixa performance, mas vamos colocar mais pessoas para aumentar a performance. Vocês já falaram o que aconteceu? A performance caiu ainda mais. Outra coisa que aconteceu por uma pressão que veio da gestão, do cliente, foi abandono dos ritos. Foi deixar de fazer todos aqueles ritos que a gente já citou em capítulos anteriores do podcast, que é o que a gente faz para tentar reduzir a exposição à complexidade. Então, quando eu cheguei a primeira coisa que eu fiz foi fazer uma avaliação e retomar a execução dos ritos. E é engraçado que o time estava tão crente, estava com uma crença tão forte de que a evolução do cenário estava melhorando a situação, que eles me questionaram em relação a retomar os ritos. Eu falei assim, “Ainda que a gente perca um pouco de produtividade”, porque eles acreditaram que a gente ia perder ainda mais se a gente retomasse os ritos, “Ainda que a gente perca um pouco de produtividade, vamos retomar os ritos”. Uma outra coisa que eu fiz também foi reduzir o time. Tirei duas pessoas do time. Nesse momento, o gerente do projeto quase que arrancou os cabelos. Falou, “Pera aí, a gente está precisando entregar e você está diminuindo a capacidade do time?”. Eu falei, “Vamos fazer esse experimento”. Com dois ou três dias a velocidade esperada do time, a quantidade de pontos que a gente tinha que queimar voltou ao que era originalmente esperado. Aí o time acalmou, ganhou confiança e conseguiu retomar o curso.

M1: Bem legal. Vamos ver outro exemplo.

M2: Só complementando, porque eu acho que tem uma pegada nesse exemplo que envolve quase que nem esse episódio, envolve o podcast, o tema do podcast. Só falando do último ator aí, que é o cara de operações. Então, o incentivo dele é o quê? Burocratizar ainda mais.

M1: A iniciativa dele não é botar nada no ar.

M1: Exatamente. Se ele é punido por isso, o que ele vai fazer? Ele vai ficar na retranca total. Então, vamos pensar bem nesse exemplo. Você tem três atores. Claro que tem mais, mas a gente está pensando em três atores. Nesse exemplo, o que tem para fazer? Só chorar, lamentar e não tem nada para fazer? Não. A principal solução no arranjo sistêmico aí é exatamente a nossa célula de produção, que é o squad. O redesenho sistêmico para você sair desse partner aí ou pelo menos o caminho na direção é, exatamente, de você tirar as pessoas dos departamentos, montar uma célula pequena com as disciplinas que estão envolvidas, que eu falei aqui. O cara que faz a especificação, o cara que faz o código, vamos dizer assim e o cara que sustenta operações, que virou o famoso (inint) [00:19:00]. Então, quando você tem esses três elementos dentro do squad, o objetivo do squad não é um objetivo local, de cada um. O objetivo é colocar, no mínimo, no pior caso, colocar o código em produção. No melhor caso, é gerar valor igual o (inint) [00:19:18] falou nos episódios anteriores, que colocar código de produção não é sinônimo de agregar valor. Eu só quis encerrar com esse exemplo.

M1: É bem interessante para a gente, porque você muda o relacionamento entre os atores, você muda os objetivos que eles vão perseguir, que vai ter um objetivo comum agora, ao invés de ficar ali massacrando um. Porque, assim, desse jeito que a gente fala parece óbvio, mas isso acontece todos os dias em todas as organizações. O sistema não entrou no ar, alguém vai massacrar o cara que não colocou o sistema no ar. O sistema entrou no ar e faltou requisito que vai massacrar o cara que não especificou requisito. Se o cara se defender falando que algum usuário chave não especificou o requisito certo, eles vão massacrar o usuário chave que não especificou o requisito certo e vão fazer isso anos e anos. Vamos dar o exemplo, só para o pessoal entender, porque o que eu acho mais legal é, justamente, esse sistema tem muito a ver com essa questão dinâmica. Quando a gente pensa em um sistema, é sempre uma coisa emergente e dinâmica que surge das interações entre os agentes, não é? E a visão da empresa, muitas vezes, é uma visão muito estática, de que você projetou a empresa com uma determinada estrutura e aquela estrutura vai dar certo, e além de ser estática, subestima muito as relações entre os agentes, porque, simplesmente, acredita que tudo está reduzido a fazer determinadas tarefas e, uma vez que elas sejam feitas, tudo vai dar certo. Então, qual outro exemplo você trouxe para a gente, Vinição, de algum outro arquétipo?

M2: Um outro arquétipo que a (inint) [00:20:59] também cita é o (shifting the birding to the) [00:21:02] (inint) [00:21:02] ou adction, um vício, de você transferir a responsabilidade, o fardo, para um outro ator. Um exemplo clássico, até pelo nome mesmo, é a droga. Então, você tem como se fosse um objetivo seu, que é estar bem, você se mede, de ver assim, “Não estou bem”. Ao invés de você tentar reestruturar, tentar deixar só a sua organização fazer com que você fique bem, praticando exercício, conversando, resolvendo os problemas que você tem, você utiliza um interventor, nesse caso a droga, para fazer com que sua medição, sou sensor interno, seja meio que alterado e você passe a medir “Agora eu estou bem”. Qual é o problema disso? Você mina completamente a sua auto-organização interna, porque você acha que está bem e, então, não tem nada de errado.

M1: Posso dar um exemplo de (shifting the birding) [00:21:57] para pais, que os pais vão reconhecer fácil? É o para casa dos filhos. As crianças, é impressionante hoje em dia. Eu ficava brincando com os meus meninos, que eu falava, “Eu só ajudo a fazer se eu achar que a dúvida é legítima”, porque eu sentia esse fardo vindo para o meu lado toda hora. “Mas eu não consigo fazer isso, o meu cérebro não está conseguindo pensar mais”. Eu já ouvi frases desse tipo. Então, esse é um arquétipo bastante comum e é engraçado. O Felipão vai dar um exemplo. Isso acontece nos times de software, não acontece?

M3: Acontece demais. Até no mesmo exemplo que eu utilizei para o último arquétipo, no mesmo caso esse também se instalou e, na verdade, todos os times que estão em um processo de crise que eu me aproximo, no primeiro momento esse arquétipo, especificamente, aparece, porque o time acaba dando uma relaxada, acreditando que o interventor, no caso eu, vou resolver todos os problemas, quando, na verdade, eu vou ajudar a sintonizar o sistema para que o sistema consiga se recuperar. Eu até brinco que, talvez, até no primeiro momento o efeito não seja tão negativo, porque eles esperam que a senioridade vá resolver o problema, então, eles relaxam. E uma das coisas que realmente é interessante que o time em crise consiga alcançar é relaxar, é reduzir a exposição ao problema, mas se isso se permanecer, se a transferência do fato do interventor permanecer, aí é altamente maléfico, porque ainda que esse interventor consiga, realmente, resolver o problema, você não resolveu o problema do sistema.

M2: É isso que eu ia falar. Para esse tipo de padrão, de (inint) [00:23:49], normalmente, você tem que conjugar uma ação de curto prazo com uma de médio e de longo prazo. Por exemplo, no caso do (inint) [00:23:55] vou voltar no exemplo mais social de drogas. Muitas vezes, ele vai ter que usar quase que uma outra droga, que é um remédio, para poder se acalmar, mas com uma medida de longo prazo, para poder se reestruturar internamente. Então, não é que esse tipo de partner, às vezes, tem que ser utilizada uma ação de interventor.

M1: Esse (shifting the birding) [00:24:19] adction é muito bom se for assim ou não muito bom o que ele significa, porque muitas empresas onde não há autonomia e são hierárquicas, elas sofrem desse adction, ou seja, as equipe estão ali, sempre esperando que alguém vai dar a solução para os principais problemas. É isso que eu sempre queria salientar em cada exemplo que a gente dá, essa dinâmica é uma dinâmica que emerge do relacionamento entre as partes. Então, não adianta alguém chegar e falar assim, “Nossa, essa equipe nunca consegue, realmente, assumir a responsabilidade e fazer o que ela tinha que fazer”. Na hora que você for olhar, não é uma questão de culpar o sujeito. A estrutura está criando esse vício, então você tem que tirar esse vício. A gente tem uma prática para isso aqui, o Felipão ia comentar agora, porque é tirar o vício do sênior.

M3: Exatamente. Então, assim, é importante para as empresas, para quem está nos ouvindo, conhecer esses partners, porque conhecendo os efeitos desses partners ou anti partners a gente consegue se programar ou se preparar para identificá-los e evitá-los. Então, uma prática que a gente faz aqui para tentar evitar o partner acontecer dada a senioridade, o sênior sempre vai ser o interventor então o time sempre fica muito dependente do sênior, é uma prática que a gente chama de rodízio de DL. O DL é o nosso desenvolvedor líder, no caso, às vezes, uma pessoa com um pouco mais de experiência dentro da equipe e isso causa, exatamente, esse efeito em que o time sempre acredita que a responsabilidade pela qualidade, a responsabilidade pelo andamento é do sênior. Aí a gente pode causar um efeito sistêmico em longo prazo, que é, justamente, a gente entrar em um ambiente de crise, em uma falta do DL. O DL pegou dengue, por exemplo, pegou alguma gripe mais forte, o time não consegue se auto organizar. Então, a prática que a gente usa de rodízio de DL, entre sprints o DL passa, entre aspas, o comando ou a liderança, o papel de DL para um outro membro da equipe. Dessa forma, a gente consegue ampliar a senioridade do time e transferir para cada pessoa do time a sensação, a responsabilidade de que a gestão do time é compartilhada, não é simplesmente só do sênior, que a qualidade, que o andamento mesmo do trajeto é responsabilidade de todos.

M2: Até mesmo o próprio contato com o cliente. Como a gente presta serviço, tem uma interação com os clientes. Às vezes, essa interação é mais concentrada nos gerentes, nos school master e nas pessoas mais sênior. Então, nós estamos com uma temporada de dengue, então a pessoa lá está com dengue, aí o time não consegue você ter um solavanco. Às vezes, é muito forte. Agora, se você tem uma inversão de forma que uma das pessoas, que é o cara que é o braço direito, alguma coisa assim, começa a ter esse tipo de relação, e nesse momento o sênior está ainda no time, é muito menos traumático e é muito mais fácil fazer com que esse conhecimento seja transferido ou seja mais distribuído dentro do time.

M1: E esse mecanismo de rodízio, ele tanto ajuda a evitar esse anti partner quanto é também um mecanismo de anti fragilidade, que é um termo que a gente já usou em outros capítulos do podcast. Você torna o time muito mais antifrágil.

M1: Eu queria falar de um último só para o pessoal ver. São vários, mas só para ter um terceiro exemplo, diferente, que é esse de road (inint) [00:28:08]. Fala aí, Vinição, sobre. Nós estamos usando os termos originais, gente, não é porque a gente é chato e gosta de falar.

M2: Até para facilitar a pesquisa depois, vai ser mais fácil de achar. Esse trap de road (inint) [00:28:23] acontece quando existe uma prescrição muito grande e uma série de regras. Esse tipo de comportamento, às vezes, é feito pelas empresas porque tenta fazer com que imaginar o sistema com que está lidando, os times, os departamentos de pessoas no domínio que a gente fala (inint) [00:28:44] do complicado. Então, você fala assim, “Se eu colocar uma série de regras aqui de política, a minha inteligência organizacional está nesse negócio”. É diferente. Se você pega, você vê que está todo mundo correlacionado. Se você pega lá no manifesto ágil, você tem indivíduos e interações sobre processos e ferramentas, o que seria mais ou menos essas regras aí, você está priorizando as pessoas e as interações sobre as regras. Aí quando você tem muita regra, acontece o seguinte, os seres humanos vão e começam a aprender a lidar com essas regras e começam a subverter as regras, atingindo um objetivo, que é o objetivo e não a intenção original daquela regra, mas o que está escrito.

M1: Só vou dar um exemplo bem concreto. Aconteceu uma coisa aqui na DTI, que eu lembrei aqui e agora e achei interessante, porque o nome road (inint) [00:29:39] fica parecendo que é até maliciosamente, e não isso. Não quer dizer que a pessoa está sendo maliciosa, mas está mostrando como é que o ser humano tenta cumprir a regra que foi dada a ele. Às vezes, pode ser malicioso, mas, por exemplo, eu lembro que teve um time entre nós, que eles estavam sendo orientados ao (inint) [00:29:59] e os caras estavam tão doidos para bater um (inint) [00:30:04] que um (inint) [00:30:05] significava fazer uma experiência sobre uma determinada tecnologia ou um tipo de tecnologia em um cliente. Os caras fizeram um negócio que era completamente irrelevante só para poder falar o seguinte, “A gente fez aquela experiência”, e olha que engraçado, na verdade, a gente, isso foi até uma coisa marcante para mim, por isso que eu lembrei agora, porque o (OKR) [00:30:30] tem uma natureza diferente desse tipo de meta, vamos dizer assim, mais prescritiva e até mais estúpida, porque o (OKR) [00:30:38] é feito para ser uma coisa audaciosa, mas que você vai errar de vez em quando, justamente porque é audacioso. Como você quer aprender? É o que eu sempre falo aqui na DTI. Como a gente quer aprender? É muito melhor o cara falar, simplesmente, assim “Eu não estou conseguindo usar aquela tecnologia nesse cliente, nós não conseguimos fazer”.

M2: Sem contar que os (OKR) [00:30:58] são de curto prazo. São de períodos de tempo curtos, de forma que você não consegue, você vê que está funcionando, você muda ele.

M1: Olha que interessante, aí já vai para um outro assunto, que um dia nós vamos ter que abordar aqui, que é sobre segurança psicológica. Normalmente, um cara vai morrer de medo de falar que não cumpriu uma regra. Então, ele vai cumprir a regra até de forma imbecil, se necessário, porque naquele ambiente ele vai ficar com medo de não cumprir a regra. Então, você vê como é perigoso ficar criando regrinha.

M3: Esse road (inint) [00:31:28] tem uma piadinha até que sempre fica muito bem, que lá na Grécia antiga estava chegando muita notícia ruim no César, e aí eles criaram uma (inint) [00:31:40], que era reduzir o (OKR) [00:31:43] lá na Grécia antiga, que era reduzir o número de notícias ruins que chegavam. Aí o que eles fizeram? Mataram o mensageiro, para que não chegue mais notícia ruim.

M2: Vou dar um exemplo engraçado demais. Quando eu fiz o (inint) [00:31:57] eu sempre peço, tem uma das dinâmicas que são exemplos desses partners aí. Aí uma pessoa deu um exemplo de uma, eu não sei é verdade ou não, mas é hilário, que teve uma cidade no interior de Minas que estava tendo muita cobra, muito acidente com cobras, e aí o prefeito colocou assim, “Vocês vão pagar x reais por quem trazer uma cobra”. Muitas casas começaram a criar cobra.

M1: Tem caso famoso assim. Eu não me lembro de onde, dos caras criando rato. Algum lugar que tinha peste e o pessoal criando rato e vendendo rato, porque os caras pagavam por rato.

M3: Mas trazendo um pouco mais para a nossa realidade esse partner, é muito interessante, porque eu lembro de uma conversa entre nós três, quando a gente implementou aqui um mecanismo de gestão a vista em relação aos nossos ritos operacionais. O retro, cheque de execução, cheque arquitetural. Aí a gente colocou isso na televisão de forma transparente para todo mundo poder consumir a informação. Eu lembro de a gente ter ficado bastante preocupado com esse partner, inclusive, que era das pessoas deixarem de fazer os ritos pela razão pela qual eles existem e só para deixar o painel verde, na verdade.

M2: A gente tem que ficar atento a isso o tempo todo. Se a gente começa a confiar excessivamente nas regras, você pode cair nesse (inint) [00:33:16].

M1: Pessoal, é isso aí. Caminhando aqui para o final, então, eu acho que a principal mensagem aqui é que você tem que, realmente, olhar para o comportamento emergente, entender os lançamentos entre as partes, entender os incentivos do ambiente, os símbolos, sobre o que as pessoas estão se auto organizando, estudar bastante sobre esses arquétipos, porque o caminho fácil é ficar achando culpado, pessoas culpadas. Eu diria que o caminho fácil é o caminho que muitas empresas fazem, mas não é o caminho que vai fazer a empresa, realmente, ficar ágil, porque igual o Vinição comentou aqui, o grande tema desse podcast que, no final das contas, é ter uma organização que seja extremamente adaptativa, você quer que aquela organização consuma o máximo de energia que ela possa gerando valor e aprendendo. Esses arquétipos vão todos caminhar no sentido contrário se você não cuidar deles. Então, é isso aí. Até o próximo episódio.

M2: Até mais, pessoal.

M3: Valeu, pessoal.

: :
os agilistas

#21 Um mau sistema irá derrubar uma pessoa todos os dias

Saiba tudo sobre cultura ágil pelos experts da dti.

Ouça e acompanhe nas plataformas abaixo.

SoundCloud
Spotify
iTunes

Ficou com dúvidas?

contato@dtidigital.com.br
R. Antônio de Albuquerque, 330 – 14° andar
Savassi, Belo Horizonte – MG, 30112-010