Saiba tudo sobre cultura ágil pelos experts da dti.

Ouça e acompanhe nas plataformas abaixo.

SoundCloud
Spotify
iTunes
M1: Bom dia, boa tarde, boa noite. Vamos começar mais um episódio dos Agilistas. Eu estou aqui hoje com o Felipão, ele andava sumido aqui do podcast… tudo bom, Felipão?Felipe: Beleza. Muito bom voltar aí gravar um episódio dos Agilistas. Me convida mais. Só convida o Régis, (inint) [00:00:21].M1: Então faremos isso. O tema hoje… o que a gente queria explorar aqui hoje, nesse episódio – e por isso chamamos o Felipão. A gente fez um episódio recentemente, e quer tentar falar sobre esse tema de várias formas diferentes, sobre o que seria esse True Agile, sobre aquela questão de pensar mais na essência, mais nos princípios do agilismo, e entender que os times, no fundo, são norteados por esses princípios, do que… pensar demais em prescrições e receitas. Assim, existe uma crítica muito grande à comunidade ágil, e que, na medida em que o agilismo começou a ficar meio stream, e começou a ter que ser escalado e etc., começou-se a tentar empacotar tanto aquilo como uma coisa prescritiva, com uma receita e tudo, que isso começou a ficar mais importante do que os princípios. Mas, por outro lado – e acho que isso é interessante também – é claro que existe uma certa prescrição que poderia ser feita para alguém que quer começar. E é isso que aqui é curioso. É paradoxal. Alguém pode ouvir e falar: “poxa, mas qual é a sua no final das contas”? Isso é prescritivo ou não é prescritivo? Tem uma essência, ou não tem uma essência? Tem que seguir os princípios, ou não tem que seguir os princípios? O fato é que, muitas vezes, quando a gente está aprendendo alguma coisa em estágios iniciais, a gente precisa de uma certa prescrição para poder começar a fazer aquilo e depois talvez explorar alternativas. E aí, sem mais delongas, a gente chamou o Felipão aqui por quê? A gente tem uma equipe aqui de operações, liderada pelo Felipão, e uma das missões dessa equipe é justamente fazer com que os times operem sob esse paradigma ágil nas suas mais diversas dimensões. E é curioso, porque, obviamente, que (superar sobre) [00:02:15] o paradigma ágil vai ter uma parte aí que é muito… de entender os princípios, para que se possa adaptar situações, mas a gente também tem na DTI o nosso flow, tem os processos mínimos que a gente acredita, os nossos cheques… enfim. Não é que simplesmente se alguém chegar aqui, o time simplesmente faz o que quer e pronto. A gente nunca quer dar essa impressão. Mas a gente tenta se ater ao mínimo de coisas e ainda dar um grau de liberdade aos times, desde que eles estejam com um propósito e com entendimento profundo. Então eu queria conversar hoje com o Felipão sobre isso, dado a grande experiência que ele tem, justamente em pegar times dos mais diversos níveis de maturidade. Claro, muitas vezes existem times que são alvo da operação, não é nem por uma questão e agilismo em si, tem outras questões também. Mas muitas vezes tem a ver com a organização do trabalho de forma ágil, não é, Felipe? Então… primeiro, como é que se enxerga isso, baseado na sua experiência, existe essa polaridade mesmo, igual eu falei de prescrição versus seguir princípios? Como é que você enxerga isso?Felipe: Eu acho que você falou muito bem essa questão desse paradoxo, sendo um dos preceitos da agilidade o empirismo, que é a experimentação versus a prescrição. Se a gente fosse empírico, a gente deveria prescrever menos para deixar algo fluir de forma ágil, mas ao mesmo tempo algum nível de prescrição, ou pelo menos uma prescrição de princípios, igual você falou bem ali, ela se torna necessária. E você citou uma coisa que é… essa atuação que a gente faz em operações e às vezes para tentar garantir que um squad que começou a operar consiga brotar a sementinha do agilismo… eu acho que até extrapola esse paradoxo de algum nível de prescrição versus a liberdade, a autonomia para operar, não se aplica necessariamente apenas aos squads começando. Às vezes squads já estão operando há algum tempo, mas que têm vales de maturidade, porque a gente sabe que isso acontece, por fatores, às vezes, externos, questões com clientes, a parte do processo que está sendo investida pode gerar ali algum rompimento com a sanidade operacional do squad e eles têm vales de maturidade. Então nesse momento também é importante dar um passo atrás e prescrever um pouco mais. Eu já peguei as duas situações: em apoiar um squad começando, onde, sim, a gente tem que dar algum nível de prescrição, tentar incorporar muito os princípios por trás da mentalidade, mas já peguei também squads em que eles já operavam há um tempo, e de repente – é até curioso –, que eles falam assim: “eu não sei o que aconteceu”, “Não sabemos o que aconteceu. A gente estava operando bem, e de repente, as coisas pararam de funcionar”. Aí óbvio que não vem muito ao caso. (Post mortem) [00:05:33] sim, avaliar as razões pelas quais tudo parou de funcionar. Mas para resolver o problema e voltar o squad a uma operação de alta performance, muitas vezes a gente dá um passo atrás. A gente volta a um pouco mais de prescrição, para que o squad consiga aumentar o nível de maturidade e, dali para frente, voltar a operar com sanidade. E sobre essa questão da prescrição, me tocou muito no (inint) [00:06:03] Brasil do ano passado, onde a gente até fez episódios ao vivo, lá, dentro do evento…M1: …bons tempos aqueles, que a gente podia encontrar as pessoas…Felipe: Aglomerava… maravilha. Mas me tocou muito a palestra lá, e até um enzima que o (Alistair Cockburn) [00:06:17] fez com a gente, ele gravou uns enzimas lá…M1: …o heart of agile.Felipe: O heart of agile, sim. Ele fez uma crítica… ele como signatário do Manifesto Ágil fez uma crítica à comunidade ágil, como ela acabou evoluindo, entre aspas, comercialmente. Muito prescritiva, muito empacotada, com talvez tentativas de se fazer uma receitinha do agilismo, quando, na verdade, você tem que se apegar ao que ele batizou de heart of agile, que é o princípio por trás. A forma como você faz, se você compreendeu muito bem o princípio, a forma, ela pode ser ajustada ao seu contexto, mas o princípio, ele tem que ser respeitado. E é isso que a gente tenta fazer muito aqui na DTI.M1: Ok, mas só uma… pegar umas coisas que eu achei superinteressantes na sua fala. Primeiro, essa questão dos vales, eu achei interessante, que você colocou. O time… porque, assim. No modelo mecanicista, que a maior parte das pessoas acabam que encaram o mundo, é quase que… como assim um time pode oscilar. Por quê? Por que oscilaria? E é interessante pelo seguinte. Só uma coisa que me deu um instalo quando você falou: eu acho que o time, às vezes, ele pode sofrer de dissonância cognitiva, o time. O dissonância cognitiva é quando existe uma tensão entre o seu comportamento e aquilo que você acredita. E é curioso, porque você, muitas vezes, ajusta àquilo que você acredita. Então, assim. Eu lembro que eu li num livro, por exemplo, (de um caso famoso) [00:07:52]…Felipe: …muito bem colocado, eu nunca tinha pensado dessa forma, mas geralmente você ajusta o que você acredita e não o seu comportamento.M1: E é engraçado. Eu lembro que eu li sobre isso num livro, e o cara fala um negócio interessantíssimo. Tinha um procurador, ou um juiz do STF, alguém respeitadíssimo nos Estados Unidos, era um cara mesmo de histórico super respeitado e de repente teve um escândalo, que esse cara estava, tipo assim, super envolvido com os lobistas, envolvido com alguma coisa que era completamente inadequada para alguém que ocupava aquele cargo. E aí o autor mostra o seguinte. O cara gradativamente vai desviando ali de onde ele estava, o comportamento dele vai mudando aos pouquinhos, e ele gradativamente vai criando narrativas que justifiquem aquilo. Então, imagina. O cara quer jantar comigo aqui hoje. É totalmente inadequado jantar com um cara que é um (noviço) [00:08:46], mas eu sou fulano tal, que sou impecável, comigo não tem problema. O cara está me levando para eu viajar para não sei aonde, e aí, gradativamente, o cara vai torcendo as histórias. Então eu vejo que alguns times, eles, bem-intencionados sempre, às vezes com uma pressão ambiental, uma pressão do cliente, uma pressão por resultado, ou o que seja, eles vão gradualmente abandonando certos ritos e se convencendo assim: “não. Para que reunião diária hoje, nós estamos aqui do lado um do outro, já conversamos. No fundo não precisa dessa conversa todo dia. Para quê?”.Felipe: Tem um quezinho de viés da confirmação aí nesse… você já percebeu que algo não está certo.M1: E aí, o time, de forma super (inint) [00:09:26], vai se afastando, se afastando um pouquinho de cada vez. E, de repente, acontece coisas que você observa que é um vale mesmo. Você pega um time: “como é que chegou nesse ponto?”. É igual esse Luís, que era honesto e que de repente está viajando. Eu lembro que esse cara estava num resort, com os lobistas, e ele mesmo… nem ele sabia mais explicar como é que ele chegou. Eu acho que um time chega nisso sem entender também o que aconteceu.Felipe: Eu acho que sim. Eu acho que esse recém-batizado vale de maturidade, eu acho que ele, dentro desse exemplo que você deu, eu achei curioso o exemplo, e acontece da mesma forma dentro dos times, eu acho que você não pode subestimar poder que o meio tem de transformar. É para o bem ou para o mal. A gente fala muito sobre o poder que o meio tem de transformar para o bem ou para o mal. Então se você começar a acreditar que você está imune a determinadas coisas, e se colocar num meio que não vai favorecer um comportamento adequado, você vai alterar o seu comportamento, não tenha dúvida disso. E se o meio te influenciar para um comportamento… um (inint) [00:10:38], por exemplo, no caso de um squad, igual você citou: “não. A gente já está aqui todo mundo perto um do outro, então não tem necessidade de fazer reunião diária”. A gente já testa bastante aqui enquanto está desenvolvendo, então não tem necessidade de fazer uma integração, um teste duplo, ou uma revisão de código. “A turma aqui já é muito madura”. Esse conjunto de coisas, eu acho que vai se somando a esse efeito que você disse. No final, o time entra nesse vale de maturidade, as coisas param de dar certo, e tu não sabe nem muito explicar o porquê. Porque, na verdade, não tem um fator. É uma alteração de comportamento gradual, e que tem sim muitos casos que ela é… o trigger disso é… às vezes uma pressão extrema de uma entrega que, de novo, gera outro (inint) [00:11:26] de comportamento. Você tem que entregar mais em menos tempo. Qual é a forma de fazer isso? Abandonar toda a minha crença, alterar… reconfigurar a minha crença para poder abandonar o que nos defende, os ritos, as práticas, os princípios, para ir para o método que a gente chama de Go Horse, simplesmente sai fazendo. Vários times que, simplesmente, quando entram num ciclo de pressão muito forte, a tendência é: “não tenho tempo mais para fazer nada que não seja construir”, e aí é Go Horse.M1: (Inint) [00:12:03] esse episódio vai ser bem solto mesmo, que os ouvintes vão ver. Porque, assim, olha só que interessante. Quando você fala que uma das principais causas – e acho que é isso mesmo, a gente poderia botar como das principais causas, de um time que é maduro e de repente ir arredando e abandonando, é a pressão de uma determinada entrega, eu acho curioso pensar que isso por si só já mostra um dos principais princípios do Agile sendo violado, que é aquele de que, se você estivesse fazendo uma entrega contínua, nunca teria uma entrega… exceto por algum motivo legal, alguma coisa que é uma lei, porque o pessoal muitas vezes fala: “mas pode ter o lançamento de produto”, mas até isso (num evento) [00:12:49] de mercado, numa abordagem ágil, você deveria já ter gerado valor de uma forma tal que aquele dia não é o dia D. Não pode ser o dia D. O dia D (inint) [00:12:59], um dia D (inint) [00:13:03].Felipe: Eu vou te falar uma coisa aqui que pode arrepiar os cabelos de muitos ouvintes, principalmente ouvintes que comprem serviços de desenvolvimento de produtos e software, é que, na verdade, na minha experiência, acredito que na nossa experiência aqui da DTI, dias D de fato, realmente em que aquele dia é importante, em que um (deadline) [00:13:29] é uma coisa imperdível, que não é simplesmente um constructo de uma gestão talvez desconectada da realidade, de um ciclo de construção de um produto, é a minoria. Esses dias D mesmo são a esmagadora minoria. Quando a gente vê squads, que estão sob a pressão de uma data, normalmente essa data é um constructo de uma gestão que está desconectada com a realidade do negócio. Normalmente. Isso… pode arrepiar a galera, mas estatisticamente é o que acontece. E o efeito negativo que isso tem nos squads é brutal, porque aí você começa a perseguir uma coisa que não tem propósito de ser, e o time sente isso, a pressão aumenta, os ritos vão sendo abandonados… aí a gente entra nesse vale e cada vez fica mais difícil para o próprio squad conseguir sair dessa situação, porque simplesmente não consegue explicar o que gerou a crise, em primeiro (inint) [00:14:30].M1: Curioso mesmo. Esses dias aí, dias de tudo ou nada, eles realmente podem ser encarados como um (inint) [00:14:39], de que o squad não estão seguindo princípios. Porque, normalmente, aquele dia é tudo ou nada. Ele pode estar significando um tanto de coisa. Ele pode estar significando que na verdade você não fez nenhum tipo de experimentação antes, não eliminou nenhum risco antes, ele pode estar significando que no fundo tem uma meta de alguém importante, que se associou ao (escopo) [00:15:02], e aí o cara quer que entregue aquilo de qualquer jeito aquele dia. Ele pode estar significando um tanto de coisa, mas ele mostra, no fundo, que a essência de gerar valor contínuo e dirimir risco continuamente não está sendo…Felipe: …não está sendo aplicada. Não está sendo aplicada. E, assim. Aí – que eu acho que tem um pouco a ver com isso que a gente está falando, me ocorreu aqui… você até brincou, esse episódio vai ser mais solto, mas me ocorreu aqui alguns cenários que a gente passou…M1: …esse episódio, na verdade, ele se chamará “Conversas sobre True Agile”, (inint) [00:15:26] com Felipão.Felipe: Um bom nome. Mas me ocorreu aqui alguns cenários que aconteceram nessas atividades de operação dos nossos squads, que me preocupam um pouco em relação ao agilismo, como ele vem evoluindo, o agilismo mercadológico, como ele vem evoluindo esses pacotes… eu acho até que, assim, fazendo um parêntese, chamar me método já é uma coisa que não parece muito ágil, porque se você falar “um método”, ele tem uma prescrição, ele tem uma receita. E sinceramente fazer um squad operar com a mentalidade ágil, com empirismo, com tudo o que a gente já fala bastante aqui no podcast… não existe uma receita de bolo específica que pode ser aplicada em squads de contextos diferentes. Você tem que deixar a essência daquele contexto ali se juntar ao agilismo mais como um (inint) [00:16:40] e colher os frutos. Mas esses casos que eu citei, e que me preocupam, é que hoje, como o agilismo está chegando no meio streaming, tem um agilismo acadêmico, muito curso, muito material… Mesmo os métodos mais consagrados, a gente pega o (inint) [00:16:56], o (Linkamban) [00:16:57], XP… tem muito material. Então hoje em dia a comunidade ágil cresceu muito, o que é bom. Mas o que me preocupa? A aplicação um pouco indiscriminada da teoria, sem se preocupar que existem determinados contextos, contextos esses que extrapolam até o ciclo de vida do produto. Exemplo, você citou aí, às vezes é uma pressão por conta de uma meta, é um gerente que prometeu um escopo para a alta gestão, e no texto, lá na prescrição dos métodos, não tem escrito lá como se comportar em casos (escusos) [00:17:48], casos alheios ao simples dia a dia do squad operando, vamos dizer assim, de forma linear. Então, assim. Eu acredito que essas situações, que elas não estão previstas na literatura, fazem muita diferença em relação a como você se comporta. E isso é uma coisa que a gente de operações aqui na DTI tenta muito ter esse feeling. Um exemplo. Recentemente agora apoiando um squad, a gente estava seguindo Sprint após Sprint, as coisas estavam indo relativamente bem, mas acontece de algum Sprint ter algum problema. Uma parte da Sprint não pode ser entregue, porque teve um impedimento, isso é comum. Isso está prescrito lá no método. O que fazer? Na teoria, o que fazer é: tudo bem, se você não entregou tudo o que estava como método da Sprint, você conclui a Sprint, faz uma (review) [00:18:45], apresenta o que foi feito, e o que não foi feito é ponderado e pontuado, não atingimos a meta, e próximo Sprint. Isso seria lindo se o mundo fosse sempre lindo. Se todo mundo compreendesse muito bem que fazer dessa forma projetando para o longo prazo, a gente consegue de fato ter mais entregas, ser mais efetivo na entrega. O que não está nos livros é que, às vezes, essas promessas feitas, a meta que há de ser batida, influencia na percepção ou na expectativa do que vai ser entregue. Então, imagina. Nesse caso específico, a expectativa da área de negócio, que não tinha nenhum conhecimento em ágil, e nem um comprometimento de que o método ágil dele deveria ser o método utilizado… isso que é uma coisa mais da TI, geralmente tem surgido de dentro da TI, tinha essa expectativa muito alta. E eu percebi que uma parte lá muito importante não ia ficar pronta, e sugeri que a gente não terminasse a Sprint no dia que estava marcado para (review) [00:19:27], que a gente estendesse a Sprint dois dias. Agora quem vai arrepiar os cabelos são os agilistas, que (vão escutar) [00:19:59]: “mas isso não se faz. Você não estende uma Sprint, acaba a Sprint e diz que a meta não foi atendida”. E aí houve uma pressão muito grande do time de agilidade, do lado do cliente, e acabamos terminando a Sprint. O efeito foi catastrófico. Porque, você imagina. Quem estava com a expectativa do lado do negócio e que não estava nenhum pouco preocupado com o processo ágil apenas esperava que algo fosse ser entregue. E a gente tentou terminar a Sprint antes e mostrar alguma coisa. Só que essa alguma coisa obviamente não estava pronta. A ótica de quem não está totalmente imerso num processo de construção de um produto, o não estar pronto significa o quê? “Vocês me entregaram algo de qualidade baixa”.  Na verdade nós não entregamos, mas a qualidade percebida foi baixa. E aí entra naquele paradigma que eu comento bastante, acho que eu já comentei em outros episódios. O atraso versus a percepção de baixa qualidade. No agilismo teórico, a gente termina a Sprint e não entrega o conteúdo. Em alguns momentos, eu acho que é importante a gente se desapegar um pouco, entender o contexto, entender os efeitos que isso pode causar, e às vezes gerar esse atraso, gerar esse (apendi) [00:21:29] no método aí, para que uma pessoa que estava lá com uma expectativa receba, ainda que com atraso de um ou dois dias, algo totalmente aderente à expectativa, do que a gente tentar ser purista. Eu sempre falo. O atraso, ele vai ser perdoado. A baixa qualidade nunca vai ser perdoada. Eu, pelo menos, (penso assim) [00:21:47].M1: Mas olha só, amigo. Até tirando a questão da baixa qualidade, sabe que eu acho esse exemplo seu superinteressante pelo seguinte. Imagina só. As pessoas tendem a ser muito dogmáticas. E é muito mais fácil seguir uma regra (inint) [00:22:01] é claro que o princípio, em geral, é que você (tem) [00:22:04] cadência e procura fica na janela de tempo, porque isso é muito melhor. Um time ganha cadência, um time aprende a entregar sempre naquele tempo, etc. Mas imagina um exemplo que não seja nem de qualidade, não. Um time que faz isso sempre, mas um dia ele percebe que, se ele trabalhar mais dois dias, ele faz um negocinho ali que muda a vida de quem vai usar aquilo. (Inint) [00:22:33].Felipe: (Por que não fazer antes?) [00:22:33]. Isso parece quase que é um mandamento divino, então, que veio não… alguém e fala: “não. Está escrito no livro divino que (inint) [00:22:43]…”M1: …não quebrarás a cabeça.Felipe: É. Não quebrarás…M1: Nós não podemos quebrar nunca a cabeça. Isso é a falta de pragmatismo total. A questão é: um time que fizesse isso o tempo todo, ele estaria começando talvez a gradativamente arredar para aquele lado que a gente falou que é perigoso. O time perde a cadência, começa a virar um (inint) [00:23:02]. Um time que conscientemente faz isso de vez em quando, ele, para mim, está pragmaticamente tomando uma decisão, (sendo) [00:23:11] uma decisão… então eu acho esse exemplo que você deu sensacional, porque ele fala muito dessa questão do (inint) [00:23:17]. Imagina, é muito confortável para um cara… Só para completar, você falou a história do conhecimento empírico versus (conhecimento) [00:23:28] teórico. Eu acredito demais nisso. Por exemplo, eu adoro ler, acho que o conhecimento teórico é fundamental, você se embasa, você lê, você cria lá os modelos mentais. Ler inclusive a mesma coisa de diversos autores diferentes sempre te aumenta um pouco… um cara escreve de um jeito, outro cara escreve de outro… por mais que seja repetitivo aquilo. O conhecimento, eu acho que ele é fundamental. Mas esse conhecimento, eles são completamente base empírica para consolidar mesmo. Por exemplo. Eu vejo a DTI, que hoje a gente fala muito… só para dar esse exemplo, para a gente voltar para o… mas a gente fala muito que (a nossa estrutura) [00:23:59] é orgânica. Hoje a gente vive isso, eu entendo muito melhor o que essa estrutura orgânica é mesmo, do que quando eu lia sobre estrutura orgânica. Ela parecia só uma metáfora, um tempo atrás, legalzinha, e às vezes eu ficava até meio cético. E hoje, quando você vê a empresa quase que um negócio (inint) [00:24:19] mesmo, adaptando, você começa a entender melhor o que é o orgânico, você vive aquilo. Então você praticar aquilo que você estuda e ter feedback é fundamental.Felipe: É. Eu acredito muito nisso que você falou. Ler perspectivas inclusive de autores diferentes sobre aquele assunto, sobre aquele material teórico, isso é importante, mas eu acho que o profissional… não vou nem ficar extrapolando para outras especialidades, vamos falar aqui do agilista. O profissional, ele tem que entender e tem que aceitar que isso é uma base de ferramentas para ele aplicar na realidade, e a realidade é empírica. Ponto final. E isso está inclusive… se a gente está falando do que está escrito, lá no (inint) [00:24:52] está escrito isso inclusive, que não se deve – não vou lembrar as palavras corretas, mas é que – não se deve subestimar o poder do empirismo. Então mesmo onde (estão) [00:25:23] prescritas as técnicas, ainda é dito: o empirismo é importante. Então espera aí. De certa forma, então, eu não estou subvertendo o (inint) [00:25:29]. Se eu esticar a Sprint em dois dias, quando isso é justificável. Mas você falou uma coisa importantíssima. A questão é saber compreender o quando esse ajuste, ele é justificável e tem razão de ser, e quando ele virou simplesmente uma muleta para o time. Então quando eu, ajudando um time, acompanhando um time, ajudo o time a tomar esse tipo de decisão, ela não vem de graça. Ela vem acompanhada de um pequeno sermão de que isso é um mecanismo que a gente adotou, porque a gente extrapolou o contexto que aquela entrega vai afetar. Nesse caso, que eu dei o exemplo, a pessoa lá, que tinha expectativa, acabou por ficar muito insatisfeita com uma entrega incompleta que, um dia a mais, dois dias a mais, teria evitado uma sequência de fatores que causou uma crise muito grande nessa (squad) [00:26:29], pela insatisfação de uma pessoa. Então, assim. Seguir o dogma, igual você colocou, foi uma decisão péssima, porque desconsiderou a necessidade de ser empírico, porque estava tudo gritando lá na cara da gente que não era a melhor opção, que isso ia acontecer. Agora adianta você virar para essa pessoa que está com essa expectativa, levá-la a scrum guide, levá-la (inint) [00:26:50] para ela: “veja bem, está escrito aqui que a gente não poderia fazer isso”. Eu ia falar assim: “tudo bem. Pouco me importa. Eu quero a minha (entrega) [00:27:00].M1: (Inint) [00:26:59] você falou antes sobre um outro negócio, que é um (inint) [00:27:02] terrível… já que nós estamos falando do True Agile. Não tem jeito de ser True Agile se o negócio na verdade não comprou, porque a (TI) [00:27:13] que comprou. Igual você falou, não é assim. Nunca vai ter true, porque o (True Agile) [00:27:18], é assim… é justamente, o negócio e TI e juntos, é todo mundo do mesmo jogo. Isso já é o começo da derrota. (Inint) [00:27:27] terceirizando uma caixa preta ali e cobrando um resultado.Felipe: É. Esse exemplo que eu dei aqui, infelizmente, ele não faz parte do True Agile. É mais aquela relação (abusiva) [00:27:44], que a gente cita muito. A expectativa é de um jeito, a tecnologia se comporta de outro, com a relação (abusiva) [00:27:52], cada um apontando na direção contrária, com a mesma intensidade. Mas então o que eu tenho me preocupado muito, e a gente tem trazido isso inclusive para dentro de casa, porque eu acho que nem a gente que respira agilismo o tempo todo está imune a esses vieses não, assim, de ser mais dogmático em algumas coisas. Eu mesmo já fui muito. Eu entusiasta que sou do assunto, fico lendo, fico lendo, fico lendo, a gente acaba às vezes querendo quase ipsis litteris o que foi lido. Mas estou melhorando. Mas o que eu quero dizer de a gente estar trazendo para a nossa estrutura orgânica? Houve um tempo aqui na DTI que a gente acreditava muito… a gente ainda acredita muito forte naquela estrutura do (inint) [00:28:40] que são três palavrinhas em japonês, o (inint) [00:28:46] é “siga uma regra”, o (inint) [00:28:47] é “quebre com a regra”, e o (inint) [00:28:48] é “se torne a regra”. Isso é espetacular, porque realmente ajuda muito bem a gente a montar um modelo de maturidade dos squads, aonde, de início, você segue um pouco de prescrição. Você vai quebrando essa prescrição, adaptando à sua realidade, e depois você cria novas práticas, novos métodos. Isso para mim é fantástico e eu continuo acreditando muito fortemente nisso. No entanto, mesmo na parte de seguir a regra, eu – vamos dizer assim – melhorei um pouco minha forma de entender isso. Na DTI a gente criou aqui uma ferramenta, a ferramenta das ferramentas, vamos dizer assim, uma ferramenta que a gente batizou de (Operating Canvas) [00:29:26], que acredito que já foi citada em outros episódios dos agilistas, que, na minha visão, foi uma epifania em relação a seguir a regra, a prescrição. Esse (Operating Canvas) [00:29:39], ele é um (Canvas) [00:29:41] como outros que se conhece no mercado de business, e que… no (Canvas) [00:29:45] estão representados princípios, os princípios que devem ser seguidos. Esses sim são os princípios que o (inint) [00:29:55] tem que garantir que sejam seguidos. Eu sempre brinco com os squads: “vocês vão preencher aqui o (Operating Canvas) [00:30:00], os princípios vocês não podem negar”. É inaceitável você dizer que não vai seguir um princípio. Agora…M1: …os princípios são inegociáveis, não é?Felipe: São inegociáveis. Agora a forma como você vai cumprir um determinado princípio, isso é obviamente negociável, e tem que ser negociável, até porque não sou eu em operações centralizadas da DTI que tenho a melhor resposta de como se fazer algo para um squad que tem todo o contexto do cliente. Então realizar determinada atuação dentro de um princípio passa a ser uma escolha do squad, a forma A ou a forma B. O que a gente tem trazido para os nossos squads é o que a gente chamou de arsenal. Então, assim. Você está em dúvida, você não sabe? Você ainda está muito no princípio do (inint) [00:30:45], então aqui tem uma gama de opções para esse princípio aqui. Você pode escolher uma, que parece mais adequada ao seu contexto, e segui-la. Mas sinta-se livre para inventar também algo novo. “Então eu fiz meu (Operating Canvas) [00:30:57], defini as formas mais adequadas, então ok, agora é só operar?”, obviamente que não, porque você tem que monitorar constantemente se aquela escolha que você fez para atender aquele princípio está de fato atendendo o princípio. Porque senão, você está só seguindo novamente uma coisa (burra) [00:31:14], está usando uma ferramenta e não está atingindo o princípio. E isso faz muita diferença, o contexto do cliente, a maturidade do squad, senioridade e tudo mais.M1: Mas veja bem. Eu acho interessante como você falou, por exemplo. O cara só tem chance de deixar de ser dogmático se ele enfrenta o mundo real. Quando o cara não enfrenta o mundo real e fica só ali nas teorias, etc., ele não tem feedback, a verdade é essa. Ele não tendo o feedback, ele só pode falar pelo livro, porque… tipo assim… aquilo é verdade mesmo. Aquilo só passa a não ser verdade quando ele pratica e vê que o mundo está ali, e que o se humano modela o mundo, mas o mundo está ali. O mundo está ali e pronto. O que eu acho interessante é assim. Só para deixar uma coisa bem clara aqui, que eu acho que você pensa igual, e se não pensa nós vamos conversando. Que, assim. Quando você fala assim: “eu tenho que fazer um (Operating Canvas) [00:32:14], eu posso tomar decisões de como fazer com certos propósitos, (estejam sendo) [00:32:19] realmente seguidos, é claro que isso tem que ser sob orientação de alguém experiente.Felipe: Sem dúvida.M1: Porque o time que não é experiente… (o que) [00:32:30] não é nem que quer dizer que tem que ser alguém de fora do time, às vezes o time já tem experiência suficiente, (inint) [00:32:34]. Mas o time que não tem essa experiência, ele nem tem como (jogar) [00:32:37]. E aí talvez que entra um pouquinho do paradoxo que a gente falou ali no começo, que existe uma certa prescrição talvez de condições mínimas ou ferramentas mínimas, que você vai falar para um time seguir, para que um dia ele possa talvez até jogar fora, (uma) [00:32:52] coisa dessas. Por exemplo… eu vejo, por exemplo, eu gosto muito de jogar tênis. O (inint) [00:32:55] sempre o exemplo é do lutador do… como é que chama? Do samurai. Mas como eu gosto de jogar tênis, eu posso dar exemplo com tênis agora… É muito mais simples você chegar para um cara e falar para o cara: “olha, você tem que segurar a raquete exatamente assim, você tem que virar e bater na bola desse jeito. Pronto”. E é óbvio que o cara que ensina aquilo, ele sabe que não vai ser (sempre) [00:32:55] assim. A bola vem de forma diferente, vem com (efeito) [00:33:26] diferente… você pode estar equilibrado, desequilibrado… um milhão de coisas acontecendo. Você pode querer bater a bola mais reta… enfim. Tem um milhão de coisas, mas é claro que você não pode chegar já no começo e já tentar falar para o cara que ele pode isso, aquilo, aquilo, aquilo. Eu imagino igual aí. Os princípios… o cara tem que ter um jeito de (instanciar) [00:33:46] para ele ganhar movimento. Depois que ele ganha movimento ele começa a aprender e talvez comece a se libertar um pouquinho de escolher os próprios caminhos.Felipe: É. Que é exatamente o (inint) [00:33:56]. Eu acho que a decisão de como operar, ela quebra um pouco – igual a gente falou – com a prescrição, ela quebra um pouco com o formato até com o que o agilismo vem sendo empacotado. No entanto a decisão de como operar tem que ser uma decisão aconselhada, ainda quer o aconselhamento parta de alguém experiente de dentro do squad. É igual você falou, não precisa ser de alguém de fora do squad. Agora um squad totalmente novo, totalmente inexperiente, vai decidir como operar? Aí é um cego guiando outro. Acho que dificilmente vai chegar em algum lugar.M1: Eu fico pensando então. É como se fosse assim. Não é que não possa haver prescrições, pode haver prescrições mínimas, mas que podem estar sob (judice) [00:34:43], e podem ser dogmas eternos. Porque é o exemplo que a gente deu da cadência. Isso que você falou, lembra? A gente já teve exemplos aqui na empresa, e essa (aqui, gente) [00:34:56], quando a gente fala isso (até) [00:34:57] para quem ouve e entende. Não é uma questão de simplesmente estar criticando o exemplo não. Nós estamos tentando só mostrar o contraste das coisas. Então, por exemplo. Eu já vi coisas do tipo assim. Alguém leu o livro de Design Sprint, e aí tem uma certa sequência que o livro recomenda. Poxa, aí você começa ali uma dinâmica de Design Sprint, e você não consegue seguir aquela sequência por N motivos, (inint) [00:35:20]. Mas alguém vai olhar para aquilo e vai dizer: “mas o livro de Design Sprint manda que agora seja isso”. Mas você fala: “vamos conseguir fazer isso, porra. Não é assim”. Acontece.Felipe: (inint) [00:35:32]. Isso aconteceu inclusive comigo conduzindo um design sprint. Exatamente isso que você narrou. “Mas no contexto não tem jeito de fazer assim”. “Não, mas no livro falou que tinha que ser assim”. (Inint) [00:35:43].M1: Mas isso que eu estou falando… é o paradoxo sempre. Existe uma certa prescrição? Existe, no Design Sprint você vai ter persona, você vai ter jornada… uma boa regra é que você tem que manter a prescrição (com) [00:35:56] o mínimo… tem que entender que não é um dogma, um dogma eterno, e que eventualmente… Mas o mínimo acaba tendo, concorda? Existe um mínimo ali que é meio negociado também, junto com os (inint) [00:35:56].Felipe: Sem dúvida. Olha só que curioso. Acho que, quem estiver ouvindo esse episódio, pode chegar à conclusão, falar assim: “esses caras são doidos. Tem hora que eles falam que tem que ter prescrição, mas tem hora que a prescrição tem que ser mínima, ou a autonomia é a autonomia é mais importante”. Realmente é uma coisa ambígua, pela definição do que a gente faz. O que a gente faz é de natureza ambígua, complexa e tudo mais. O mundinho VUCA que a gente sempre fala. E aí, a epifania do (Operating Canvas) [00:36:41] é justamente isso. Por ser tão ambíguo, a prescrição, ou a não prescrição, a autonomia, o aconselhamento, o mínimo de prescrição, mas tem que ter, não tem que ter, essa epifania com o (Operating Canvas) [00:36:53] foi. Então vamos fazer algo que a gente documente a forma como a gente opere, mas garanta que isso aqui é vivo e que pode alterar de uma Sprint para outra, e às vezes tem que alterar, porque às vezes a forma como foi definido, ou aquela prescrição, não teve o resultado esperado. O input e o output que estava escrito no livro… Você pôs o mesmo input, rodou o mesmo processo, aí você falou assim: “o output não foi igual o que estava escrito no livro”.M1: É. Eu não em que (mercado) [00:37:27] (inint) [00:37:28] todo mundo que está ouvindo, que eu acho que é poder desse Canvas é que ele faz com que as coisas aconteçam de forma refletida. Então, assim. Uma coisa é a pessoa não estar… ela não está seguindo um princípio porque ela esqueceu do princípio, porque ela não entende o princípio, ou o que seja. Outra coisa é a pessoa… fez uma reflexão (inint) [00:37:47]…Felipe: …deliberadamente decidiu.M1: É. Baseado na experiência, no contexto e numa série de variáveis, e deliberadamente registrou: “pelo que a gente entende, aqui é melhor fazer desse jeito. E vamos ver se vai dar certo e se esse é o caminho mesmo”. Isso quebra, primeiro, você usar uma ferramenta cegamente, ou segundo, simplesmente atuar irrefletidamente. Porque no fundo tudo isso que a gente fala, por isso que tem esse nível de ambiguidade grande, o time ágil no fundo é aquele time que aprende continuamente. Ele está aprendendo (inint) [00:38:19].Felipe: (inint) [00:38:20].M1: Isso. Ele está aprendendo inclusive isso, se ele está exagerando em seguir os princípios, se ele está exagerando ou não na prescrição, se ele não está prescrevendo de menos, devia estar prescrevendo de mais. Isso é curioso, no fundo ele está sempre aprendendo porque ele está sempre tentando achar ali o lugar certo.Felipe: É. E para os agilistas que estão nos ouvindo, aqueles que começaram agora atuar em poucos squads, e mesmo aqueles que já atuam há mais tempo, é aceitar uma realidade inexorável. Os squads não vão funcionar do mesmo jeito. A experiência que você teve no squad A, num contexto A, se você tentar replicar literalmente tudo que você fez naquele primeiro squad, num segundo squad um contexto diferente, a chance do resultado não ser o mesmo é grande, porque existe uma coisa muito importante que é o contexto de cada situação. Então isso que é um pouco a crítica que eu comecei lá no início do episódio. O agilista, ele tem que aceitar que, o que está escrito, o método, as ferramentas, vão ser nada mais do que ferramentas que devem ser usadas, adaptadas ao contexto. E aquele papo de tipo, assim: “não, mas no outro squad eu fazia assim”. “Está bom, mas isso foi no outro squad. Esse squad aqui tem outro contexto”. As pessoas no squad são outras, elas respondem de outra forma, a forma como elas se comunicam é diferente. Então… vários ritos, várias práticas têm que ser adaptadas.M1: Não, gente, assim. Estamos chegando ao final, gostei muito dessa conversa nossa (inint) [00:40:00]. Eu acho que isso é igual você falou, pode ter um efeito bom ou ruim, algumas pessoas podem ficar irritadas porque justamente falam: “poxa, esses caras… eu queria uma prescrição, queria uma (inint) [00:40:14]”. Mas eu acho curioso porque… por exemplo, eu estava lendo outro dia sobre o (inint) [00:40:21] de novo, que é o (inint) [00:40:24] para tratar de problemas complexos, e o autor bota como algumas das características do (inint) [00:40:29], coisa você acabou de falar aqui agora. Então ele fala coisa para o (inint) [00:40:35] é context bound, ou seja, ele é completamente ligado ao contexto, e outra coisa que eu esqueci o nome bonito que ele usa, mas que é muito melhor que quem está envolvido no problema que descubra dentro daquele contexto o que fazer, que isso é muito mais (inint) [00:40:50].Felipe: Sem dúvida.M1: E para mim, eu tenho ficado até repetitivo com isso. Isso tem a ver com um mundo complexo e com essa visão mais orgânica do mundo, porque… é igual, por exemplo. Na natureza é assim, as coisas vão se adaptando justamente conforme o contexto delas. Não adianta um ser ter uma prescrição ali, para aquele contexto, se aquele contexto (inint) [00:41:18] daquele contexto, aquela prescrição não vai… se não servir para aquele contexto… vai haver uma adaptação, e aquilo vai ter que mudar, senão vai… é exatamente isso, os contextos… vai ser engraçado, você vê. Todo o problema de tudo é essa visão muito mecanicista e muito ordenada, que as coisas são iguais, repetidas, e que eu consiga atuar com o máximo… por exemplo, muita gente ouve isso e fala: “mas isso é extremamente deficiente. Eu tinha que pegar o time todo, já treinar no método e seguir o método”. Se eu deixo um time descobrir o método, isso é ineficiente. É porque aí (você) [00:41:55] despreza o contexto de cada um, contexto esse que inclusive depende não só do problema que o time está resolvendo, da particular configuração daquele time naquele momento, as pessoas que estão ali e são (inint) [00:42:07].Felipe: Eu falo isso demais. Tem uma métrica muito simples utilizada. Todo mundo que já trabalhou no squad fala: “qual é capacidade ou a velocidade desse time?”. Uma coisa para mim, que eu acho absurda, absurda, é situações em que o time tem determinada configuração, aí tem uma determinada velocidade. Isso é só uma das várias coisas que o contexto do time altera. Mas então, assim. Tem um time de três pessoas, eles têm determinada velocidade, aí por uma razão, a pessoa ali saiu da empresa e tal, o time se alterou, pôs uma pessoa nova. Eles mantêm a mesma velocidade. Não tem cabimento isso. É outro time, o contexto mudou completamente. É óbvio que você tem que reconfigurar algumas variáveis. Você tem que revisitar, você tem que medir novamente algumas variáveis que vão ser carregadas junto com aquele time.M1: E aí é aquela história. Resiliência, o pessoal adora falar, é isso. (Inint) [00:43:15] agilidade é isso. É um time que, no momento que ele aprendeu a aprender, ele vai mudando de configuração, o contexto vai mudando, e ele vai conseguindo tirar lições e rapidamente se adaptar a um time que está com tudo já dado e prescrito (com) [00:43:29] a data. Muito bom, nosso tempo estourou aqui. Espero que a gente consiga ter trazido boas provocações nessa conversa sobre o espírito do True Agile, porque ele viola realmente esses dogmas, nossas necessidades de ter ordem, necessidade de achar um caminho claro, de ter um controle de tudo, mas é isso aí, o mundo é isso aí.Felipe: Exatamente.M1: Um abração Felipe.Felipe: Valeu, (Schuster) [00:43:57]. Obrigado, boa tarde… bom dia, boa tarde e boa noite.
: :
os agilistas

#108 – Conversas sobre True Agile – Felipe Silveira

Ficou com dúvidas?

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