Ep. 135 - O ownership do Agilista

O tema de hoje é o ownership do agilista. A pergunta clássica é: que problema resolve eu saber qual é o ownership do agilista? Que raio de negócio é esse? Eu acredito muito que a gente estava resgatando o porquê desse tema. Eu lembro que eu tive alguns momentos que eu senti que eu não estava mais pertencendo àquele espaço ou que a gente tinha algumas entregas sendo feitas, mas que eu não conseguia ver como parte daquele impacto que estava sendo gerado. E aí, eu acho que um pouco do ownership do agilista vem daí, da provocação. Como que a gente consegue entender sobre o que o agilista é dono? Porque ele está ali num time, ele está ali no meio de um processo, tentando otimizar as coisas, mas ele não é dono daquele processo, às vezes ele não é parte integral ali daquele time ou ele é parte daquele time por um período, às vezes ele atua como consultor. Então, como que a gente consegue ter esse ownership claro do agilista, para que ele se sinta parte, pertencente. Eu gosto bastante quando a gente fala de pertencimento e quando a gente fala de responsabilização. A gente ter clareza dos porquês e de quem é acionável, em que momento é acionável, qual que é a parcela de contribuição de cada pessoa dentre aquilo que a gente está fazendo. A gente tem que otimizar mais nossas rotinas, nossos processos. Então, é importante ter claro qual que é a responsabilidade de cada um para que a gente acione as pessoas para aquilo que está, de fato, pegando. Então, se eu sei que o agilista é responsável por determinado item, eu consigo acioná-lo. E eu consigo ter clareza de que ele é a pessoa que vai ajudar a resolver esses problemas. Para mim, está muito relacionado com accountability também. Quando a gente fala da palavra ownership, também vem muito na minha cabeça essa coisa da responsabilização. E sentir parte, mas ao mesmo tempo, qual que é a minha parcela de contribuição? Isso é importante ter clareza para a gente poder, de fato, otimizar a nossa rotina. Eu fiquei pensando várias vezes quando eu vou em linkoff, sempre traz esse lugar muito das fronteiras do trabalho, do que é efetivamente a responsabilidade do agilista. Perguntas assim do tipo, ah, eu tenho que ajudar o meu product owner, eu tenho que ajudar muitas vezes a minha liderança a fazer o trabalho, a trazer provocações de negócio. E não só num viés de eficiência. E existe um pouco, talvez, de sobreposição desses papéis? Eu acredito que sim, se a gente estiver falando sobre sobreposição de quem faz o quê. Porque em determinados momentos a gente está falando de que as mesmas coisas, trabalhar e contribuir para as mesmas coisas. Então, se eu não tenho clareza do que é, de fato, de quem, pode trazer um pouco dessa sobreposição. Pelo menos essas discussões que eu via nas comunidades, era muito do tipo, poxa, isso é meu papel ou isso é papel do líder? Por exemplo, cuidar do time, do clima, ver se as pessoas estão engajadas, entendendo se elas estão aderindo à cultura ágil, essas práticas que a gente está trazendo. Isso é um papel meu ou quanto o líder deveria me ajudar? Mesma coisa do, ah, eu tenho que ajudar meu próprio aluno a fatiar, a priorizar, usar técnicas ágeis para isso. Mas o próprio PO não deveria saber isso? Então, às vezes, traz esses conflitos. Eu vejo que, por exemplo, alguns ambientes que eu passei, realmente existe essa sobreposição. Mas eu sempre vi o meu líder ali, principalmente quando eu estava debaixo de uma estrutura de engenharia, e aí como agilista respondia para um gestor de engenharia, ele como meu parceiro, ele quase meu par. E aí, muitas vezes, mesmo tendo alguma sobreposição, a gente era corresponsável ali. Mas tem alguns ambientes também que eu vejo que essa corresponsabilidade ou ela não funciona, por conta de perfis ali, ou por conta do contexto, ou porque realmente precisa ser bem definida essa responsabilidade para que um não passe à frente do outro, ou saia fazendo a mesma coisa e a gente tem trabalho duplicado. E eu percebi que ambientes que normalmente precisa dessa delimitação mais clara, também tem uma visão muito clara, ou que aparece mais, da divisão entre o processo de gestão de pessoas e como é gerido o escopo que aquele time cuida. O agilista, ele provavelmente não vai tocar no âmbito de carreira. Às vezes, ele vai, sim, contribuir para feedbacks, vai contribuir para alguns mecanismos ali que apoiam a gestão, que ele não é accountable, ou que ele não tem um ownership direto. Na visão de vocês, qual que é a responsabilidade do agilista? Porque cultura de agilidade é um bagulho amplo. Quando a gente fala dos quatro domínios, dá para a gente atuar nesses quatro domínios. Quando a gente fala dos quatro domínios da agilidade, aqui tão famoso pela K21, a gente está falando que existem possibilidades de atuação dentre o nível organizacional, domínio organizacional, domínio técnico, domínio de negócio e o domínio cultural. Tendo em vista esses pontos, a gente fala muito do agilista sendo um habilitador para que o resultado aconteça dentre esses quatro domínios. O que é resultado do ponto de vista cultural? Como que a gente pode impactar? Por exemplo, métricas, acompanhamento de métricas que dizem respeito à satisfação das pessoas, o turnover, se a gente tem uma capacidade legal ali, ou se a gente está em um nível de burnout. É uma métrica, é algo que faz total sentido o agilista acompanhar. Se a gente está falando ali do nível organizacional, como que a gente pode ter melhores reuniões, ter melhores encontros, aproveitar de fato esses momentos, ter as cadências certas com as pessoas certas. Indicadores desse nível organizacional também faz todo sentido o agilista acompanhar. Quando a gente fala disso, a gente fala de lead time, invasão, tempos de ciclo. Depois, quando a gente fala ali da parte de negócio, acho que um dos principais diferenciadores de agilistas hoje no mercado. O agilista, ele precisa também se apropriar do negócio. E o que isso significa? Ele precisa contribuir, de certa forma, para o resultado. Então, ajudar as pessoas a definirem, ajudar os PMs a definirem, ajudar os POs, os heads, que é resultado dentro daquele contexto de negócio. Então, se eu estou numa BU, o que é sucesso para a gente? E acompanhar esses indicadores, acompanhar o que é, de fato, de eficácia que a gente gostaria de ter. E dentro do nível técnico, não esquecendo também, isso é super importante, a gente já fala de qualidade de código, de bugs, tempos de falha. Então, o que o agilista consegue contribuir para trazer essas visões? Porque, no fundo, as métricas empoderam as pessoas. Então, se o agilista tem domínio, a gente consegue trazer as conversas para um nível mais a nível de resultado. E a nível de resultado, a gente tende a ter menos discussão, porque as pessoas concordam com os impactos. Então, eu vejo muito agilistas sendo essa pessoa que empodera as pessoas a terem essas discussões boas e proveitosas nesses quatro domínios. Eu acho que o agilista, na maioria dos cenários, ele é habilitador. Ele habilita as estruturas onde ele está a conseguirem alcançar esses resultados, nesses diferentes aspectos, de uma forma mais ágil, conseguir se adaptar na velocidade que aquele contexto está acontecendo. Enquanto vocês falavam, me veio alguns lugares que eu trabalhei, e eu pensando o quanto a minha atuação era mais ampla, ou mais focada em um dos domínios, dependendo de como eu estava atuando. Quando eu estava dentro do time, lá na PagSeguro, a gente tinha, na vertical que eu tinha, uma coisa que a gente falava de trio, de trinca. Então, o PO era muito focado no produto, e, consequentemente, nas métricas de produto. Então, eu apoiava ele ali, para falar de práticas de agilidade, de fatiamento, de ciclos curtos, muito em prol de melhorar aquelas métricas focadas em negócios, focadas no cliente. A gente tinha um líder técnico, que era o cara que estava muito focado nas métricas de qualidade. E eu ali, como agilista, trazendo, dado que você quer melhorar isso, como a gente consegue fatiar e falar qual é o valor que eu vou trazer, e conseguir trazer esse PO e priorizar essas melhorias. E aí, eu como agilista, olhando muito um lugar mais de eficiência, às vezes até cultural também, e trazendo essa consciência para o time e a minha liderança me apoiando muito, e olhando muito para essas métricas culturais. Quando eu virei Agile Coach, ou mesmo até como consultora, a gente tem uma atuação mais ampla. A gente traz muitas provocações em todos esses quatro domínios. A gente olha para o todo. E isso não quer dizer que, necessariamente, eu sou a responsável por fazer aquilo mudar. Mas talvez eu sou a pessoa que vai ser responsável por trazer as provocações e os questionamentos, e aí, práticas e métodos para que a gente consiga chegar onde a gente quer. Me veio muito na cabeça essa habilidade que eu acho fundamental para um bom agilista, que é a capacidade da visão sistêmica, de ampliar a visão sistêmica. Muitas vezes, quando a gente começa, a gente começa tendo essa visão mais local, uma visão do time, e faz parte entender primeiro como que a gente pode evoluir o time, para depois evoluir como um todo a organização. Mas o grande pulo do gato está quando eu começo a acompanhar não só o impacto do meu time, mas o impacto do sistema no meu time também, e o contrário, e vice-versa. Então, essa é uma habilidade que a gente vê que é fundamental e é um passo de evolução dos agilistas. E aí, acho que uma coisa que eu vejo muito como diferencial, é a capacidade de fazer boas perguntas. Um agilista, ele vai começar fazendo provocações dentro do time, que faz sentido para a gente evoluir, mas ele precisa, às vezes, comprar certas brigas, para que a gente resolva não só problemas locais, mas que a gente, de fato, tenha um fluxo melhor de valor. E não a gente ter o melhor time, mas a gente ter, de fato, o melhor fluxo de valor possível. Então, eu penso muito que habilitadores para isso são fazer boas perguntas. Então, não deixar, de repente, aqueles pontos ocultos acontecerem, entrar, fazer aquelas perguntas. As perguntas óbvias também precisam ser feitas. E é assim que ele vai habilitando a mudança. Através dessas boas perguntas, ele vai habilitando trazer para o explícito, trazer para a visibilidade coisas que não estão sendo ditas. E assim a gente consegue transformar. A gente só consegue mudar aquilo que a gente conhece. Então, se a gente não provocar, a gente não vai sair ali daquele lugar. Quanto mais amplo é o escopo que o agilista começa a atuar, acho que não só boas perguntas, mas também o agilista conseguir ter essa visão sistêmica e conseguir evidenciar as coisas, evidenciar os problemas, evidenciar as necessidades que aquele ambiente está trazendo, ou que alavancas a gente precisa movimentar para poder causar as mudanças. Eu acho que quando a gente está num ambiente, num escopo mais local, num ambiente menor, e que a gente tem um domínio maior ou consegue ter uma visão um pouco mais detalhada, é até fácil a gente conseguir evidenciar os problemas, a gente conseguir provocar, trazer boas perguntas, mas conforme o agilista vai mudando essa amplitude do escopo, da atuação dele, isso começa a ficar cada vez mais difícil. E eu vejo que a gente está vivendo um momento que o agilista está ampliando esse escopo de atuação e quando a gente vem com o tema de business agility, ou transformar o negócio como um todo, conseguir fazer com que o negócio se adapte como um todo e não só mais um time ou uma área, uma estrutura menor. E aí entrando um pouco nesse assunto, eu estou entendendo que esse ownership está aumentando, essa responsabilidade desse agilista está aumentando. Tem uma polêmica, e eu não sei se vocês já passaram por isso, mas eu vejo que na vida do agilista, no percurso do agilista, ele em alguns momentos vive a síndrome do impostor. Ele tem momentos de síndrome do impostor, tipo, ah, meu Deus, o que eu estou fazendo aqui? Agilidade, o que que é agilidade? Agilidade realmente resolve alguma coisa? E eu acho que tange muito esse tema que a gente está falando, porque aí o agilista ele começa a não só não ver o impacto do que ele faz, às vezes, mas não ser reconhecido, porque muitas vezes rola aquele reconhecimento ali pro time, ó, time, muito bom o que vocês fizeram, mas o agilista, ele está ali dentro, mas ele não se sente tão reconhecido. Ele no final não entregou, de alguma forma, não entregou nada. Como eu evidencio o trabalho de um agilista, como eu evidencio o valor que esse agilista entrega? Quando eu ouço isso, eu penso muito no quais são os outputs que um agilista pode gerar e que pode ajudar a trazer essa visibilidade do que está sendo feito. E, às vezes, eu acho que a gente acaba pecando, a gente mesmo acaba pecando em não evidenciar e não trazer isso de uma forma estruturada. E que talvez a maior oportunidade que a gente tenha, de fato, estruturar esse raciocínio, esse processo de transformação evidencial que a gente está colocando e quais são os próximos passos. Eu gosto muito de pensar assim, se a gente só fala e a gente não faz, é filosofia. Então, a gente precisa transformar o que a gente encontrou em alguma ação. Então, como que a gente pode pegar tudo aquilo que a gente encontrou, as oportunidades, transformar em ações, em ações práticas, para a gente acompanhar esse processo de evolução. Porque, no fundo, o que o agilista está fazendo é como se fosse uma transformação, promovendo essa melhoria contínua entre ciclos curtos, focando no valor. Só que se a gente não tiver isso, se a gente não fizesse essa demonstração de quais são as nossas entregas, o que a gente está podendo contribuir dentro do processo, fica difícil. Então, acho que fica assim, uma coisa que eu sempre vejo. Talvez a gente pegue nós, agilistas, pequenos em demonstrar o nosso trabalho. Porque acho que as coisas estão sendo feitas, mas a gente precisa dar mais visibilidade de qual é o próximo passo, porquê e qual que isso está fazendo sentido ser feito nesse momento. E acho que eu aproveito o gancho para trazer a polêmica maior, que é o agilista não é só o facilitador. Porque eu acho que nos últimos anos, o que a gente tem vivido é que o agilista tem sido muito lembrado naquele momento, ah, precisa facilitar uma retro, precisamos facilitar alguma coisa mais complexa, definição de OKRs. Legal, mas será que é esse o trabalho que a gente está fazendo? É só isso que a gente faz? É só aí que as skills do agilista são úteis? Facilitação faz parte, mas ela é tudo, se for tudo, a gente está jogando muita coisa fora, muita oportunidade fora. Você está querendo facilitar para chegar de um outro lado, você vai trazer reflexões, você vai mostrar caminhos. Facilitação é muito importante dentro do nosso trabalho, até os questionamentos que a gente traz, mesmo quando a gente não está facilitando uma reunião, os questionamentos que a gente traz. Vocês conversaram muito sobre isso, sobre evidenciar que a coisa não está legal para despertar senso de urgência ali, um senso de urgência de que as coisas precisam mudar, fazer boas perguntas para trazer boas reflexões, talvez quebrar ali um status quo, mas também apontar caminhos. Não é só ficar enchendo o saco e fazendo um monte de perguntas também, que deixa as pessoas estressadas, às vezes a pessoa já está cheia de trampo e ela não quer mais um problema para resolver, ela não quer pensar, ela só quer uma solução. Sim, acontece. Então, acho que faz muito sentido a gente evidenciar que o bagulho não está bom, a gente escutar as pessoas, trazer essas preocupações, mas também trazer caminhos. E a facilitação é um caminho para isso. Eu trago um caminho durante essa facilitação para que a gente resolva um problema, para que a gente chegue num resultado. E aí, como eu evidencio esses resultados de todas as ações que eu tenho feito como agilista? Eu estava mentorando uma menina que ela chegou para mim e falou assim, ah, eu já me sinto sênior, mas ainda não estou sênior, eu sinto que eu trouxe bastante impacto para o meu time. Eu falei, beleza, vamos evidenciar esses resultados? E foi assim, a gente, eu falei, me traz tudo o que você fez que você sente que trouxe, fez diferença e eu quero números. Ah, você mexeu aqui no processo, você fez essa sugestão, o que mudou no clima do time? O que mudou na eficiência do time? O que mudou no resultado de negócio do time? Traz isso para mim. E aí ela trouxe, organizou, mostrou para o chefe dela e o chefe dela vai trazer essa promoção para ela. Pelo menos prometeu essa promoção. E acho que é isso, de você ter um pouco, trazer talvez de forma um pouco mais consciente para ti, as ações que você está fazendo, qual o problema que você quer resolver e se você consegue mensurar de alguma forma. E aí, quando eu falo de métricas, várias métricas que eu posso utilizar, não só métricas de eficiência, que acho que a gente está muito acostumado, como agilistas, mas também de qualidade, de negócio e até culturais. Achei incrível a forma como você guiou ela ali para evidenciar, porque eu acho que a primeira forma de evidenciar que eu vivi era até um pouco parecida, mas tinha uma diferença que eu fazia isso muito para um gestor de engenharia e aí tem um gancho para um próximo papo, que acho que o mercado está mudando, que agora a gente tem os papéis de agile managers, e que acho que isso vai mudar um pouco, mas que a gente evidenciava muito o trabalho para aquele gestor de engenharia, que muitas vezes ele não sabia nem o que fazer com aquelas evidências. Ele talvez era a pessoa que deveria estar olhando para sua carreira e te ajudando a perseguir o próximo passo, mas muitas vezes para ele era só parte do resultado ali, e o que ele queria e o que ele era cobrado eram resultados mais específicos da equipe, aumento da eficiência, diminuição do tempo de entrega, redução de bugs e coisas desse tipo. Mas aí eu vivi um outro momento, falando de como evidenciar o nosso trabalho, aonde eu descobri um modelo que se chama Brag Document, que é documento de apreciação ou de autoapreciação, algo assim, que é um documento que o pessoal da Square, que é uma fintech, utilizava, e eu descobri através de um outro colega do Nubank, o Atanabe, e ele trouxe para mim ali como um exemplo de como ele evidenciava as entregas dele para avaliação, inclusive de performance. E esse documento basicamente o que a gente faz é a gente entregou quem foram as pessoas que estavam envolvidas naquela entrega e qual o impacto, seja o impacto com uma métrica específica do negócio ou alguma forma de medir esse impacto, que não seja só a entrega por si só, que a gente consiga tangibilizar ali esse impacto. E acho que isso me ajudou muito a me perceber dentro daquele ambiente como responsável pelas entregas e também conseguir orgulho das entregas que eu estava fazendo, do que eu estava construindo, conseguindo perceber que eu estava avançando. Que eu acho que é importante para qualquer pessoa e muitas vezes o agilista, como a gente comentou, fica nessa síndrome do impostor, ele não sabe se ele realmente é útil. E acho que o caminho está aí. Achei que contribuindo, nós aqui na K21, a gente acaba atuando bastante como agilistas em níveis organizacionais, talvez no Flight Level 2, Flight Level 3 e eventualmente a gente entra também nos times, no Flight Level 1. Quando a gente está falando de Flight Level 2 e 3, a gente está falando de uma jornada de transformação organizacional. Então, como a gente evidencia isso, também está muito relacionado com o que você trouxe. É meio que contar essa jornada de evolução. Então, de onde saímos para onde vamos, qual que é o nosso próximo passo que nos habilita a chegar onde a gente gostaria. E aí, nesse sentido métrica de sucesso, o que é sucesso para a gente transformação? A gente definir quais são essas métricas, acompanhá-las constantemente, porque as nossas ações precisam estar relacionadas com o que a gente quer. Senão, a gente ataca itens que não necessariamente vão alcançar o resultado que a gente gostaria. Então, evidenciar aqui nesse contexto é muito construir essa jornada, como se fosse esse timeline da transformação, evidenciando qual que é o próximo passo, o que é o resultado que eu estou buscando e quais são as ações que me viabilizam com que esse resultado aconteça. E se eu estou nessa posição de eu sinto que eu não estou conseguindo trazer o resultado que eu gostaria. Eu estou fazendo algumas ações, eu até saberia como medi-las, porém não estou conseguindo ver nesse curto prazo, curto médio prazo, que está tendo efeito. E estou me sentindo meio inútil aqui nessa situação. Quais ações vocês dariam de sugestão para essa pessoa? Eu vejo que a primeira coisa é realmente ela fazer isso pra ela, ela conseguir evidenciar pra ela. Então documenta em algum lugar, tenta criar, nem que seja um PowerPoint ali, uma apresentação aonde você consiga contar a jornada do que você está construindo. Como que foi o cenário que eu cheguei? Como é que estava o contexto que eu entrei quando eu cheguei? O que que eu estou fazendo ou pretendo fazer e como que isso está impactando aquele ambiente? E como eu vou medir esse impacto? E aí, de tempos em tempos, fazer um check-in ali. Falar, poxa, acho que todo mês ou a cada duas semanas eu vou parar e vou olhar. Eu estou progredindo mesmo em direção a esses objetivos que eu coloquei? E como que está sendo? Eu estou percebendo esse impacto? O que eu preciso fazer para perceber mais as entregas e os resultados do trabalho que eu estou fazendo? E acho que aí, por essas provocações e com esse storytelling do que você está construindo, contando essa história, acho que você começa a dar o primeiro passo de entender essas suas entregas e esse seu nível de responsabilidade sobre aquela estrutura, sobre aqueles trabalhos que estão sendo feitos. Eu pensei bastante também sobre adaptação constante. Todo plano está sujeito à adaptação, mesmo que você tenha ali evidenciado uma direção para você ir. Faz parte desse processo de adaptação. Então, nesse momento de reflexão que você tem que ter, de parar ali e analisar se de repente é o caminho, a gente está distante do caminho, essas são as melhores ações, a gente pode escolher outras ações para atingir aquele objetivo. Então, rever as estratégias para a gente atingir aquele objetivo faz parte do processo de revisão. Isso tem que ser constante. Quase que todos os dias a gente olhar para aquilo. Está fazendo sentido? Estou atingindo o resultado? Posso mudar a estratégia? Posso selecionar uma outra possibilidade, um outro caminho para resolver aquele problema? E aí a gente pode buscar, não é só o agilista, a gente tem o time também para ajudar. Faz parte também trazer essas reflexões para o time, que a gente pode estar estagnado e que a gente precisa buscar outras ações. Faz parte da revisão do processo. Eu acho que eu tive já em situações assim que eu estava me sentindo meio inútil e que, mais que as pessoas até me ouvissem, me considerassem, eu não sentia que havia uma grande movimentação. Com o tempo, eu comecei a perceber que aquele time não tinha uma ambição. Estava bom só fazer do jeito que estava. Então, mesmo que eu falasse, poxa, vamos fatiar mais fino, vamos pegar aqui as métricas de negócio, ver se está evoluindo ou não. Ah, não, vamos, vamos, mas aí não se colocava esforço para se mudar. Eles não estavam comprometidos em ser melhores. A gente não tinha uma ambição, a gente não tinha algo a perseguir, a gente estava só mantendo um produto que já, de certa forma, era um sucesso. Então, para que melhorar? E aí é uma questão muito de alinhar expectativas, na minha opinião, também. Não adianta eu querer melhorar o processo, ser mais eficiente, entregar mais valor, se ninguém ali está achando que precisa. Ali o pessoal está feliz com o dinheiro que aquele produto está trazendo. E acho que é uma questão de alinhar com o líder. Então, o que eu fiz, alinhei, copiei, olhei com o líder e falei e aí, o que vocês estão afim, gente? Vocês querem mesmo fazer alguma coisa aqui? Estou vendo que está há meses a gente está no mesmo jeito, que a gente está andando de lado nos nossos resultados e até no jeito que a gente trabalha. Nossa eficiência não está lá, as nossas entregas não são velozes. E a gente está andando de lado em relação aos resultados desse produto. É o que a gente quer mesmo? Está tudo bem para vocês? Tem essa conversa franca, essa conversa difícil. E, cara, estava tudo bem para eles. Então, nunca que eu ia conseguir tracionar uma mudança ali comportamental. Mas que eu podia fazer uma manutenção ou outra para que as pessoas continuassem utilizando práticas ágeis, trazendo uma provocação ali ou outra, mas também me retirar daquele lugar. De falar assim, acho que aqui não é o lugar para mim, porque eu queria mais. Eu queria me desafiar. Eu queria entregar mais. E ali, de repente, não era o lugar para mim também. Então, acho que ter muita clareza da situação atual, onde você quer chegar, é muito importante. Você medir as suas ações é muito importante. Você evidenciar que está dando certo ou não é muito importante. Mas você precisa ter essa clareza e esse alinhamento com as outras pessoas que estão em volta. Afinal, você não trabalha sozinho. Então, alinhar com o teu time, com a liderança, alinhar com a pessoa de produto, alinhar com aquela área que você está fazendo um coaching. Então, onde você quer chegar? Qual é o teu objetivo no final? Tu quer crescer mesmo? Se você não quer, se você não tem dor, se você não tem problema para resolver, vou para outro lugar. Ressignificar meu trabalho. Tem uma frase que eu ouvi uma vez e que conecta, de certa forma, com isso, que é que o agilista tem prazo de validade. Mas aí, eu vejo que não só isso. A gente também é protagonista e tem que ser protagonista daquela jornada que a gente quer trilhar. Então, eu acho que sim. Algumas vezes, o agilista vai perceber que, putz, meu prazo de validade aqui já deu. Ele não enxerga mais mudanças que ele precisa fazer. E tem um momento que, assim, o desafio aqui não é o tipo de desafio que eu quero perseguir ou não tem o nível que eu gostaria de perseguir. O time não tem ambição, não está me desafiando, não está me movendo para onde eu gostaria aqui ou me desafiando o suficiente. E aí, eu concordo total com você que o primeiro passo é alinhar com a gestão, com as lideranças para tentar perseguir, se conectar com outro desafio. E, talvez, tenha espaço para isso, inclusive. Eu acho que foi assim que eu comecei, inclusive, a absorver outros trabalhos, por exemplo, ah, mais de um time de uma vez, um outro contexto ali, ó, tem um trabalho ali que parece ser legal. Vai lá e vê se faz sentido você tocar aquele trabalho ali. Eu penso bastante nisso que a Bia trouxe da gente ter clareza também de onde a gente está atuando, para a gente não estressar mais o sistema do que o sistema suporta o estresse. Então, às vezes, a gente também, como agilista, tem essa coisa da ambição do, ah, melhoria contínua, preciso fazer aqui, preciso dar resultado. Só que, talvez, não seja o momento daquele time de estar nesse momento de busca de resultado, de alavanca, de crescimento, e a gente precisa saber reconhecer esses cenários. Então, acho que uma outra habilidade que a gente tem é essa de leitura de cenário, de entendimento, de levar isso para a discussão. Porque a gente, de fato, não pode levar a escada no sistema do que o sistema aguenta. Será que a gente está falando aqui de entender as ambições, entender os objetivos? Em algum momento aqui a gente falou de estratégia, falou de OKRs. Fê está falando aqui nos bastidores sobre o ownership do agilista nessa gestão de resultados. A gente tem passado por muitas organizações que estão começando aí com a cultura de OKRs e sempre surge a polêmica. Quem é a responsável? Sabe pelo quê? Quando a gente está falando de gestão de resultados, no OKR. Sou eu que crio uma ação? Sou eu que crio uma iniciativa? O que eu posso fazer para contribuir para o processo? E aí aqui eu queria trazer um ponto que eu vejo como uma oportunidade, que talvez a gente possa explorar mais toda vez que a gente estiver trabalhando com gestão de resultado. O agilista, ele acaba sendo um habilitador, um habilitador desse processo. Quando a gente está falando de gestão de resultado, a gente está falando de entregas em ciclos curtos que são acionáveis. Então a gente tem OKRs para medir essas entregas e acompanhar os resultados. Como que o agilista pode contribuir aí, sendo efetivo? Olhando para quais são os problemas que a gente pode resolver para atingir aquele objetivo. Então, estruturação dessa narrativa dentro do time. Uma vez definido quais são os nossos objetivos, como que a gente identifica quais são os problemas que a gente pode resolver para poder mobilizar aqueles OKRs? E promover essa discussão dentro do time é extremamente essencial. Porque, no fundo, o backlog dos times precisa refletir o que está sendo proposto dentro dos objetivos. Então, se a gente não levar essas provocações para dentro dos times, para que eles discutam o que a gente deveria estar fazendo em termos de ação para contribuir com aquele resultado final, a gente está perdendo parte do nosso potencial, que é mobilizar as pessoas em prol do resultado. Então, para mim, assim, polêmico, mas agilista, a gente precisa incentivar mais os times a desdobrarem os OKRs. E aí eu vejo que a gente tem muito potencial. Vamos fatiar, vamos focar no problema, vamos fazer boas perguntas e vamos garantir que as métricas de sucesso estão sendo acompanhadas. Para mim, fundamental. Você traz aqui um lugar muito de um champion ali, que vai fazer esse coach com os líderes dos objetivos. E esses líderes vão conversar com os POs e garantir que, poxa, eu estou priorizando aquilo que faz sentido, mas também como um facilitador, um questionador, um coach mesmo, durante os check-ins ou durante o acompanhamento dos POs, vai trazendo esses questionamentos. Porque eu acho que também, o que eu percebo acontecer nos lugares em que eu já trabalhei com projeção de resultado. Às vezes eu sinto que o agilista é muito mais capacitado do que as outras pessoas que estão ali tocando a própria vertical. Então, às vezes, o líder mesmo da vertical, ele entende do negócio ali, mas ele não entende muito do método de OKR, por exemplo. Então, nem ele sabe muito bem como questionar, como trazer boas perguntas, como fazer boas provocações. E aí, o PO, às vezes, ainda precisa de uma ajuda em relação ao, tipo, poxa, eu estou sendo exigido de tantas coisas, como é que eu priorizo problemas que vão efetivamente impactar isso daqui? E aí, o agilista acaba pegando uma carga meio grande ali, por ter esse conhecimento, por ser visto como essa pessoa facilitadora, por ser essa pessoa questionadora. Mas será que não fica muito pesado pra ele? Antes até da gente de entrar nessa polêmica de ser pesado ou não, eu acho que tem um outro ponto que muitas empresas acabam esquecendo por conta da moda de usar o framework, o modelo dos OKRs. Qual que é o propósito dos OKRs? O propósito dos OKRs é foco. É fazer a empresa toda remar pro mesmo lado, assim, todo mundo focado naquela mesma direção. Apesar da gente ter um desdobramento ou ter o alinhamento de OKRs, a ideia é que a gente foque naqueles objetivos que são estratégicos. E aí o que acontece é que isso também precisa refletir nos backlogs, nas priorizações de produto, nos portfólios, e o que acontece é que não reflete. Essas empresas, elas definem um objetivo lindo, maravilhoso, que results, mas não despriorizam as coisas pra que tenha foco. Eles deixam de falar não ali, deixam de falar não pra várias coisas que não estão agregando pra aqueles objetivos. Então eu acho que o agilista tem um papel fundamental em ajudar a gerar esse foco e provocar nos níveis mais operacionais e táticos ali da empresa que a gente gere foco. E um último aspecto que eu acho que o agilista também contribui, que pra mim tá no centro dos OKRs, é o coração dos OKRs, que é disciplina. A gente precisa ter disciplina pra definir, acompanhar, gerenciar os ciclos de OKR. E o agilista com a skill de facilitação e essa skill de boas perguntas que a gente já falou aqui, de provocação, consegue ajudar muito a manter essa disciplina em cima do método e dos ciclos de OKR. Então acho que tem essa provocação aí dentro desse contexto de agilidade e OKRs. Eu ainda saio com uma sensação de que pelo menos nos lugares que eu participo, o agilista parece que ele tá gerando tantos pratinhos e que ele precisa continuar gerando muitos pratinhos, senão algum vai cair. Acho que foi legal a gente falar sobre um pouco desse ownership, da responsabilidade dele, de como eu meço que ele tá agregando ou não. E até dar um pouco de clareza de que, às vezes, não é necessariamente responsabilidade dele, mas que ele tem um papel ali muito forte de facilitar, de questionar, de trazer boas práticas, que de repente ele vai ser a pessoa que vai ter mais conhecimento ali na sala pra trazer esses questionamentos. E acho que é legal ele ir lá e contribuir. Ele entender que o papel dele é trazer essas provocações, é trazer caminhos. Mas não necessariamente ser o dono de tudo. Porque também acho que vai pro lugar do agilista herói. Ah, eu preciso estar em todas as reuniões, eu preciso estar envolvido em tudo, porque se eu não estiver lá, as pessoas não vão conseguir tomar as decisões. Não, não é bem assim, gente. Se você fez um bom papel ali, como coach, como facilitador, como questionador, e até trazendo caminhos, depois é as pessoas trabalharem, se virarem um pouco sozinhas também. E deixar muito claro o que é a responsabilidade de quem. Com certeza. Acho que não queremos heróis, queremos pessoas que possam contribuir dentre as mais diversas especialidades e focos que elas têm. Se a gente estiver, de fato, delegando tudo pra uma única pessoa, a gente tá perdendo a capacidade das outras de contribuírem. A gente não pode responsabilizar uma pessoa pelo processo. O agilista, ele é essa pessoa que tem essa visão grande e ampla, e por isso que ela pode ajudar nesses questionamentos, nesses movimentos. Pelas habilidades mesmo, pelos soft skills também que ele tem. Então é muito nesse sentido. Eu tenho uma percepção que aconteceu com o agilista e o que aconteceu muito com os desenvolvedores de software. No começo, o desenvolvedor de software, ele era desenvolvedor de Java. Especificamente, ele é Java. E aí, com o tempo, começaram a surgir várias outras tecnologias, linguagens. E aí, o pessoal começou a ver nas vagas, nas oportunidades ali pedindo várias tecnologias diferentes. E aí, a gente viu uma mudança no mercado que foi a gente parou de chamar as pessoas ali desenvolvedoras de desenvolvedor Java, desenvolvedor C Sharp pra engenheiro de software. Onde, assim, então você vai ter um conhecimento de resolução de problemas através da programação. Agora, qual linguagem, qual tecnologia começa a ser indiferente. O que as empresas acabaram mudando e buscando eram pessoas que conseguissem resolver problemas através do software. E eu acho que com o agilista tá acontecendo algo parecido. Porque se for ver o arcabouço, o tanto de coisas que a gente acaba conhecendo dentro de muitos aspectos diferentes. E cada vez que a gente muda de negócio, a gente teve que aprender daquele negócio ali pra poder fazer as provocações e tudo mais. Então, eu acho que a gente tá chegando nesse momento na carreira, na jornada do papel do agilista, que é ser quase como um engenheiro de alguma coisa. Poderia falar engenheiro de processo, mas acho que aí eu tô pegando muito estritamente ali a processo e acho que não é isso. Mas a gente tá chegando nesse papel, que ele é mais agnóstico, ele conhece de muitas coisas e o ponto é resolver problemas. Como a gente ajuda as empresas a resolver problemas com as ferramentas que a agilidade tem embaixo do guarda-chuva. Tem uma frase também que eu gosto muito, que fala sobre isso, que é não é sobre método, é sobre soluções que resolvam problemas. Então, encaixa muito com o que você falou aqui. Agilidade vai conhecer de diversos métodos, mas o conhecimento também hoje já é um commodity. A diferença é o que a gente faz com esse conhecimento. E aí é que tá o diferencial do agilista. Porque hoje você pode procurar tudo no Google. Tem lá o que é link, é screen, o que é XP. Mas o que a gente faz com esse conhecimento é o nosso diferencial.