> Ouça este episódio

Eu sou o Paulo Caroli e este é o Podcast Mínimo Viável, onde compartilho conhecimento sobre as novas relações de trabalho e, assim, contribuo para a transformação de um mundo melhor.

Esse tal de ágil não funciona. Não é só uma pessoa que me procura com essa… não é nem com essa dúvida né, mas com esse relato e quando você vai ouvir faz muito sentido. O contexto que as pessoas estão, realmente, o ágil não tem funcionado.

Meu agradecimento aqui por ter recebido esse relato e vou compartilhar com vocês um bate-papo muito aberto sobre um relato que eu recebi: esse tal de ágil não funciona. Aproveite!

1) Neste episódio, então, você vai conferir alguns aspectos do relato recebido e as considerações e dicas do autor Paulo Caroli sobre os temas.

Modelo ágil funcionando, Scrum, teatro: O profissional conta que trabalhou em diversas empresas que diziam “respirar o ágil”, mas lamenta nunca ter visto o modelo ágil funcionar na prática. Para ele, o que vivenciou foi um grande teatro, só um script de Scrum, pois nem todo mundo estava inserido ou comprometido com o contexto ágil.

Certificado, modelo ágil… é interessante o teu relato que parece um teatro e, provavelmente, é um teatro mesmo, tá? Eu não sei exatamente a situação que tu passou, mas se está só implantando a melhoria processual, está faltando muita coisa. Eu sei, porque eu vivi isso também. Você passa em algumas empresas.

Já que você nomeou o Scrum, que é um excelente framework ágil, beleza, só que ele busca a melhoria processual. A galera começa a seguir as práticas de Scrum, vamos fazer cerimônias, só que aí começa a faltar algumas coisas. Mesmo o Scrum, se for Scrum sozinho, tem que buscar qual é a meta da Sprint e tem que entender qual é a meta e o time junto vai trabalhar para alcançar aquela meta.

Aí tu já botou no papel, mas tu viu funcionando quando alguém pegava fazia, ou seja, tem um time não comprometido com a meta. O Scrum ele joga isso também para o papel do PO, essa pessoa ela é responsável pelo direcionamento de negócio, então, ela tem que estar junto do time para ajudar o time e trazer a importância do time cumprir a meta.

Outra coisa que vai também é a reunião de Retrospectiva. Tudo bem, está lá no meio do teatro, o pessoal fez o Scrum, a meta não está clara, a pessoa PO não está trabalhando bem… cara, na primeira Retrospectiva, que é uma reunião do time para o time, o time tem que trazer a informação e falar para o pessoal o que que é isso?

Metade das tarefas das histórias passaram para a Sprint seguinte, a meta não está clara, a PO não está aqui com a gente… Então, precisa ter pelo menos uma Retrospectiva forte. E depois da Retrospectiva isso vai para o colo da pessoa que é Scrum Master. Porque se você está seguindo Scrum, a pessoa Scrum Master é a pessoa experiente com o framework e, logo na primeira, vai trazer oh, pessoal, não tá funcionando, a gente tem que melhorar, o que a gente faz?

Nesse início de conversa, independente de ser só Scrum, ele não está sendo aplicado, você está só repetindo. É que nem você falou: você estava fazendo teatro, só repetindo as cerimônias e empurrando as coisas para a frente e aí, nesse caso, realmente, eu também não gosto de ágil para isso não, eu prefiro uma coisa bem tradicional que fala está aqui a data, está aqui o que tem entregar e vamos embora, vamos entregar?

Ou seja, esse papo do compromisso, do comprometimento do time, eu acho que é independente de ser ágil ou não. O que o ágil tem de bom é ter o framework, você tem a Retrospectiva, o Kanban e você vai tentar buscar esse comprometimento do time, mas independente de ser ágil ou não ágil, a gente tem que buscar isso.

Um outro lado, que foi o que eu vivi em métodos ágeis, que é uma busca da eficiência sem eficácia. Daí que vem muito da minha pegada com Lean Inception. Cara, não interessa qual ágil que a gente vai usar, se é Scrum, se é Kanban, qual teatro que o time fazer, mas antes de fazer esse teatro, vamos alinhar e vamos entender o que a gente está construindo.

Depois, a gente até vai ter a meta da Sprint, da semana, das duas semanas, mas, antes de tudo, vamos entender o que é isso que a gente está fazendo? Quem é o time? Cadê o comprometimento com o time? Em quais datas? O que vai ser feito? O que é o MVP? Qual é a hipótese que estava lidando?

Começa com esse papo muito forte, tá, por isso que eu gosto tanto da Lean Inception, pois, independente do que vai vir depois, já começa alinhado, porque começando alinhado já é difícil, sem começar alinhado é mais difícil ainda.

E aí a gente cai para um ágil mais moderno, que aí é essas coisas de Lean Inception, Lean Start Up, até business agility, isso começa e são os anos mais recentes. Então, talvez, você tenha passado em organização que está naquele ágil lá 1.0, só pelo ágil 1.0. Mas, o mundo já mudou, a gente precisa que a busca pela eficácia seja muito forte.

2) Comprometimento do time: O profissional relatou, ainda, que as demandas só eram entregues nas datas e só davam certo, porque alguém do time deixava o almoço de lado, ou fazia hora extra, ou faltava em uma Daily Scrum, ou em uma Planning, e as demais tarefas sempre iam estourando para as próximas Sprints.

A palavra-chave nesse exemplo que você tá dando, para mim, é comprometimento. Está faltando comprometimento e o que precisa ser feito? Não vai ser o ágil, não vai ser só o Scrum, só o Kanban, aliás, nenhuma coisa isolada vai trazer o comprometimento.

Em relação ao ferramental útil, que está comum agora, um exemplo é o OKR, qual é o objetivo e o resultado-chave? Independente da Sprint, independente das duas semanas, pode ser um pouco um pouco maior, um pouco mais abrangente, mas qual é o objetivo e qual o resultado-chave? E vamos olhar para isso, esse é o norte do time todo, o que vamos seguir.

Cuidado para não fazer um objetivo de 1 ano, também não vai fazer o de 2 semanas que não está funcionando, mas tenta achar um objetivo, mês a mês, trimestre a trimestre, mas tem que ter qual o objetivo e resultado-chave. Não descrevendo no resultado-chave exatamente a tarefa, o que o time vai ter que fazer para alcançar, mas tem que ter bem claro esse é o objetivo e esse o resultado-chave.

Claro, talvez você precisa de uma Lean Inception. Se tem o objetivo e o resultado-chave muito claro, você tem muito claro o que é o outcome. Talvez, o time ainda se perca na tradução de outcome para output, para alcançar esse resultado, quais são as coisas pequenas nesse trabalho que a gente tem que fazer.

Nesse contexto, aí sim, fazendo uma Lean Inception, você ajuda o time a entender: tá… esse é o objetivo. Como é que a gente quebra em pedaços menores que a gente vai depois jogar nas nossas Sprints?

Aí, são 2 workshops que ajudam com o comprometimento e a entender o trabalho do time, que seria algum workshop de OKR, de alinhamento de objetivos e resultados a serem alcançados e uma Lean Inception, um workshop para alinhar a estratégia do time para criar aquele produto, aquela solução digital, começando por um passo pequeno, o tal do MVP.

3) Configuração da equipe e time multifuncional: Em suas considerações acerca do funcionamento do modelo ágil, ele ainda questiona como que tem que ser o time Scrum para o ágil funcionar?

Cara, agora o contexto do teu time, primeiro, deixa aceitar as organizações, que são organizações enormes, com um contexto complexo, que você têm pessoas de front-end, back-end, developers e começa a montar um time multifuncional.

Se não tem a meta muito clara e fica cada um de áreas diferentes que, agora teoricamente está seguindo um framework ágil, pode ficar torto mesmo. Como os produtos, como as soluções estão sendo encaixadas? Isso é difícil mesmo isso, isso aí não tem nenhuma forma de você cortar vai ter uma saída muito fácil.

Mas, você tem que entender, tem que buscar a melhor forma onde você tenha um time com o objetivo claro, um time multifuncional e com menos dependência possível de outros times, dada a importância do time ser multifuncional… em vez de ficar um time de front-end dependendo do time de back-end.

Mas o escopo tem que ser relativamente pequeno, eu não posso falar é um produto, bota aí são 100 pessoas todas responsáveis por esse produto multifuncional, o que não encaixa também. Tem que ser um time relativamente pequeno. Então, a forma como você vai quebrar esse teu portfólio de programa em produtos ou produtos em features ela é super importante.

Essa aí, o que eu vou te falar, ela nem encaixa numa Lean Inception, essa é alguma coisa antes da Lean Inception, de como você prioriza ou particiona o seu portfólio de programa em produtos, em soluções, em features.

É super importante também, se ela não é bem feita em muitas organizações grandes, até pela complexidade, ela não é bem feita, isso acaba caindo para os times e aí os times são maiores, eles são pessoas de várias áreas, não necessariamente multifuncional, mas é muita gente de várias áreas tentando resolver um problema complexo junto que tem dependência com outros times. E aí, fica realmente difícil o comprometimento e entender até o cronograma desse time.

4) Daily Scrum: Em sua visão, a Daily Scrum não funcionou por onde passou, pois, na maioria dos casos, interessava saber o que o colega estava fazendo na hora em que fosse necessário e não em parar todo um trabalho para ouvir aquilo.

Gostei do teu relato sobre a Daily Scrum. Algumas mudanças: antigamente, a Daily, acho que estava até no Scrum Guide, que a gente falava o que eu fiz ontem, o que vou fazer hoje e se tem algum impedimento. Isso foi mudando tá, quer dizer, essas perguntas elas são úteis se o time está super entrosado, tem a meta da Sprint muito clara, mas, o mais importante da Sprint é a meta da Sprint.

A gente tem que estar com isso muito claro. Qual é a meta e, todo o dia, a gente tem um alinhamento muito rápido de como é que a gente está com relação àquela meta. Não precisa ser só nesse formato do que fiz ontem, o que vou fazer hoje e qual meu impedimento. Esse formato, se o time não está entrosado, ele acaba sendo muito individualista, exatamente como você está relatando.

Outra coisa é que a Daily, a gente quando fazia Daily lá no início, a gente chamava de stand up meeting, Daily Scrum, Daily stand up, stand up Scrum Daily. Tinha até brincadeira, tinha time que pegava um peso ali de 3 kg e quando você falava tinha que ficar segurando o peso com o braço esticado que é pra ser rápido, para não ser chato.

A gente sabe a meta, todo mundo junto, todo mundo participou do planejamento da Sprint, a gente tá junto todo dia e 15 minutinhos e, geralmente, a gente sentava junto 15 minutinhos e ficava cada um dando o seu update com relação àquela meta.

O objetivo principal era, cara, eu estou precisando de ajuda, ouvi você falando disso, posso te ajudar com isso, é o time se ajudando para alcançar aquela meta e esse é o principal objetivo da Daily. Se tu tá com o time que tem alguém que está ali que realmente não dá bola para o que está sendo falado, é provavelmente o trabalho, o jeito que ele está distribuído, a meta da Sprint não está clara, tem alguém que está trabalhando em uma coisa isolado, nem tinha que estar nesse time nesse momento.

Realmente, você está descrevendo uma disfunção muito grande. Para resolver? De novo, é alinhar bastante antes até do Scrum, talvez com Lean Inception, alinhar num Planning com a meta da Sprint e fazer a Daily rápido. Eu sei que o desafio do remoto né a gente está sentado e as coisas levam mais tempo, mas sei lá, talvez o mesmo remoto de todo mundo de pé numa perna só para ir mais rápido, alguma coisa assim.

5) Planning no meio da Sprint: Ele conta que na empresa era feita uma Planning inicial, antes de começar todo o trabalho, e na segunda semana de Sprint todo time tinha que parar com o objetivo de fazer outra Planning da próxima tarefa.

Concordo muito, eu também não gosto de numerozinho, de estimativa, até entendo, porque a gente usava isso antigamente, já não uso há muitos anos. Eu compreendo um time começando com ágil querendo usar isso ainda, eu acho que, com o tempo, a gente vai deixando de lado essa parte de estimativa, vou até falar o nome do Planning Poker né, story points, essas coisas que a gente usava, pelo menos eu usava antigamente e parei de usar há muito tempo.

Você falou de outro smell né, não code smell, mas agility smell, que é esse Planning no meio da Sprint ou interrupções no meio da Sprint. Cara, se tu fez um Planning lá no início, não é no meio da Sprint que tu vai ficar fazendo Planning. A Sprint ela é curta, fez o planejamento e vamos embora até o final com a Sprint. Está clara a meta da Sprint.

Talvez teu Planning ele esteja muito tarefal, falando exatamente cada tarefa que você vai fazer. O Planning tem que ser claro, pode até ter um pouco ali de histórias do usuário, para descrever né o que é que vai ser feito, os critérios de aceite, mas tem que ser claro sobre qual é a meta da Sprint e deixa o time correr atrás e buscar essa meta durante a Sprint.

E o time que faz isso com comprometimento, falando não, olha só, eu acho que alcanço como meta essas duas funcionalidades, é porque o time está seguro e já fez previamente antes daquelas Sprints, o time vinha fazendo o refinamento do trabalho a ser feito.

Então, tem algumas coisas que parecem estar faltando. Um é Lean Inception, um alinhamento para lá na frente a gente entender as features, as hipóteses que a gente quer fazer, em que ordem elas estão.

Depois, você precisa estar fazendo o PBB, do Fábio Aguiar. Tem que estar rodando PBBs curtos de vez em quando, depois da Lean Inception já roda um. Depois, de tempo em tempo, se necessário, a pessoa PO chama o time num canto e roda o PBB mais curto, umas duas horinhas.

Rodando o PBB com frequência aí o time começa a ter um backlog de histórias do usuário que vão estar no estado ready, para ser desenvolvidas, e aí sim, quando for numa reunião de planejamento, a gente tá falando de meta da Sprint e ainda puxa histórias do usuário que estão no estado ready.

Então você passa um planejamento da Sprint, que a meta tá clara, tá todo mundo alinhado, comprometido e até entende-se a meta por causa da Lean Inception, com a estratégia de mais longo prazo e as histórias estão no estado ready, provavelmente, naquela Sprint você não vai ter interrupção, vai estar todo mundo alinhado, as histórias estão ready e vamos embora.

Aí, as coisas ficam mais fáceis, mas se você perceber tem um nível de maturidade né, não é só o Scrum nu e cru básico ali, com story point, Planning Poker e vamos lá. Eu até entendo o intuito da pessoa Scrum Master de querer estar refinando histórias das Sprints seguintes, mas a forma como fazer isso faz toda a diferença.

E outra dica nesse problema vai de refinamento. Refinamento tem que ser contínuo, não é um planejamento no meio da Sprint. Uma ferramenta para refinamento contínuo é o PBB, não para todas as features, mas faz para uma feature, despois para outra, depois para outra e só puxa para a Sprint Planning histórias que tenham passado por um refinamento e estejam naquele estado aceito que passou pelo checklist definition of ready.

6) O ágil que não funciona: O profissional deixa claro que não está querendo dizer que o ágil não funciona em nenhum lugar, mas que onde trabalhou até hoje nunca viu isso acontecer. Ele questiona se isso é culpa dos profissionais, das instituições ou de cada um de nós, por que não funcionou onde trabalhou e pergunta: onde está o poder do ágil que ele ainda não conseguiu ver?

O ágil não funciona, mais uma vez, eu concordo, porque não é uma coisa ali que você faz ali, pega uma certificação, joga o time lá e fala: e aí vocês estão seguindo o framework tal e tal e vai funcionar. Não vai.

Nem para mim, cara, eu passo em vários times nos quais o ágil funciona. Mas não é que você pega ali e diz oh galera, está aqui, sacode o framework, vamos embora, que vai começar e sair funcionando. Não, nunca sai funcionando.

O livro que escrevi com a Mary, o Sprint a Sprint, que tu vai ler, uma história real lá de um time que eu tava. A Mary é uma excelente profissional, eu excelente profissional, todo mundo naquele time é excelente profissional. Você vai ler e, se tu ler tu vai ver, os desafios que o time passa. Então, o ágil de cara ele não funciona. Ele é um bom framework para você buscar uma boa interação e melhorar.

Então, o que eu te indicaria de tudo isso de ágil, que é muita ferramenta, é muita coisa, dependendo do nível de maturidade. Eu te indicaria é de tudo de ágil: cara, se agarra somente na Retrospectiva. Não interessa qual o contexto atual da organização, qual buzzwords eles estão usando, qual a certificação, mas para a cada semana…

Não é nem a cada duas semanas, a cada semana e fala o que a gente vai fazer para melhorar? Basicamente isso, o que a gente vai fazer? Olha para trás, olha a semana, o que aconteceu, beleza, e aí o que a gente vai fazer diferente semana que vem para melhorar?

Semana a semana, mês a mês, ano a ano tu vai ver que aí sim, nessa organização, nesse time que está buscando a melhoria contínua você vai melhorar, porque independente de como você começou, a gente vai se encaixando não interessa se a pessoa vem com uma certificação Scrum, outro vem com certificação Lean Inception, outro com certificação Kanban…

Todo mundo cheio das ideias, mas vamos lá, semana a semana, e aí que a gente vai fazer diferente semana que vem? Nesse exemplo que você está relatando, eu faria isso: começou a trabalhar em um time novo? Primeiro, a Retrospectiva. Galera vem cá, na stand up eu estou me sentindo assim, porque isso, para mim é uma perda de tempo.

Aí, na Retrospectiva seguinte, você vai falar assim: gente, não estou entendendo as histórias a gente está passando de uma Sprint para a outra. Acho que não faz sentido, o que vocês acham disso e vai conversar sobre esse assunto e, cada semana, vai atacar um assunto novo. Não dá para atacar tudo de uma vez, tá, mas, assim, em cada semana você vai atacando um assunto com o tempo tu vê que esse time, aí sim, ele começa a funcionar de forma muito ágil.

7) Clean code e XP: Sobre isso, ele acha que o ágil está muito mais na parte da mão do programador do que na mão do Scrum Master, pois ele considera ter vivido um teatrinho, sem ver as coisas funcionarem.

Adorei o teu relato. Cara, ágil, pelo menos para mim e muitas pessoas com um perfil parecido com o meu, era a técnica de programação. Era extreme programming, era clean code… essas trouxeram muito valor, a gente melhorou muito a forma como a gente desenvolve software, da programação mesmo e isso trouxe muita agilidade para o negócio.

A gente está se deparando com o desafio além do código. Eu concordo com você plenamente tá, é o clean code, é integração contínua, é usar o feature toggle. Agora, a parte de dados mais encapsulada perto dos microsserviços, até uma parte aí de Data Mesh, tem muita evolução que a gente vê há muitos anos, na parte da agilidade mais próxima do código.

Isso faz muita diferença. Até aquele livro Accelerate, ali era uma galera que era técnica que evoluiu, trouxe o business agility, mediu e percebeu que a gente melhorando a eficiência operacional da parte do código, dessa infraestrutura que vem desde lá de developers, vai aumentar e muito a agilidade das empresas.

Ainda assim, a gente vai precisar dessa coordenação com times, com Scrum Masters, com Product Managers, com Product Owners e aí que o sapato está se apertando. Só que eu sei né, quando você falou o nome da empresa, eu sei que é enorme, eu sei que é muito time. Então, um grande desafio que vocês têm não é nem a nível de time, é a nível de portfólio, alinhamento de portfólio, montagem das equipes, as Lean Inceptions.

Então, você está pegando um desafio, ele vem antes. Por isso, que eu entendo quando você fala para mim não funciona, porque, realmente, os exemplos que você deu de empresas são muito complexos e essa mudança, essa transformação para esse tamanho de empresa ela é grande, ela é bem grande.

E, para piorar né, quando a gente fala de ágil, cara, não tem um ágil. Só de treinamento e certificação você vai ter 20 que valem a pena e como é que você vai ter as 20 pessoas de um time, todas que passaram por treinamentos similares, tendo uma linguagem comum e se entendem? Não acontece, mesmo que todos passem pelos treinamentos, cada uma vai querer implementar numa hora diferente.

Precisa ter sim um alinhamento entre cada equipe, entre as equipes, entre o portfólio e esse é o grande desafio. Até pra te dar exemplo, vou falar da minha área, de livro que eu escrevi. Eu vou falar beleza, você tem que ler e entender o Lean Inception, o PBB resolve teus problemas, o Sprint a Sprint tem uma história, a Retrospectiva te ajuda, mas ainda estão faltando uns cinco livros de coisas que te falei.

Essa parte de portfólio, de programa, de OKR é super importante e eu nem tenho um livro para te falar é esse livro só. Eu vou te falar esses 20 livros, que eu lembro na minha cabeça hoje, fazem sentido. Só que da minha cabeça fazer sentido e da cabeça de alguém fazer sentido e do time todo estar alinhado, leva um tempo. Então, a dica é continua de mente aberta sabendo que esse terreno ele fica mudando, não é uma coisa assim de ah, todo mundo leu Scrum e vai funcionar, tanto que você está vendo que não funciona não.

É só uma coisa, você é a combinação de várias coisas no mundo que está mudando constantemente. De parte, eu concordo contigo: se agarra na parte do código, já vi que é a parte que tu gosta, melhora essa parte que você consegue ter domínio para melhorar, melhora e tenta influenciar a meta do time para pelo menos ficar mais clara.

Se não tiver clara, levanta e fala: cara, não está claro, o que a gente está começando nessa Sprint, não está claro, não está claro, se tu levantar quatro vezes falando que não está claro e ninguém fizer nada, levanta a mão mais alto e fala próximo projeto, próxima iniciativa eu só começo com uma Lean Inception e, na Lean Inception, aí você vai lá e fala, espera aí, vamos entender porque a gente está fazendo isso, porque a gente está fazendo aquilo, qual vai ser a ordem das features que aí, pelo menos, as coisas ficam alinhadas a priori.

 

E aqui o episódio de hoje. Espero que você tenha gostado. Eu te peço para se inscrever e recomendar esse Podcast na sua plataforma de Podcast preferida, como Spotify e YouTube, e nas redes sociais. Ou, como eu prefiro: recomende aos seus amigos. Assim, você me ajuda com a missão de compartilhar conhecimento sobre as novas relações de trabalho, de forma a contribuir para a transformação de um mundo melhor.

>> Esse Podcast não tem patrocinadores. Então, se você vem curtindo esse Podcast e quer colaborar com a nossa equipe, vá em www.mepagaumcafe.com.br/caroli. Muito obrigado!

>> Confira os comentários no LinkedIn

Notas do episódio:

Treinamento Scrum Basics

 

>> Adicione nosso podcast a sua playlist