Estes dias estava vagando pela internet e achei um texto com uma chamada bem curiosa:
Programador sabe estimar?
Bem, a resposta deveria ser bastante óbvia, já que é o programador quem implementa e sabe, melhor que ninguém, o esforço da implementação, certo? Não muito…
Na minha experiência, estive com diversos times que tinham uma dificuldade monstro para fazer as estimativas. Fiquei um bom tempo matutando sobre qual poderia ser o problema, pois as estimativas nunca eram aproximadas. Ou eram otimistas demais ou pessimistas ao extremo. Em outras palavras, ou o time terminava a sprint no terceiro dia ou precisava de mais uma (ou pouco mais que isso) sprint para entregar a sprint!
Seria inexperiência ou dificuldades técnicas? Não! Sempre tive a sorte de trabalhar com times compostos por pessoas muito boas e esforçadas, que sempre correram atrás do que fosse necessário.
Seria a síndrome do estudante? Murphy? Bom, coisas assim existem, é verdade, mas, como Agile Coach não podemos crer na sindromização do desenvolvimento. Elas existem, sim, em casos isolados e não são fantasmas que assombram os times o tempo todo.
Não! Nada disso! O desenvolvimento é feito por pessoas, pessoas têm crenças que as fortalece ou as limitam. Bingo! Estamos falando de algumas crenças que limitam os programadores a fazerem estimativas de forma ponderada e assertiva.
Ah, lá vem você com esse papo de coaching!
Ah, sim, lá vou eu com o coaching! Todos nós somos movidos por crenças. Algumas, as fortalecedoras, nos impulsionam a fazer sempre mais e melhor; as limitantes, nos atrapalham nas ações mais simples. É como se você dissesse: “Eu preciso fazer isso. Mas…” Tudo o que vem depois do “mas” são as crenças que temos que vão nos limitar a fazer o que é preciso, da forma mais eficiente.
Identifiquei algumas crenças limitantes que um programador pode ter durante uma sessão de estimation. Você pode identificar outras e ajudar a enriquecer este artigo. Use os comentários sem moderação!
Tenho que resolver todos os problemas
Aqui, o MVP é visto como uma praga que impede o programador de resolver o problema do cliente como um todo. Mas o programador tem que entender que não pode resolver tudo de uma vez! É necessário entender que estamos construindo o software de forma incremental, para que o retorno seja o mais breve possível.
Tenho que entregar rápido
Vamos combinar, de uma vez por todas, que “Agile” não é “Rapidile“. Não se trata de colocar pumas programando loucamente e abrir mão de testes, qualidade, documentação e vida pessoal. Comprometimento é bom, mas ele não deve te anular. E nem deve penalizar alguma parte do processo.
Tenho que aceitar tudo que o PO trouxer
Claro que o trabalho do Product Owner é tentar maximizar o uso do time; mas isso não significa que o time não pode dar um basta nas solicitações. deve haver uma batalha de forças contrárias, facilitada e mediada pelo Scrum Master. Lembre-se: você não está sozinho!
Tenho que botar umas gordurinhas
Tem desenvolvedor que acha que tudo vai dar errado! Tudo mesmo! são os famosos “e se…” E se infra não entregar o ambiente? E se o tester encontrar muitos erros? E se o servidor cair em um buraco negro? Gente! Es-ti-ma-ti-va! Não tem problema se errar um pouco. Pense em dias ideais de trabalho e reporte todos os problemas durante a jornada. Comunicação clara, simples assim!
Não entendi nada! Vou chutar!
Isso é muito mais comum do que você imagina! Coloque um baralho do planning poker na mão de alguém que acabou de entrar no time e peça para estimar em story points. Quase sempre vai sair alguma estimativa. Raramente uma incerteza. Temos vergonha de não saber as coisas (including myself). Mas não há vergonha alguma em não saber e perguntar! Aliás, para que as estimativas sejam mais assertivas, precisamos entender perfeitamente o que estamos estimando. E, se não entendemos, perguntamos!
Como quebrar crenças limitantes?
Bom, pra quebrar uma crença, primeiro, é necessário entender como funcionam as crenças, de uma maneira geral. Quando se fala de crenças limitantes, geralmente não nos damos conta de que existe um problema ou que estamos nos auto sabotando.
Uma crença limitante nasce a partir da generalização de uma experiência dolorosa. Internalizamos uma falsa verdade que nos impede de sermos assertivos.
Exemplos:
Uma vez fiz uma pergunta numa reunião e todo mundo achou idiota; passaram meses tirando sarro da minha cara;
Da última vez, não conseguimos entregar por que aconteceram vários problemas; e o chefe ficou muito bravo com todos;
Já me recusei a fazer alguns trabalhos e fui demitido
Então, internalizamos a experiência negativa e usamos nossos mecanismos de defesa para criar um novo hábito que nos proteja daquela situação dolorosa. Afinal, nunca mais quero ver o chefe bravo, ser demitido ou ter todo mundo tirando sarro de mim!
Em linhas bem gerais, existem alguns passos para trabalhar uma crença:
Identificar as crenças limitantes
O trabalho do Agile Coach é identificar as possíveis crenças que podem estar limitando o potencial do time e atuar individualmente em cada caso. Muitas vezes prestar atenção nas palavras do time durante a retrospectiva ajuda muito a identificar. “Toda vez” e “sempre” estão diretamente ligadas a crenças. Fique de olho!
Encontrar a causa da crença
Identifique qual foi a experiência dolorosa que causou o hábito. Muitas vezes, apenas falar em voz alta sobre o assunto ajuda muito no processo de libertação.
Definir claramente onde quer chegar e quais os benefícios de não ter a crença
O que você ganha se não colocar gordura na estimativa ou se disser alguns “não” para o Product Owner? Onde você chegará se agir desta forma?
Substituir a crença limitante por uma crença fortalecedora
Ao invés de pensar que será demitido, que tal pensar que todos vão admirá-lo por proteger o time de aceitar issues que não pode cumprir? Se se todos começarem a pensar que o time é ponta firme e sempre entrega o que promete?
Condicionar a nova crença, até que se torne um hábito
Não tem segredo! A coisa tem que virar um hábito. Não adianta simplesmente negar uma crença limitante, se você não acredita na nova crença fortalecedora. Acredite, essa é a parte mais difícil. Quando eu fiz minha formação em coaching foi exatamente o ponto onde fiquei travado. Você está substituindo um hábito que te protege de uma dor do passado por algo que vai te trazer retorno no futuro.
É necessário abrir a mente e se permitir acreditar que seu novo mindset é melhor que o antigo. Acima de tudo, é preciso que você se monitore o tempo todo até que este mindset se torne um hábito. Afinal, muitas vezes agimos no “piloto automático”.
Seguindo estas dicas e mudando o seu mindset relacionado ao que te limita, da próxima vez que te perguntarem, você vai responder com bastante segurança e propriedade:
Sim, programador sabe estimar e melhor do que qualquer um!
Bom dia
Excepcional seu artigo, muito bem explanado e de altíssimo valor para todos nós. Usarei em sala de aula. Parabéns!
CurtirCurtido por 1 pessoa
Puxa, fico muito feliz, de verdade! Obrigado!
CurtirCurtido por 1 pessoa
Bom dia Marcelo.
Vejo muitos falando em Ágil… Agile “impõe” naturalmente Feedback. É muito fácil propalar em sala de aula o Feedback somente para desenvolvimento de softwares, e continuar ignorando prover feedback para os nossos fornecedores, clientes, leitores, amigos, etc. Eu procuro dar feedback sempre. Isto tem um custo, mas o resultado vale muito a pena. Falo muito disso em meu blog: canaldevbr.wordpress.com
Acredite no poder da comunicação e colaboração intensa que são as bases do feedback, que nos ajudar a obter a melhoria contínua.
Observação: Começarei a usar(com os devidos/merecidos créditos) seu texto na próxima semana, em uma turma de Scrum em SP.
Acredito neste tipo de Agile, de mão na massa, de interações, de muito dialogo e trabalho árduo.
Um forte abraço.
CurtirCurtir
[…] (Cross-post de https://agilemomentum.com.br/2016/06/22/estimativas-ageis-e-crencas-limitantes/) […]
CurtirCurtir
Que bacana esse texto, gostei bastante. Marcelo, você acha que a equipe usar uma técnica para ajudar a estimar ajuda a quebrar a crença limitante de não saber estimar? Ou pode ser apenas uma desculpa para depois, se a técnica não funcionar bem, usar como justificativa e lamentações?
CurtirCurtir
Oi, Roger! Eu acho que todos nós temos receio de fazer estimativas, por que, pela nossa história passada, se algo desse errado, a culpa se voltaria pra gente. Ter alguém que use o mantra “estimativas são estimativas” com frequência, encorajando o time a tentar é muito válido pra quebrar esse pensamento limitante. Obrigado pela participação! Abraços
CurtirCurtir