: :
os agilistas

#59 Perguntas & Respostas

#59 Perguntas & Respostas

os agilistas
: :
M1: Bom dia. Boa Tarde. Boa noite. Bem-vindos a mais um episódio de Os Agilistas. Estou aqui novamente com o Vinição. M2: Tudo bem, galera? M1: E o Régis. M3: E aí, pessoal, beleza? M1: A gente teve uma repercussão muito boa com o primeiro Perguntas & Respostas. Vamos fazer mais um agora. Já vou começar direto então lendo uma pergunta. Antes disso, lembrar mais uma vez, se vocês quiserem mandar comentários, mensagens, a gente tem agora um WhatsApp para isso. O telefone é (31) 99697-7104. Tem o e-mail também: osagilistas@DTIdigital.com.br. Algumas mensagens não estão identificadas, mas a gente tem uma pergunta aqui interessante. Eu vou lê-la aqui agora. A pergunta é a seguinte: “como lidar com um cliente que quer um projeto ágil, mas não consegue embarcar nisso e fica sendo aquela coisa arcaica e que deixa todo mundo doido? PO que não se envolve, ordens aleatórias que não entram no backlog, etc. Vocês poderiam falar um pouquinho sobre isso? Seria ótimo”. Então, esse cenário aí não é tão incomum. Acho que tem dois cenários, que o Régis vai comentar. Tem o cliente que nem quer o ágil e aí é mais difícil ainda, mas tem até o cliente que quer o ágil, mas não deixa a coisa acontecer. O que você teria a falar um pouquinho sobre isso, Régis? M3: Quando a gente viu essa pergunta, eu disse que esse cenário que ele descreveu nem é o inferno completo. Pelo menos ele disse aí que o cliente quer o projeto ágil. Dá para ser pior, que seria o segundo cenário aí, quando o cliente nem quer o ágil ou te contratou pela entrega do software, por exemplo, no nosso caso, e aí você tenta implantar o ágil e tem os conflitos aí com a cultura dele. É evidente que embora não seja um caso incomum, como o Schuster falou, que a gente não vai ter uma receita de bolo aqui para isso. Porque cada cliente, e a gente investe muito aqui nisso, cada cliente demanda uma resposta diferente, uma estratégia diferente, uma maneira de agir diferente, mesmo que seja a mesma entrega e o mesmo tipo de serviço. Eu acredito que uma das coisas que ajudam é a fase inicial. Embora a gente não trabalhe com a fase de planejamento completa, a gente tem alguns ritos no início que ajudam justamente a embarcar o cliente na ideia do projeto. Por exemplo, as dinâmicas que a gente chama aqui de mission command, que é onde a gente define os objetivos, os resultados chave e as dinâmicas de design sprint, que normalmente se seguem a essa, são dinâmicas que, em geral, a gente tem obtidos bons sucessos na venda da ideia para os níveis mais altos da empresa no envolvimento e no engajamento dos níveis mais altos da empresa e nessas reuniões a gente costuma aproveitar, dependendo do nível da empresa que está contratando, para explicar como é que vai ser a metodologia do projeto a partir dali, como é que funciona o ágil, depende da maturidade da organização. Isso seriam algumas dicas mais gerais que eu acho que poderiam ajudar também a conseguir esse compromisso no início. Uma outra coisa é que, assim, se o cliente quer o ágil, então você pode sempre apelar para o lado da coerência. Se ele pediu um projeto ágil e por alguma razão ele está com uma dificuldade de embarcar o PO ou de se envolver de forma própria, você sempre tem o caminho de apelar para a coerência dele. Você não quer o ágil? Então deixa eu te ajudar a fazer o ágil da forma que é e explicar isso exige de nós que estejamos prontos para explicar mais a questão dos princípios, dos valores, porque a gente entende que é melhor fazer assim do que da forma tradicional, porque também se a gente chega, simplesmente, com o discurso de que é assim que faz e pronto, eu acho que isso gera mais resistência do que qualquer outra coisa, então tem que estar muito pronto para explicar, para apelar para esse lado mais didático da coisa também. Seriam algumas dicas que eu pensei aqui. Não sei se vocês teriam outras. M1: Uma coisa que me vem muito à cabeça, eu lembro do Vinicius falando sobre alguns contextos. Um rito importantíssimo no ágil é análise crítica, que, na verdade, é uma reflexão para ser uma equipe, um time aprender a aprender. Então é uma coisa que eu tenho visto nos últimos anos, principalmente que o ágil está ficando mainstream, ou seja, é igual o que você comentou, o cara quer realmente e precisa fazer aquilo, é ter análises críticas que envolvam o próprio cliente e que mostrem a verdade não em um tom acusatório, em uma vontade de aprender. Por exemplo, uma das piores coisas que pode ser para uma frente ágil, que quer gerar valor, é PO que não se envolve ou, então, atendimento a agendas pessoas ao invés de tentar priorizar baseado em negócio. Idealmente, isso tem que emergir uma análise crítica, e é bom, inclusive, ter análises críticas no âmbito do projeto e no âmbito do (inint) [00:04:58] do patrocinador do projeto, mostrando que dá para o caminho ser diferente. É claro, para tudo que se fala tem chance de alguém falar que não vai adiantar, não é? É claro que se no limite, obviamente, a organização não quiser, a liderança não mudar e começar a conduzir tudo da forma convencional, não vai mudar, mas partindo do princípio que você colocou de que no fundo o cara quer, mas é quase uma questão de entendimento, de ele não estar entendendo certas coisas, de estar com certos receios, acho que isso é muito importante. E tem outras iniciativas de educação também. Tem muitos clientes nossos que têm usado o podcast como um dos canais para tentar chegar em outras pessoas e dar exemplos. Você tem mais algo a acrescentar, Vinição? M2: Eu vejo que a gente tem observado algumas situações na DTI e ao longo dos anos a gente foi vendo uma necessidade da nossa oferta ser mais completa, até para endereçar esses pontos aí. É claro que você não tem que necessariamente contratar a DTI, mas você usar um (de para) do que a gente faz. Então a gente viu a necessidade de ter uma oferta para treinamentos, que é o DTI. Você buscar coisas do tipo no DTI, aonde você estiver, aí na sua cidade, na sua empresa, buscar ofertas que ajudam a treinar os membros dos times que são do seu cliente, por exemplo. Uma outra estratégia que tem muito a ver com priming, que o Schuster falou que tem um certo nível de influência presencial em um esquema quase de game (inint) [00:06:30], que a pessoa está presente, que aqui a gente tem uma oferta que é o garden, que a gente chama, que o cliente fica junto com a gente e a gente influencia o cliente. Então o jeito de você fazer isso é ficar fisicamente em algum lugar, sei lá, em um coworking, alguma coisa assim, que já pratique o agilismo e de repente você consiga convencer o seu cliente mais pelo exemplo, mostrando o que está acontecendo no dia a dia. Nós temos ainda outra oferta que é uma espécie de consultoria, que não é uma consultoria tradicional, que é uma consultoria quase de mentoria, onde você vai ajudar o cliente, mas ele vai executar boa parte do trabalho, que a gente chama de (inint) [00:07:07] e que tem outras empresas que fazem também e a gente tem a nossa oferta aqui. A gente tem uma oferta não só da execução, mas também uma oferta mais completa, que a gente chama de universo DTI aqui, que tende a endereçar todos esses aspectos que você colocou aí. M1: No fundo, a gente sempre remete para dar o primeiro passo, no sentido de que você tem que tentar destravar um ciclo virtuoso, criar um ciclo virtuoso. Aí você vai atacar em todas as frentes. Você vai atacar nessa parte de educação e vai, principalmente, na minha visão, tentar gerar ação dentro da organização a partir dessas análises críticas, que é inclusive uma das coisas que o (inint) [00:07:42] tenta gerar, que é o que a gente chama de looping desses times que conseguem empreender. O mais importante é isso. Se você está entregando com cadência, não tem tanto problema um PO agir mal durante duas semanas, por exemplo, desde que você identifique e corrija isso rápido. O time que aprende a corrigir as coisas rápido talvez consiga reverter um processo desse, mas sem comprometimento da alta liderança vai ficar muito difícil. É isso. M: Oi, Denise. Oi, Schuster. Bom dia. Boa tarde. Boa noite. Meu nome é Rodrigo Perestelo, sou coordenador de uma instituição financeira. Ando ouvindo bastante o podcast de vocês, quero dar os parabéns, vem abrindo bastante a minha mente, o meu conceito sobre agilidade. Tenho certificação de Scrum Master. Venho estudando bastante o tema, mas eu queria ver com vocês como que a gente usa esses conceitos de agilidade com a sustentação dos sistemas. Após um produto ser lançado, uma feature ser lançada, como que é essa passagem do time que faz a sustentação dessas peças, como é a integração entre esses dois times, como o DTI costuma trabalhar assim com alguns clientes. Agradeço desde já. Um forte abraço e, mais uma vez, parabéns. M1: Oi, Felipão. Tudo bom? M: E aí, pessoal, beleza? M2: Felipão estava ficando deprimido ali, porque não estava participando dos episódios. M1: Ele passou várias vezes na porta aqui do estúdio, querendo entrar. M3: Cara chorosa… Aí eu deixei. M2: Fala aí, Felipão. Estava na trincheira. M: Exatamente. Enquanto vocês estão aqui falando para o podcast, eu estava executando o que a gente fala. M1: É bom ter alguém aqui que executa. Felipão, o que você diria sobre? Essa questão de sustentação é engraçada, porque, no fundo, esses assuntos convergem quando a gente fala de squads e de diferentes digitais. Fala um pouquinho sobre isso aí, Felipão. M: A experiência que eu já tive no assunto, eu dividiria em dois aspectos. A pergunta fala sobre como fazer a passagem de bastão de uma feature que acaba de ser entregue para o time que faz sustentação. Eu já acho que não deve haver essa passagem de bastão, porque se a gente está falando de um produto, nessa primeira visão, o squad tem que ser responsável por novos features e por sustentar a aplicação. Uma coisa que a gente já falou até no episódio anterior, que um backlog de um produto tem que ser composto por feature, sim, mas também por bugs, (inint) [00:10:20] técnicos. Então a sustentação é feita pelo próprio time. O bug passa a ser uma história comum do time daquele produto, porque ninguém melhor de estar contextualizado no assunto, ter o conhecimento de causa para sustentar o produto do que o próprio time do produto. Agora, quando a gente está falando já de aplicações que já são legados, já estão em operação e não existe um squad atuando de forma contínua… M1: Só um comentário. Então eventuais aplicações você talvez aposente, porque não justifica ter um squad. M: Não justifica ter um squad cuidando. Aí, sim, a gente vai para um ambiente de sustentação descentralizada. Aí a experiência que eu já tive em um ambiente de sustentação descentralizado, fazendo aí o paralelo com o agilismo, o que melhor funcionou é a gente colocar o time em operação de Linkan Bain, o método mais próximo de Likan Bain, em que você consiga tentar limitar alguns working progress, que a gente sabe que na sustentação é, às vezes, inevitável, mas tentar levar o bug, o chamado, até o fim. Por que eu estou falando isso? Porque no início dessa experiência que eu tive com sustentação centralizada a gente elevou muito o número do nosso work in progress, e aí você acaba se perdendo no contexto de um problema que você começou a organizar, às vezes, uma semana atrás, e a gente convergiu bastante quando entramos em modo Linkan Bain, em que a gente tinha o máximo de work in progress, três por desenvolvedor, três chamados. A gente entrava em um ciclo ali de, às vezes, está parado na validação do usuário. A gente ficava enchendo o saco do usuário até conseguir, realmente, ir até o fim. M1: Ficar cada um passando o bastão com uma meta local, assim. M: Exatamente. M1: Fechar o chamado da perspectiva dele, não é? M: O que, no fim, acaba acontecendo. M1: Para resolver o problema. M: Exato. Se a gente não tiver essa orientação forte em resolver o problema, a gente começa a aumentar muito o work in progress, aumentar muito a fila e começa a fazer fechamento de chamado à força. O problema não foi resolvido. Eu vejo mais por esse lado, sabe? M1: Só um comentário. Esse primeiro cenário que o Felipão disse, para um squad poder, de fato, assumir a sustentação da frente pela qual ele é responsável, você tem que estar com o conceito do agilismo na veia mesmo. Por quê? Primeiro, esse squad vai ter que ter um espaço para isso no backlog. Alguém que cobra constantemente, alguém que quer uma previsibilidade total e que não aceita, a gente já falou várias vezes… M2: O Burndown não pode ter nenhuma variação em função de um novo problema, não é? M1: O Burndown não pode ter variação e se aquele time entregou menos… Pensa bem, o time tem que fazer o que é mais importante. Se em dado momento é mais importante uma pequena melhoria ou corrigir um bug crítico importante, aí o time vai fazer aquilo. Então isso exige uma maturidade, vamos dizer assim, de gestão, para entender as variações e, na minha visão também, para isso acontecer de verdade você tem que estar com uma série de ferramentas de DevOps em ação para o time, realmente. Porque, assim, se é um fardo muito grande para aquele time cuidar, toda hora, vamos supor, para acessar um ambiente é difícil, para fazer aquilo é difícil, para colocar um deploy é difícil, aquilo atrapalha tanto o time que você fala assim, “deixa isso para alguém fazer e mesmo eles tendo mais eficiência”. Você concorda? M: Se o time está com esse tipo de problema de autonomia, de DevOp, de implantação, ele tem um problema até anterior à sustentação, porque provavelmente eles vão estar com esse mesmo problema para poder evoluir. M1: Eu comento isso porque, às vezes, a causa raiz é essa. O cara separa porque ele fala assim, “o cara é muito ineficiente para ficar dentro do time”, mas a solução, às vezes, não é separar, é ir na causa raiz dessas ineficiências. M: Eu não sei qual é o formato da sustentação no caso do Rodrigo, mas um conselho que eu daria para ele é tentar identificar, se for uma sustentação centralizada, o que é produto ali e começar a transferir a responsabilidade desses chamados de produto para os times de produto, de fato. M1: É engraçado. O conselho para um modo tradicional é ficar o mais lean possível. M: Exatamente. M1: E para a frente de produto é trazer para dentro do contexto da frente de produto. M: É claro que, assim, em equipes de sustentação centralizada existem métodos como (inint) [00:14:34] que ajudam também a fazer a gestão, mas eu acho que o principal ponto aí, realmente, é tentar identificar se tem produto ali no meio e tentar se tornar o mais lean possível quando a gente está falando de centralizada, e quando a gente está falando de produto, é colocar para o produto cuidar. M2: Eu podia fazer só uns comentários, assim. Na minha visão, a melhor estrutura mesmo, bem saindo do muro mesmo, é estar dentro do squad. A sustentação está dentro do squad por um fator crucial, que aumenta a responsabilidade intrínseca do time. O time passa a ficar muito mais responsável pelo o que ele gera, aí essas questões de evolução de DevOps, que a gente comentou aqui, nascem até porque se a pessoa que faz é a pessoa responsável por em um final de semana atender os chamados, ele vai querer muito automatizar as coisas, aumentar e melhorar a qualidade do que está entregando, mas há divergências. Se você tem uma variabilidade muito grande em algum produto, o que eu quero dizer com isso? Vamos supor: tem um produto que, de vez em quando, não tem chamado nenhum. Vários dias sem chamados, mas, de vez em quando, tem uma rajada de chamados ou pequenas demandas. Como lidar com isso? Você vai montar um squad só para isso? É meio complicado, não é? Outro aspecto é o seguinte: quando está dentro do squad, normalmente é um rodízio. Não tem uma pessoa só, que a pessoa da sustentação, porque ia ser muito frágil. As pessoas vão girando aí, mas, por exemplo, o Google tem um papel que eles chamam lá de SRE, que é Site Reliability Engineering. Às vezes, tem times que são só desse papel. O que eles fazem é que eles selecionam as pessoas que têm um perfil adequado para isso, porque normalmente é um papel muito estressante. É o cara que gosta muito da emoção. Eles fazem uma seleção, já li alguns artigos, própria para isso. A pessoa tem aquele perfil ali, não liga de ser acionada fora de hora. O cara até gosta. O que eu estava voltando, falando sobre a questão da variabilidade, o que você pode fazer, nesse modelo do Google é um modelo mais centralizado, igual o Felipão estava falando. Talvez, você pode acumular produtos que tem grande variabilidade e normalmente quando você junta muita variabilidade, a variabilidade total diminui. É uma saída. Tem um livro que se chama Building Microservices, do Sam Newman, que tem um capítulo em que fala especificamente sobre isso, sobre estruturas de times para você conviver com modelos de produtos que têm muita variabilidade. Aí ele tem algumas estratégias, não vou lembrar de cabeça. Foi interessante que teve uma (inint) [00:17:21] hoje eu citei isso. Eu lembrei aqui agora e é uma fonte bacana de conhecimento sobre isso. Ele fala várias estratégias. Por exemplo, tem um modelo de open source interno, aonde tem alguns caras que são os caras que fazem as revisões, os code reviews, mas as pessoas que estão mudando o sistema, às vezes, estão em outras squads, mas precisa de ter o code review, ter o carimbo de entender daquela solução. Então eu comendo ele ler esse livro aí. Eu não lembro exatamente o capítulo, mas é um capítulo que fala de estrutura de times para situações de variabilidade alta. M1: Pessoal, mais uma mensagem anônima. “Bom dia, agilistas. Primeiramente, gostaria de parabenizá-los pelo podcast e pelo excelente trabalho que postam constantemente. Também vim para agradecer o conteúdo e temas de extrema relevância nos podcasts. Por através destes pude aprimorar os meus estudos durante o meu tempo de locomoção. Não só de vídeo aulas um estudante vive. Por fim, venho a vocês com duas perguntas. Estou em busca de uma boa leitura sobre metodologia ágil. Qual leitura vocês indicariam? E qual o nome do livro que o Marcelo menciona no (inint) [00:18:34] dezesseis: atenção ao feedback? Desculpe, tenho um nome, sim. Me chamo Pedro Faraj”. Só respondendo aqui, o livro que eu indiquei aquele dia se chama Nine Lies About Work. Eu não sei se já existe uma versão em português. O autor se chama Marcus Buckingham e Ashley Goodall. Régis, qual livro você indicaria? Dentre vários, qual te vem à mente? M3: Eu vou indicar o último que eu li. Não sei se tem em português. Me indicaram em inglês, então eu nem procurei. Chama: A Seat at the Table. O autor se chama Mark Schwartz. Aí tem o subtítulo. É: IT Leadership in the Age of Agility. Por que eu gostei desse livro e eu recomendo ele? Ele é um livro que trata muito sobre a relação negócios e TI. É uma das coisas de que a gente, inclusive, fala bastante aqui quando a gente está falando sobre business agility, sobre essa relação abusiva entre negócios e TI. Eles chamam esse A Seat at the Table, esse assento à mesa, justamente tratando como que o CIO dentro das empresas, muitas vezes, é tratado de forma diferente de outros diretores, diretores de outras áreas e, muitas vezes, ele tem que se provar além até do que seria saudável. Nessa discussão entre negócios e TI, ele trata muitos desses conceitos que a gente aborda no podcast sobre como que deve ser uma TI verdadeiramente ágil, como que isso, inclusive, ajuda a destravar o potencial da organização no uso da tecnologia. Um livro excelente. Eu recomendo muito. M1: E você, Vinição? M2: Um livro que eu gosto bastante, estou precisando até dar uma relida nele, porque é muito bom livro, o Schuster sempre fala isso, livros muito bons têm que ser relidos várias vezes. M1: Os (inint) [00:20:18] falam para fazer isso, mas eu faço o contrário. Eu fico tentando ler 400, mas os (inint) [00:20:22] falam que você deveria dominar um bom livro. M2: Eu gosto de reler alguns livros bons. Esse livro, eu acho muito bom. Acho que é uma das melhores coisas que eu já li, que se chama The Principals of Product Development Flow. É um livro do Donald G. Reinertsen. Esse livro eu acho bem interessante, porque ele meio é meio de (inint) [00:20:43] e meio de linha, uma mistura dos dois. M1: Mas ele é complicadão, hein? M2: Esse livro tem um embasamento matemático e estatístico muito forte com a teoria de filas. Ele é bem legal, mesmo, e ele tem algumas questões de estrutura. Ele fala sobre descentralização. M1: Ele é citado em vários lugares. Os caras citam esse autor, porque o livro é bem profundo. Ele não é uma leitura, digamos, introdutória. Por um lado, tem todos os princípios ali que o cara coloca, mas só para quem vai ler, é uma leitura que não é tão fácil. Ela não é tão narrativa igual um livro de negócios tradicional. Por exemplo, o A Seat at the Table é um livro mais palatável. M2: São cerca de 170 princípios que ele vai dividindo em torno de temas. Por exemplo, teoria de filas. Aí tem um capítulo, por exemplo, que é só sobre centralização versus descentralização. Ele faz várias analogias com a parte de redes, que tem um ambiente bem caótico, bem descentralizado. Ele faz algumas analogias com o exército, a guerra, que são ambientes onde é difícil você manter um plano prescritivo, então faz analogias com isso. É bem legal, mesmo. M1: Beleza. Já que vocês citaram dois livros, eu vou citar um livro aqui. A gente já falou muito dele em outros episódios. Não é de agilismo diretamente, mas como a gente sem fala que uma das coisas mais importantes é mudar a liderança e que isso, talvez, habilitasse o resto todo, é um livro que já foi citado, que é o The Meaning Revolution, do Fredy Kofman. A gente já fez podcast sobre isso, sobre o líder trasncendental. Eu acho ele muito interessante por causa disso. Uma das maiores dificuldades é o líder entender o seu novo papel e, talvez, quando alguém pergunta como é que começa uma transformação, a verdade é que se a liderança começasse a entender melhor qual o seu papel, ela, talvez, já começasse a criar o espaço para a mudança. É uma leitura que eu recomendo demais. E aí, Felipão? Qual leitura você recomendaria para o nosso ouvinte? M: Eu vou recomendar um livro especificamente, não, mas do último conjunto de leituras que eu fiz, que eu achei muito bom. É de um site encabeçado pelo Alistair Cockburn, que é um dos signatários do manifesto ágil, inspirado por uma palestra dele no último Agile Brazil, que é heartofagile.org. Lá tem um conjunto bem interessante de artigos, de vídeos. Recomendo um artigo principal, que é onde ele descreve, e um vídeo em que ele descreve, sobre esse conceito que ele está retrazendo, está resgatando. M1: Está resgatando a essência do ágil. M: Exatamente. Até na palestra ele comenta que ele acredita que os métodos ágeis foram um pouco desvirtuados desde 2001, quando eles assinaram o manifesto e se tornaram muito comerciais, muito prescritivos, quando, na verdade, a gente tem que se apegar com algo que está bem anterior a isso, que é o que ele chamou de heart of agile, que é o Colaborate, Deliver, Spect – se não me engano – e o Improve. Você colabora para entregar e você inspeciona para melhorar. Se você internalizar bem essa filosofia, não importa nem muito qual o método que você está utilizando, você vai conseguir se transformar e ter uma mentalidade mais ágil. Recomendo acessar lá o heartofagile.org. M1: Lembrando que o Alistair Cockburn fez um Enzimas para a gente. M: Exatamente. M1: Onde ele fala justamente sobre esses princípios, Colaborate, Deliver, Reflect e Improve. M: É Reflect. Colabora para entregar e reflita para melhorar. M3: Eu acho que é heartofagile.com. M: Correção aqui ao vivo pelo Régis. Heartofagile.com. M: Bom dia. Boa tarde. Boa noite. Meu nome é Roberto. Sou coordenador da equipe de automação e BI do Itaú Unibanco. Eu ouço o podcast desde o começo, já ouvi todos os episódios e toda quinta-feira busco avidamente o episódio mais atual, o novo conteúdo que vocês lançam. Também gosto bastante do conteúdo do Enzimas. Queria deixar o parabéns para toda a equipe dos agilistas pela forma que vocês compartilham esse conteúdo. Eu acredito que seja o primeiro podcast em língua portuguesa de agilismo. O fato de vocês não serem focados em uma metodologia, focados em uma maneira de trabalhar e também não serem prescritivos faz muita diferença. Faz com que com que quem ouve o podcast tenha que fazer as suas próprias reflexões, suas próprias análises e tomar uma decisão, de que maneira aquela pessoa quer trabalhar, de que maneira a pessoa quer conduzir ali o seu trabalho, o seu desenvolvimento. Uma dúvida que eu tenho é como que vocês lidam com a questão de um backlog priorizado, um backlog com entregas de valor já definidas, eventualmente, um code map. E em um projeto ágil, quando você já fez o lançamento de alguma funcionalidade, já tem uma versão no ar, você já começou a receber uma série de feedbacks, queria saber como que vocês lidam com o tratamento desses feedbacks dessa versão que está atualmente no ar versus o Roadmap do produto ali, as novas funcionalidades, os novos recursos que provavelmente já tem ali uma expectativa de um retorno de valor, versus os feedbacks dos usuários ali, que podem estar reportando problemas, funcionalidades que podem ser melhoradas, novas funcionalidades e como que vocês administram isso. Obrigado, pessoal. Valeu. M1: Roberto, muito obrigado pela pergunta. Vamos explorar esse tema. Acho que é um tema bem importante e ele está muito atrelado com essa cultura tradicional das empresas, que, no fundo, nunca entendem que o Roadmap poderia, na verdade, ser a mesma referência inicial que você iria perseguir e iria se adaptando àquilo. Mas para ir mais direto ao ponto, eu queria primeiro que o Felipão explorasse esse assunto. Felipão, isso, no final das contas, não é uma mera questão de praticar continuamente engenharia de valor? M: É exatamente isso. Acho que você praticamente já deu a resposta mais simples possível para essa pergunta. Eu acho que você está certo, sim. Eu acho que a criação ou a necessidade de um Roadmap surge muito. Eu acho que a gente pode discutir mais o assunto, mas com a necessidade de uma orçamentação, de garantir (inint) [00:27:23] ship com a alta liderança, mas quando, na verdade, eu acho que o time tem que enxergar um Roadmap do que um guia inicial do que vai ser tratado com maior valor ou quais são as maiores hipóteses. Ele fala sobre como a gente trata isso em relação aos feedbacks do mercado. Eu acho que o feedback do mercado é muito maior do que o Roadmap, afinal, um dos princípios ágeis é adaptar a mudança ao invés de seguir um plano. Igual você disse, é uma engenharia de valor constante. O feedback tem que gerar reflexão e esse Roadmap pode e deve ser revisto constantemente. M1: A gente respondeu há pouco uma pergunta sobre os livros e o Vinição citou o livro do Principals of Product Development Flow, alguma coisa assim… M2: Donald G. Reinertsen. M1: É interessante, porque ele começa o livro, ou estou enganado, o Vinição deve lembra, meio que falando assim: “cara, você tem que partir do modelo econômico correto”. E o modelo econômico que ele começa, partindo, é um modelo de ser costumer centric, que é um modelo de ser chamado pelo cliente, e nesse modelo, pensando em lean, o que mais importa é o quê? É o cost of delay. Ainda que isso não seja tão simples na prática, ninguém está falando que isso é simples na prática, é como se você sempre tomasse as decisões, principalmente em um mundo mais dinâmico, baseado no custo que o atraso daquela funcionalidade pode trazer para você. Você deixa de fazer um experimento, deixa de colocar uma funcionalidade, e o custo desse atraso pode ser muito alto, mas aí eu penso assim, essa é a resposta direto. Mas o que é interessante para poder tentar contribuir bastante com a pergunta? M2: Só complementando o que você falou. Eu acho que um jeito de praticar a engenharia de valor é, de fato, através desse modelo do Donald, que ele coloca no livro, do cost of delay. O que ele explora muito lá é que o que é a explicação do cost of delay é você pode estar mitigando um risco, você pode estar explorando um ganho que só vale naquela janela de tempo ou você pode estar evitando um custo. Aí tem toda a parte também de sunk costs, de o que vale é o que você está enxergando no presente em relação ao cost of delay. Se você fez uma funcionalidade toda, está apegado a ela, mas na hora que você vai fazer a engenharia de valor tem uma outra coisa que você deveria finalizar e entregar antes, ou deveria priorizar, você deveria ignorar, de fato, e desapegar do que você já fez, dependendo disso. M1: Quer falar, Régis? M3: Você quer terminar o que você ia falar? M1: Pode completar. M3: O que eu ia comentar é que existe até um modelo diferente mesmo de você enxergar o projeto e por isso que, às vezes, a gente acaba caindo nas discussões do valor que o Roadmap tem para isso ou não. É que, assim, o Roadmap, no fundo, é construído em cima de algumas hipóteses do que você acha que vai ser a melhor entrega para você resolver um problema ou para conseguir aproveitar uma oportunidade. Quando você enxerga isso como uma hipótese, a sua primeira entrega nada mais é do que a maneira como você está confirmando a sua hipótese. Então o que é esse feedback, no fundo? Esse feedback que você está recebendo dos seus clientes, essas solicitações de mudanças, solicitações de melhoria, nada mais são do que a validação da sua hipótese. Elas estão te informando se a hipótese que você tinha sobre aquele produto que você entregou eram verdadeiras ou não. A gente propõe até que não seja só o feedback dos usuários, mas que você tenha indicadores de negócio atrelados àquela entrega, inclusive, para você saber se aquela entrega confirmou ou não a sua hipótese inicial. Vamos dizer, então, que esse feedback está te dizendo que a sua hipótese inicial estava errada ou estava incompleta. É quase irracional você continuar com o Roadmap que você tinha inicialmente. M2: Irresponsável. M2: É irresponsável você continuar com o Roadmap que você tinha inicialmente. Por isso que a gente bate tanto na tecla de que existe valor no Roadmap para mostrar o que a sua intenção com a informação que você tem hoje, o que você espera que vá acontecer para questões de orçamentação, de aprovação, responsive ship, etc, mas a ferramenta deve ser usada dentro das limitações dela. Se a primeira entrega está te mostrando que a sua hipótese estava errada ou incompleta, você deve (inint) [00:31:51]. Eu sei que eu estou abstraindo das dificuldades práticas, que eu acho que é isso que o Schuster estava colocando. M1: Não sei se vocês vão concordar comigo, mas é porque eu acho curioso o seguinte. Pensa bem: para mim, tem um erro fundamental por trás de tudo, porque eu acho interessante explorar o porquê isso não acontece, porque é tão difícil. Para mim, ainda tem um erro fundamental, que é assim: quandos e faz um Roadmap desses, você poderia estar respondendo a uma pergunta que é a seguinte, quais os principais resultados que eu vou buscar nos próximos meses e isso vai virar o (inint) [00:32:23] para o meu time, que já tem orçamento dando fundos para eu cuidar desse time. Isso seria, para mim, um time ágil. Você não está usando o Roadmap para saber o preço de um sistema que você nem sabe qual é. O Roadmap é mais no sentido de “cara, olhando para esse ano nós vamos procurar isso e esse objetivo, por exemplo”. Por que eu estou falando isso? O Roadmap normalmente cumpre uma outra função, que é dar um conforto para alguém de quanto que, possivelmente, custa aquilo. Então ele começa já assim: quanto que custa isso aí? Aí todo mundo, em altíssimo nível, tenta dar isso, só que, por algum motivo misterioso da psique humana e talvez porque a empresa não fez a transição para trabalhar ágil, aquele quanto que deve custar isso ou quanto vai custar cada modo vira muito mais. Vira uma verdade. Aquilo já começa a contaminar o ágil. Por isso que a gente é tão chato com escopo e tem um episódio que se chama Maldição do Escopo, porque, o que acontece? Por trás disso tudo, por mais que seja um Roadmap, está falando que é de um banco. Se eu achava que ia gastar x mil para um modo de abertura e já gastei, e agora, se vier um feedback disso? Eu peço aprovação disso? Eu consumo dinheiro do próximo módulo ou então eu deveria ter feito aquele modo já com uma reserva para esse dinheiro? Se o objetivo tiver sido engajado, conseguir abrir tantas contas ou engajar os clientes, você deve ir gastando um dinheiro que é razoável para trazer aquele retorno de negócio e continuar gastando enquanto fosse importante. O cost of delay seria um cost of delay de não conseguir trazer esses clientes, por exemplo, que você está perdendo para o outro banco. Entende o que eu falo? Por trás disso tudo, por isso que eu acho que a transformação é tão dura, ainda existe um modelo orçamentário. O dia em que as empresas simplesmente tiverem squads e já admitirem que aquele custo é dado, eu tenho aqueles squads e aí o Roadmap existia mais para dar aquela visão inicial do ano daqueles caras e eles procurarem resultado, você já descontaminou um pouquinho, entendeu? M2: E não é só, igual você falou, o conforto da quantidade de dinheiro, do orçamento, porque você poderia ter o orçamento sem definir necessariamente o que vai ser feito e quando vai ser feito. Ainda tem um conforto aí meio de reputação. É meio feio você chegar lá e falar assim, “de fato, existe um nível de incerteza muito grande em relação ao que deve ser feito e quando deve ser feito”. É difícil um diretor, por exemplo, chegar e falar assim: “é, de fato, não sei nem se vai ter que fazer isso. Porque você poderia definir uma orçamentação, mas sem ter um racional tão detalhado ou tão cientificamente comprovado. M: O problema maior do Roadmap é essa definição do como tem que ser feito, na minha visão. Você falou assim “módulo”. Eu fiquei tentando trazer na memória aqui alguns projetos que eram orientados a Roadmap e aí, realmente, eles definem módulos. Quando você define um módulo, você está dizendo que tem que ser feito. Um Roadmap deveria ter muito mais a hipótese e que essas hipóteses sejam revistas, como o Régis disse, na medida em que você for recebendo o feedback. Se você já diz “vou fazer um módulo”, um módulo (inint) [00:35:58]. Aí você está medindo escopo, não está medindo resultado. M1: Olha só, uma empresa tem n times que não têm que ter um Roadmap para serem justificados, mas esse time que está fazendo um software tem. Por quê? No fundo, ela está focando no escopo do software e não, na verdade, acreditando que tem um time que deve existir e entregar resultado, entendeu? Eu acho essa discussão importante porque por trás dessa pergunta, você pode falar mil vezes para o cara fazer engenharia de valor, mas a conversão é lá no início do troço. M3: Volta de novo no modelo taylorista. Se você parte do princípio que dá para saber de antemão, por que você não deveria saber utilizar os recursos da sua empresa? Só executa. M1: Eu insisto nisso: a empresa é cheia de times, que não tem que se justificar a existência com Roadmap ou escopo. Você tem aquele time porque ele é importante e gera valor para o negócio. Esse é mais um time, mas hoje a visão de projetos, que você vai lá e aloca os recursos para fazer alguma coisa, você continua indo lá e pedindo um dinheiro para fazer aquilo. Aí você fala, “estou pedindo dinheiro de forma mais genérica”, mas aquilo vira uma sombra sobre tudo que vai ser feito, porque aquele dinheiro, de alguma forma, já está comprometido. Eu, realmente, acho assim: a empresa pode até não começar assim, mas com o passar do tempo aqueles times vão tendo sentido de existir, ou seja, eles vão automaticamente sendo… Inglês é bom, porque tem os funds. Eles automaticamente vão sendo orçados para todos os anos e aí eles começam a ganhar uma certa liberdade para começar a entregar resultado. Se for lá no âmago da questão, é muito isso. No fundo, é o diabo do escopo ali. M2: A maldição do escopo. M1: Que está almadiçoando. Ontem um cliente chegou aqui para conhecer e foi engraçado, porque ele deu a volta e viu o cartazinho nosso da Maldição do Escopo. Na reunião eu falei, “cara, eu vou explicar porque a gente acha isso tão importante”. Isso contamina tudo e a partir disso já começa tudo a ficar meio contaminado, porque você tem que dar satisfação em torno daquilo e a engenharia de valor acaba que vira um jogo secundário, porque você já gastou um dinheirão. É isso aí, pessoal. Terminamos o episódio de Perguntas & Respostas. Um abraço para todos. M2: Até mais, pessoal. M3: Falou, pessoal. Obrigado. M: Valeu, pessoal.
M1: Bom dia. Boa Tarde. Boa noite. Bem-vindos a mais um episódio de Os Agilistas. Estou aqui novamente com o Vinição. M2: Tudo bem, galera? M1: E o Régis. M3: E aí, pessoal, beleza? M1: A gente teve uma repercussão muito boa com o primeiro Perguntas & Respostas. Vamos fazer mais um agora. Já vou começar direto então lendo uma pergunta. Antes disso, lembrar mais uma vez, se vocês quiserem mandar comentários, mensagens, a gente tem agora um WhatsApp para isso. O telefone é (31) 99697-7104. Tem o e-mail também: osagilistas@DTIdigital.com.br. Algumas mensagens não estão identificadas, mas a gente tem uma pergunta aqui interessante. Eu vou lê-la aqui agora. A pergunta é a seguinte: “como lidar com um cliente que quer um projeto ágil, mas não consegue embarcar nisso e fica sendo aquela coisa arcaica e que deixa todo mundo doido? PO que não se envolve, ordens aleatórias que não entram no backlog, etc. Vocês poderiam falar um pouquinho sobre isso? Seria ótimo”. Então, esse cenário aí não é tão incomum. Acho que tem dois cenários, que o Régis vai comentar. Tem o cliente que nem quer o ágil e aí é mais difícil ainda, mas tem até o cliente que quer o ágil, mas não deixa a coisa acontecer. O que você teria a falar um pouquinho sobre isso, Régis? M3: Quando a gente viu essa pergunta, eu disse que esse cenário que ele descreveu nem é o inferno completo. Pelo menos ele disse aí que o cliente quer o projeto ágil. Dá para ser pior, que seria o segundo cenário aí, quando o cliente nem quer o ágil ou te contratou pela entrega do software, por exemplo, no nosso caso, e aí você tenta implantar o ágil e tem os conflitos aí com a cultura dele. É evidente que embora não seja um caso incomum, como o Schuster falou, que a gente não vai ter uma receita de bolo aqui para isso. Porque cada cliente, e a gente investe muito aqui nisso, cada cliente demanda uma resposta diferente, uma estratégia diferente, uma maneira de agir diferente, mesmo que seja a mesma entrega e o mesmo tipo de serviço. Eu acredito que uma das coisas que ajudam é a fase inicial. Embora a gente não trabalhe com a fase de planejamento completa, a gente tem alguns ritos no início que ajudam justamente a embarcar o cliente na ideia do projeto. Por exemplo, as dinâmicas que a gente chama aqui de mission command, que é onde a gente define os objetivos, os resultados chave e as dinâmicas de design sprint, que normalmente se seguem a essa, são dinâmicas que, em geral, a gente tem obtidos bons sucessos na venda da ideia para os níveis mais altos da empresa no envolvimento e no engajamento dos níveis mais altos da empresa e nessas reuniões a gente costuma aproveitar, dependendo do nível da empresa que está contratando, para explicar como é que vai ser a metodologia do projeto a partir dali, como é que funciona o ágil, depende da maturidade da organização. Isso seriam algumas dicas mais gerais que eu acho que poderiam ajudar também a conseguir esse compromisso no início. Uma outra coisa é que, assim, se o cliente quer o ágil, então você pode sempre apelar para o lado da coerência. Se ele pediu um projeto ágil e por alguma razão ele está com uma dificuldade de embarcar o PO ou de se envolver de forma própria, você sempre tem o caminho de apelar para a coerência dele. Você não quer o ágil? Então deixa eu te ajudar a fazer o ágil da forma que é e explicar isso exige de nós que estejamos prontos para explicar mais a questão dos princípios, dos valores, porque a gente entende que é melhor fazer assim do que da forma tradicional, porque também se a gente chega, simplesmente, com o discurso de que é assim que faz e pronto, eu acho que isso gera mais resistência do que qualquer outra coisa, então tem que estar muito pronto para explicar, para apelar para esse lado mais didático da coisa também. Seriam algumas dicas que eu pensei aqui. Não sei se vocês teriam outras. M1: Uma coisa que me vem muito à cabeça, eu lembro do Vinicius falando sobre alguns contextos. Um rito importantíssimo no ágil é análise crítica, que, na verdade, é uma reflexão para ser uma equipe, um time aprender a aprender. Então é uma coisa que eu tenho visto nos últimos anos, principalmente que o ágil está ficando mainstream, ou seja, é igual o que você comentou, o cara quer realmente e precisa fazer aquilo, é ter análises críticas que envolvam o próprio cliente e que mostrem a verdade não em um tom acusatório, em uma vontade de aprender. Por exemplo, uma das piores coisas que pode ser para uma frente ágil, que quer gerar valor, é PO que não se envolve ou, então, atendimento a agendas pessoas ao invés de tentar priorizar baseado em negócio. Idealmente, isso tem que emergir uma análise crítica, e é bom, inclusive, ter análises críticas no âmbito do projeto e no âmbito do (inint) [00:04:58] do patrocinador do projeto, mostrando que dá para o caminho ser diferente. É claro, para tudo que se fala tem chance de alguém falar que não vai adiantar, não é? É claro que se no limite, obviamente, a organização não quiser, a liderança não mudar e começar a conduzir tudo da forma convencional, não vai mudar, mas partindo do princípio que você colocou de que no fundo o cara quer, mas é quase uma questão de entendimento, de ele não estar entendendo certas coisas, de estar com certos receios, acho que isso é muito importante. E tem outras iniciativas de educação também. Tem muitos clientes nossos que têm usado o podcast como um dos canais para tentar chegar em outras pessoas e dar exemplos. Você tem mais algo a acrescentar, Vinição? M2: Eu vejo que a gente tem observado algumas situações na DTI e ao longo dos anos a gente foi vendo uma necessidade da nossa oferta ser mais completa, até para endereçar esses pontos aí. É claro que você não tem que necessariamente contratar a DTI, mas você usar um (de para) do que a gente faz. Então a gente viu a necessidade de ter uma oferta para treinamentos, que é o DTI. Você buscar coisas do tipo no DTI, aonde você estiver, aí na sua cidade, na sua empresa, buscar ofertas que ajudam a treinar os membros dos times que são do seu cliente, por exemplo. Uma outra estratégia que tem muito a ver com priming, que o Schuster falou que tem um certo nível de influência presencial em um esquema quase de game (inint) [00:06:30], que a pessoa está presente, que aqui a gente tem uma oferta que é o garden, que a gente chama, que o cliente fica junto com a gente e a gente influencia o cliente. Então o jeito de você fazer isso é ficar fisicamente em algum lugar, sei lá, em um coworking, alguma coisa assim, que já pratique o agilismo e de repente você consiga convencer o seu cliente mais pelo exemplo, mostrando o que está acontecendo no dia a dia. Nós temos ainda outra oferta que é uma espécie de consultoria, que não é uma consultoria tradicional, que é uma consultoria quase de mentoria, onde você vai ajudar o cliente, mas ele vai executar boa parte do trabalho, que a gente chama de (inint) [00:07:07] e que tem outras empresas que fazem também e a gente tem a nossa oferta aqui. A gente tem uma oferta não só da execução, mas também uma oferta mais completa, que a gente chama de universo DTI aqui, que tende a endereçar todos esses aspectos que você colocou aí. M1: No fundo, a gente sempre remete para dar o primeiro passo, no sentido de que você tem que tentar destravar um ciclo virtuoso, criar um ciclo virtuoso. Aí você vai atacar em todas as frentes. Você vai atacar nessa parte de educação e vai, principalmente, na minha visão, tentar gerar ação dentro da organização a partir dessas análises críticas, que é inclusive uma das coisas que o (inint) [00:07:42] tenta gerar, que é o que a gente chama de looping desses times que conseguem empreender. O mais importante é isso. Se você está entregando com cadência, não tem tanto problema um PO agir mal durante duas semanas, por exemplo, desde que você identifique e corrija isso rápido. O time que aprende a corrigir as coisas rápido talvez consiga reverter um processo desse, mas sem comprometimento da alta liderança vai ficar muito difícil. É isso. M: Oi, Denise. Oi, Schuster. Bom dia. Boa tarde. Boa noite. Meu nome é Rodrigo Perestelo, sou coordenador de uma instituição financeira. Ando ouvindo bastante o podcast de vocês, quero dar os parabéns, vem abrindo bastante a minha mente, o meu conceito sobre agilidade. Tenho certificação de Scrum Master. Venho estudando bastante o tema, mas eu queria ver com vocês como que a gente usa esses conceitos de agilidade com a sustentação dos sistemas. Após um produto ser lançado, uma feature ser lançada, como que é essa passagem do time que faz a sustentação dessas peças, como é a integração entre esses dois times, como o DTI costuma trabalhar assim com alguns clientes. Agradeço desde já. Um forte abraço e, mais uma vez, parabéns. M1: Oi, Felipão. Tudo bom? M: E aí, pessoal, beleza? M2: Felipão estava ficando deprimido ali, porque não estava participando dos episódios. M1: Ele passou várias vezes na porta aqui do estúdio, querendo entrar. M3: Cara chorosa… Aí eu deixei. M2: Fala aí, Felipão. Estava na trincheira. M: Exatamente. Enquanto vocês estão aqui falando para o podcast, eu estava executando o que a gente fala. M1: É bom ter alguém aqui que executa. Felipão, o que você diria sobre? Essa questão de sustentação é engraçada, porque, no fundo, esses assuntos convergem quando a gente fala de squads e de diferentes digitais. Fala um pouquinho sobre isso aí, Felipão. M: A experiência que eu já tive no assunto, eu dividiria em dois aspectos. A pergunta fala sobre como fazer a passagem de bastão de uma feature que acaba de ser entregue para o time que faz sustentação. Eu já acho que não deve haver essa passagem de bastão, porque se a gente está falando de um produto, nessa primeira visão, o squad tem que ser responsável por novos features e por sustentar a aplicação. Uma coisa que a gente já falou até no episódio anterior, que um backlog de um produto tem que ser composto por feature, sim, mas também por bugs, (inint) [00:10:20] técnicos. Então a sustentação é feita pelo próprio time. O bug passa a ser uma história comum do time daquele produto, porque ninguém melhor de estar contextualizado no assunto, ter o conhecimento de causa para sustentar o produto do que o próprio time do produto. Agora, quando a gente está falando já de aplicações que já são legados, já estão em operação e não existe um squad atuando de forma contínua… M1: Só um comentário. Então eventuais aplicações você talvez aposente, porque não justifica ter um squad. M: Não justifica ter um squad cuidando. Aí, sim, a gente vai para um ambiente de sustentação descentralizada. Aí a experiência que eu já tive em um ambiente de sustentação descentralizado, fazendo aí o paralelo com o agilismo, o que melhor funcionou é a gente colocar o time em operação de Linkan Bain, o método mais próximo de Likan Bain, em que você consiga tentar limitar alguns working progress, que a gente sabe que na sustentação é, às vezes, inevitável, mas tentar levar o bug, o chamado, até o fim. Por que eu estou falando isso? Porque no início dessa experiência que eu tive com sustentação centralizada a gente elevou muito o número do nosso work in progress, e aí você acaba se perdendo no contexto de um problema que você começou a organizar, às vezes, uma semana atrás, e a gente convergiu bastante quando entramos em modo Linkan Bain, em que a gente tinha o máximo de work in progress, três por desenvolvedor, três chamados. A gente entrava em um ciclo ali de, às vezes, está parado na validação do usuário. A gente ficava enchendo o saco do usuário até conseguir, realmente, ir até o fim. M1: Ficar cada um passando o bastão com uma meta local, assim. M: Exatamente. M1: Fechar o chamado da perspectiva dele, não é? M: O que, no fim, acaba acontecendo. M1: Para resolver o problema. M: Exato. Se a gente não tiver essa orientação forte em resolver o problema, a gente começa a aumentar muito o work in progress, aumentar muito a fila e começa a fazer fechamento de chamado à força. O problema não foi resolvido. Eu vejo mais por esse lado, sabe? M1: Só um comentário. Esse primeiro cenário que o Felipão disse, para um squad poder, de fato, assumir a sustentação da frente pela qual ele é responsável, você tem que estar com o conceito do agilismo na veia mesmo. Por quê? Primeiro, esse squad vai ter que ter um espaço para isso no backlog. Alguém que cobra constantemente, alguém que quer uma previsibilidade total e que não aceita, a gente já falou várias vezes… M2: O Burndown não pode ter nenhuma variação em função de um novo problema, não é? M1: O Burndown não pode ter variação e se aquele time entregou menos… Pensa bem, o time tem que fazer o que é mais importante. Se em dado momento é mais importante uma pequena melhoria ou corrigir um bug crítico importante, aí o time vai fazer aquilo. Então isso exige uma maturidade, vamos dizer assim, de gestão, para entender as variações e, na minha visão também, para isso acontecer de verdade você tem que estar com uma série de ferramentas de DevOps em ação para o time, realmente. Porque, assim, se é um fardo muito grande para aquele time cuidar, toda hora, vamos supor, para acessar um ambiente é difícil, para fazer aquilo é difícil, para colocar um deploy é difícil, aquilo atrapalha tanto o time que você fala assim, “deixa isso para alguém fazer e mesmo eles tendo mais eficiência”. Você concorda? M: Se o time está com esse tipo de problema de autonomia, de DevOp, de implantação, ele tem um problema até anterior à sustentação, porque provavelmente eles vão estar com esse mesmo problema para poder evoluir. M1: Eu comento isso porque, às vezes, a causa raiz é essa. O cara separa porque ele fala assim, “o cara é muito ineficiente para ficar dentro do time”, mas a solução, às vezes, não é separar, é ir na causa raiz dessas ineficiências. M: Eu não sei qual é o formato da sustentação no caso do Rodrigo, mas um conselho que eu daria para ele é tentar identificar, se for uma sustentação centralizada, o que é produto ali e começar a transferir a responsabilidade desses chamados de produto para os times de produto, de fato. M1: É engraçado. O conselho para um modo tradicional é ficar o mais lean possível. M: Exatamente. M1: E para a frente de produto é trazer para dentro do contexto da frente de produto. M: É claro que, assim, em equipes de sustentação centralizada existem métodos como (inint) [00:14:34] que ajudam também a fazer a gestão, mas eu acho que o principal ponto aí, realmente, é tentar identificar se tem produto ali no meio e tentar se tornar o mais lean possível quando a gente está falando de centralizada, e quando a gente está falando de produto, é colocar para o produto cuidar. M2: Eu podia fazer só uns comentários, assim. Na minha visão, a melhor estrutura mesmo, bem saindo do muro mesmo, é estar dentro do squad. A sustentação está dentro do squad por um fator crucial, que aumenta a responsabilidade intrínseca do time. O time passa a ficar muito mais responsável pelo o que ele gera, aí essas questões de evolução de DevOps, que a gente comentou aqui, nascem até porque se a pessoa que faz é a pessoa responsável por em um final de semana atender os chamados, ele vai querer muito automatizar as coisas, aumentar e melhorar a qualidade do que está entregando, mas há divergências. Se você tem uma variabilidade muito grande em algum produto, o que eu quero dizer com isso? Vamos supor: tem um produto que, de vez em quando, não tem chamado nenhum. Vários dias sem chamados, mas, de vez em quando, tem uma rajada de chamados ou pequenas demandas. Como lidar com isso? Você vai montar um squad só para isso? É meio complicado, não é? Outro aspecto é o seguinte: quando está dentro do squad, normalmente é um rodízio. Não tem uma pessoa só, que a pessoa da sustentação, porque ia ser muito frágil. As pessoas vão girando aí, mas, por exemplo, o Google tem um papel que eles chamam lá de SRE, que é Site Reliability Engineering. Às vezes, tem times que são só desse papel. O que eles fazem é que eles selecionam as pessoas que têm um perfil adequado para isso, porque normalmente é um papel muito estressante. É o cara que gosta muito da emoção. Eles fazem uma seleção, já li alguns artigos, própria para isso. A pessoa tem aquele perfil ali, não liga de ser acionada fora de hora. O cara até gosta. O que eu estava voltando, falando sobre a questão da variabilidade, o que você pode fazer, nesse modelo do Google é um modelo mais centralizado, igual o Felipão estava falando. Talvez, você pode acumular produtos que tem grande variabilidade e normalmente quando você junta muita variabilidade, a variabilidade total diminui. É uma saída. Tem um livro que se chama Building Microservices, do Sam Newman, que tem um capítulo em que fala especificamente sobre isso, sobre estruturas de times para você conviver com modelos de produtos que têm muita variabilidade. Aí ele tem algumas estratégias, não vou lembrar de cabeça. Foi interessante que teve uma (inint) [00:17:21] hoje eu citei isso. Eu lembrei aqui agora e é uma fonte bacana de conhecimento sobre isso. Ele fala várias estratégias. Por exemplo, tem um modelo de open source interno, aonde tem alguns caras que são os caras que fazem as revisões, os code reviews, mas as pessoas que estão mudando o sistema, às vezes, estão em outras squads, mas precisa de ter o code review, ter o carimbo de entender daquela solução. Então eu comendo ele ler esse livro aí. Eu não lembro exatamente o capítulo, mas é um capítulo que fala de estrutura de times para situações de variabilidade alta. M1: Pessoal, mais uma mensagem anônima. “Bom dia, agilistas. Primeiramente, gostaria de parabenizá-los pelo podcast e pelo excelente trabalho que postam constantemente. Também vim para agradecer o conteúdo e temas de extrema relevância nos podcasts. Por através destes pude aprimorar os meus estudos durante o meu tempo de locomoção. Não só de vídeo aulas um estudante vive. Por fim, venho a vocês com duas perguntas. Estou em busca de uma boa leitura sobre metodologia ágil. Qual leitura vocês indicariam? E qual o nome do livro que o Marcelo menciona no (inint) [00:18:34] dezesseis: atenção ao feedback? Desculpe, tenho um nome, sim. Me chamo Pedro Faraj”. Só respondendo aqui, o livro que eu indiquei aquele dia se chama Nine Lies About Work. Eu não sei se já existe uma versão em português. O autor se chama Marcus Buckingham e Ashley Goodall. Régis, qual livro você indicaria? Dentre vários, qual te vem à mente? M3: Eu vou indicar o último que eu li. Não sei se tem em português. Me indicaram em inglês, então eu nem procurei. Chama: A Seat at the Table. O autor se chama Mark Schwartz. Aí tem o subtítulo. É: IT Leadership in the Age of Agility. Por que eu gostei desse livro e eu recomendo ele? Ele é um livro que trata muito sobre a relação negócios e TI. É uma das coisas de que a gente, inclusive, fala bastante aqui quando a gente está falando sobre business agility, sobre essa relação abusiva entre negócios e TI. Eles chamam esse A Seat at the Table, esse assento à mesa, justamente tratando como que o CIO dentro das empresas, muitas vezes, é tratado de forma diferente de outros diretores, diretores de outras áreas e, muitas vezes, ele tem que se provar além até do que seria saudável. Nessa discussão entre negócios e TI, ele trata muitos desses conceitos que a gente aborda no podcast sobre como que deve ser uma TI verdadeiramente ágil, como que isso, inclusive, ajuda a destravar o potencial da organização no uso da tecnologia. Um livro excelente. Eu recomendo muito. M1: E você, Vinição? M2: Um livro que eu gosto bastante, estou precisando até dar uma relida nele, porque é muito bom livro, o Schuster sempre fala isso, livros muito bons têm que ser relidos várias vezes. M1: Os (inint) [00:20:18] falam para fazer isso, mas eu faço o contrário. Eu fico tentando ler 400, mas os (inint) [00:20:22] falam que você deveria dominar um bom livro. M2: Eu gosto de reler alguns livros bons. Esse livro, eu acho muito bom. Acho que é uma das melhores coisas que eu já li, que se chama The Principals of Product Development Flow. É um livro do Donald G. Reinertsen. Esse livro eu acho bem interessante, porque ele meio é meio de (inint) [00:20:43] e meio de linha, uma mistura dos dois. M1: Mas ele é complicadão, hein? M2: Esse livro tem um embasamento matemático e estatístico muito forte com a teoria de filas. Ele é bem legal, mesmo, e ele tem algumas questões de estrutura. Ele fala sobre descentralização. M1: Ele é citado em vários lugares. Os caras citam esse autor, porque o livro é bem profundo. Ele não é uma leitura, digamos, introdutória. Por um lado, tem todos os princípios ali que o cara coloca, mas só para quem vai ler, é uma leitura que não é tão fácil. Ela não é tão narrativa igual um livro de negócios tradicional. Por exemplo, o A Seat at the Table é um livro mais palatável. M2: São cerca de 170 princípios que ele vai dividindo em torno de temas. Por exemplo, teoria de filas. Aí tem um capítulo, por exemplo, que é só sobre centralização versus descentralização. Ele faz várias analogias com a parte de redes, que tem um ambiente bem caótico, bem descentralizado. Ele faz algumas analogias com o exército, a guerra, que são ambientes onde é difícil você manter um plano prescritivo, então faz analogias com isso. É bem legal, mesmo. M1: Beleza. Já que vocês citaram dois livros, eu vou citar um livro aqui. A gente já falou muito dele em outros episódios. Não é de agilismo diretamente, mas como a gente sem fala que uma das coisas mais importantes é mudar a liderança e que isso, talvez, habilitasse o resto todo, é um livro que já foi citado, que é o The Meaning Revolution, do Fredy Kofman. A gente já fez podcast sobre isso, sobre o líder trasncendental. Eu acho ele muito interessante por causa disso. Uma das maiores dificuldades é o líder entender o seu novo papel e, talvez, quando alguém pergunta como é que começa uma transformação, a verdade é que se a liderança começasse a entender melhor qual o seu papel, ela, talvez, já começasse a criar o espaço para a mudança. É uma leitura que eu recomendo demais. E aí, Felipão? Qual leitura você recomendaria para o nosso ouvinte? M: Eu vou recomendar um livro especificamente, não, mas do último conjunto de leituras que eu fiz, que eu achei muito bom. É de um site encabeçado pelo Alistair Cockburn, que é um dos signatários do manifesto ágil, inspirado por uma palestra dele no último Agile Brazil, que é heartofagile.org. Lá tem um conjunto bem interessante de artigos, de vídeos. Recomendo um artigo principal, que é onde ele descreve, e um vídeo em que ele descreve, sobre esse conceito que ele está retrazendo, está resgatando. M1: Está resgatando a essência do ágil. M: Exatamente. Até na palestra ele comenta que ele acredita que os métodos ágeis foram um pouco desvirtuados desde 2001, quando eles assinaram o manifesto e se tornaram muito comerciais, muito prescritivos, quando, na verdade, a gente tem que se apegar com algo que está bem anterior a isso, que é o que ele chamou de heart of agile, que é o Colaborate, Deliver, Spect – se não me engano – e o Improve. Você colabora para entregar e você inspeciona para melhorar. Se você internalizar bem essa filosofia, não importa nem muito qual o método que você está utilizando, você vai conseguir se transformar e ter uma mentalidade mais ágil. Recomendo acessar lá o heartofagile.org. M1: Lembrando que o Alistair Cockburn fez um Enzimas para a gente. M: Exatamente. M1: Onde ele fala justamente sobre esses princípios, Colaborate, Deliver, Reflect e Improve. M: É Reflect. Colabora para entregar e reflita para melhorar. M3: Eu acho que é heartofagile.com. M: Correção aqui ao vivo pelo Régis. Heartofagile.com. M: Bom dia. Boa tarde. Boa noite. Meu nome é Roberto. Sou coordenador da equipe de automação e BI do Itaú Unibanco. Eu ouço o podcast desde o começo, já ouvi todos os episódios e toda quinta-feira busco avidamente o episódio mais atual, o novo conteúdo que vocês lançam. Também gosto bastante do conteúdo do Enzimas. Queria deixar o parabéns para toda a equipe dos agilistas pela forma que vocês compartilham esse conteúdo. Eu acredito que seja o primeiro podcast em língua portuguesa de agilismo. O fato de vocês não serem focados em uma metodologia, focados em uma maneira de trabalhar e também não serem prescritivos faz muita diferença. Faz com que com que quem ouve o podcast tenha que fazer as suas próprias reflexões, suas próprias análises e tomar uma decisão, de que maneira aquela pessoa quer trabalhar, de que maneira a pessoa quer conduzir ali o seu trabalho, o seu desenvolvimento. Uma dúvida que eu tenho é como que vocês lidam com a questão de um backlog priorizado, um backlog com entregas de valor já definidas, eventualmente, um code map. E em um projeto ágil, quando você já fez o lançamento de alguma funcionalidade, já tem uma versão no ar, você já começou a receber uma série de feedbacks, queria saber como que vocês lidam com o tratamento desses feedbacks dessa versão que está atualmente no ar versus o Roadmap do produto ali, as novas funcionalidades, os novos recursos que provavelmente já tem ali uma expectativa de um retorno de valor, versus os feedbacks dos usuários ali, que podem estar reportando problemas, funcionalidades que podem ser melhoradas, novas funcionalidades e como que vocês administram isso. Obrigado, pessoal. Valeu. M1: Roberto, muito obrigado pela pergunta. Vamos explorar esse tema. Acho que é um tema bem importante e ele está muito atrelado com essa cultura tradicional das empresas, que, no fundo, nunca entendem que o Roadmap poderia, na verdade, ser a mesma referência inicial que você iria perseguir e iria se adaptando àquilo. Mas para ir mais direto ao ponto, eu queria primeiro que o Felipão explorasse esse assunto. Felipão, isso, no final das contas, não é uma mera questão de praticar continuamente engenharia de valor? M: É exatamente isso. Acho que você praticamente já deu a resposta mais simples possível para essa pergunta. Eu acho que você está certo, sim. Eu acho que a criação ou a necessidade de um Roadmap surge muito. Eu acho que a gente pode discutir mais o assunto, mas com a necessidade de uma orçamentação, de garantir (inint) [00:27:23] ship com a alta liderança, mas quando, na verdade, eu acho que o time tem que enxergar um Roadmap do que um guia inicial do que vai ser tratado com maior valor ou quais são as maiores hipóteses. Ele fala sobre como a gente trata isso em relação aos feedbacks do mercado. Eu acho que o feedback do mercado é muito maior do que o Roadmap, afinal, um dos princípios ágeis é adaptar a mudança ao invés de seguir um plano. Igual você disse, é uma engenharia de valor constante. O feedback tem que gerar reflexão e esse Roadmap pode e deve ser revisto constantemente. M1: A gente respondeu há pouco uma pergunta sobre os livros e o Vinição citou o livro do Principals of Product Development Flow, alguma coisa assim… M2: Donald G. Reinertsen. M1: É interessante, porque ele começa o livro, ou estou enganado, o Vinição deve lembra, meio que falando assim: “cara, você tem que partir do modelo econômico correto”. E o modelo econômico que ele começa, partindo, é um modelo de ser costumer centric, que é um modelo de ser chamado pelo cliente, e nesse modelo, pensando em lean, o que mais importa é o quê? É o cost of delay. Ainda que isso não seja tão simples na prática, ninguém está falando que isso é simples na prática, é como se você sempre tomasse as decisões, principalmente em um mundo mais dinâmico, baseado no custo que o atraso daquela funcionalidade pode trazer para você. Você deixa de fazer um experimento, deixa de colocar uma funcionalidade, e o custo desse atraso pode ser muito alto, mas aí eu penso assim, essa é a resposta direto. Mas o que é interessante para poder tentar contribuir bastante com a pergunta? M2: Só complementando o que você falou. Eu acho que um jeito de praticar a engenharia de valor é, de fato, através desse modelo do Donald, que ele coloca no livro, do cost of delay. O que ele explora muito lá é que o que é a explicação do cost of delay é você pode estar mitigando um risco, você pode estar explorando um ganho que só vale naquela janela de tempo ou você pode estar evitando um custo. Aí tem toda a parte também de sunk costs, de o que vale é o que você está enxergando no presente em relação ao cost of delay. Se você fez uma funcionalidade toda, está apegado a ela, mas na hora que você vai fazer a engenharia de valor tem uma outra coisa que você deveria finalizar e entregar antes, ou deveria priorizar, você deveria ignorar, de fato, e desapegar do que você já fez, dependendo disso. M1: Quer falar, Régis? M3: Você quer terminar o que você ia falar? M1: Pode completar. M3: O que eu ia comentar é que existe até um modelo diferente mesmo de você enxergar o projeto e por isso que, às vezes, a gente acaba caindo nas discussões do valor que o Roadmap tem para isso ou não. É que, assim, o Roadmap, no fundo, é construído em cima de algumas hipóteses do que você acha que vai ser a melhor entrega para você resolver um problema ou para conseguir aproveitar uma oportunidade. Quando você enxerga isso como uma hipótese, a sua primeira entrega nada mais é do que a maneira como você está confirmando a sua hipótese. Então o que é esse feedback, no fundo? Esse feedback que você está recebendo dos seus clientes, essas solicitações de mudanças, solicitações de melhoria, nada mais são do que a validação da sua hipótese. Elas estão te informando se a hipótese que você tinha sobre aquele produto que você entregou eram verdadeiras ou não. A gente propõe até que não seja só o feedback dos usuários, mas que você tenha indicadores de negócio atrelados àquela entrega, inclusive, para você saber se aquela entrega confirmou ou não a sua hipótese inicial. Vamos dizer, então, que esse feedback está te dizendo que a sua hipótese inicial estava errada ou estava incompleta. É quase irracional você continuar com o Roadmap que você tinha inicialmente. M2: Irresponsável. M2: É irresponsável você continuar com o Roadmap que você tinha inicialmente. Por isso que a gente bate tanto na tecla de que existe valor no Roadmap para mostrar o que a sua intenção com a informação que você tem hoje, o que você espera que vá acontecer para questões de orçamentação, de aprovação, responsive ship, etc, mas a ferramenta deve ser usada dentro das limitações dela. Se a primeira entrega está te mostrando que a sua hipótese estava errada ou incompleta, você deve (inint) [00:31:51]. Eu sei que eu estou abstraindo das dificuldades práticas, que eu acho que é isso que o Schuster estava colocando. M1: Não sei se vocês vão concordar comigo, mas é porque eu acho curioso o seguinte. Pensa bem: para mim, tem um erro fundamental por trás de tudo, porque eu acho interessante explorar o porquê isso não acontece, porque é tão difícil. Para mim, ainda tem um erro fundamental, que é assim: quandos e faz um Roadmap desses, você poderia estar respondendo a uma pergunta que é a seguinte, quais os principais resultados que eu vou buscar nos próximos meses e isso vai virar o (inint) [00:32:23] para o meu time, que já tem orçamento dando fundos para eu cuidar desse time. Isso seria, para mim, um time ágil. Você não está usando o Roadmap para saber o preço de um sistema que você nem sabe qual é. O Roadmap é mais no sentido de “cara, olhando para esse ano nós vamos procurar isso e esse objetivo, por exemplo”. Por que eu estou falando isso? O Roadmap normalmente cumpre uma outra função, que é dar um conforto para alguém de quanto que, possivelmente, custa aquilo. Então ele começa já assim: quanto que custa isso aí? Aí todo mundo, em altíssimo nível, tenta dar isso, só que, por algum motivo misterioso da psique humana e talvez porque a empresa não fez a transição para trabalhar ágil, aquele quanto que deve custar isso ou quanto vai custar cada modo vira muito mais. Vira uma verdade. Aquilo já começa a contaminar o ágil. Por isso que a gente é tão chato com escopo e tem um episódio que se chama Maldição do Escopo, porque, o que acontece? Por trás disso tudo, por mais que seja um Roadmap, está falando que é de um banco. Se eu achava que ia gastar x mil para um modo de abertura e já gastei, e agora, se vier um feedback disso? Eu peço aprovação disso? Eu consumo dinheiro do próximo módulo ou então eu deveria ter feito aquele modo já com uma reserva para esse dinheiro? Se o objetivo tiver sido engajado, conseguir abrir tantas contas ou engajar os clientes, você deve ir gastando um dinheiro que é razoável para trazer aquele retorno de negócio e continuar gastando enquanto fosse importante. O cost of delay seria um cost of delay de não conseguir trazer esses clientes, por exemplo, que você está perdendo para o outro banco. Entende o que eu falo? Por trás disso tudo, por isso que eu acho que a transformação é tão dura, ainda existe um modelo orçamentário. O dia em que as empresas simplesmente tiverem squads e já admitirem que aquele custo é dado, eu tenho aqueles squads e aí o Roadmap existia mais para dar aquela visão inicial do ano daqueles caras e eles procurarem resultado, você já descontaminou um pouquinho, entendeu? M2: E não é só, igual você falou, o conforto da quantidade de dinheiro, do orçamento, porque você poderia ter o orçamento sem definir necessariamente o que vai ser feito e quando vai ser feito. Ainda tem um conforto aí meio de reputação. É meio feio você chegar lá e falar assim, “de fato, existe um nível de incerteza muito grande em relação ao que deve ser feito e quando deve ser feito”. É difícil um diretor, por exemplo, chegar e falar assim: “é, de fato, não sei nem se vai ter que fazer isso. Porque você poderia definir uma orçamentação, mas sem ter um racional tão detalhado ou tão cientificamente comprovado. M: O problema maior do Roadmap é essa definição do como tem que ser feito, na minha visão. Você falou assim “módulo”. Eu fiquei tentando trazer na memória aqui alguns projetos que eram orientados a Roadmap e aí, realmente, eles definem módulos. Quando você define um módulo, você está dizendo que tem que ser feito. Um Roadmap deveria ter muito mais a hipótese e que essas hipóteses sejam revistas, como o Régis disse, na medida em que você for recebendo o feedback. Se você já diz “vou fazer um módulo”, um módulo (inint) [00:35:58]. Aí você está medindo escopo, não está medindo resultado. M1: Olha só, uma empresa tem n times que não têm que ter um Roadmap para serem justificados, mas esse time que está fazendo um software tem. Por quê? No fundo, ela está focando no escopo do software e não, na verdade, acreditando que tem um time que deve existir e entregar resultado, entendeu? Eu acho essa discussão importante porque por trás dessa pergunta, você pode falar mil vezes para o cara fazer engenharia de valor, mas a conversão é lá no início do troço. M3: Volta de novo no modelo taylorista. Se você parte do princípio que dá para saber de antemão, por que você não deveria saber utilizar os recursos da sua empresa? Só executa. M1: Eu insisto nisso: a empresa é cheia de times, que não tem que se justificar a existência com Roadmap ou escopo. Você tem aquele time porque ele é importante e gera valor para o negócio. Esse é mais um time, mas hoje a visão de projetos, que você vai lá e aloca os recursos para fazer alguma coisa, você continua indo lá e pedindo um dinheiro para fazer aquilo. Aí você fala, “estou pedindo dinheiro de forma mais genérica”, mas aquilo vira uma sombra sobre tudo que vai ser feito, porque aquele dinheiro, de alguma forma, já está comprometido. Eu, realmente, acho assim: a empresa pode até não começar assim, mas com o passar do tempo aqueles times vão tendo sentido de existir, ou seja, eles vão automaticamente sendo… Inglês é bom, porque tem os funds. Eles automaticamente vão sendo orçados para todos os anos e aí eles começam a ganhar uma certa liberdade para começar a entregar resultado. Se for lá no âmago da questão, é muito isso. No fundo, é o diabo do escopo ali. M2: A maldição do escopo. M1: Que está almadiçoando. Ontem um cliente chegou aqui para conhecer e foi engraçado, porque ele deu a volta e viu o cartazinho nosso da Maldição do Escopo. Na reunião eu falei, “cara, eu vou explicar porque a gente acha isso tão importante”. Isso contamina tudo e a partir disso já começa tudo a ficar meio contaminado, porque você tem que dar satisfação em torno daquilo e a engenharia de valor acaba que vira um jogo secundário, porque você já gastou um dinheirão. É isso aí, pessoal. Terminamos o episódio de Perguntas & Respostas. Um abraço para todos. M2: Até mais, pessoal. M3: Falou, pessoal. Obrigado. M: Valeu, pessoal.