terça-feira, 15 de fevereiro de 2022

Correção de Bug não agrega valor! Será?

 Certa feita, ouvi um Agile Coach dizer muito enfaticamente: "Correção de Bug não agrega valor para o cliente". Imediatamente pensei: "Se ele soubesse o que aconteceu na Metabook, não falaria isso". E, para explicar o motivo deste meu pensamento, vou contar um "causo".

 Esta história aconteceu no sistema solar de uma estrela chamada Sol, num planeta chamado Terra, um país chamado Brasil, no estado do Rio de Janeiro, na cidade de Nova Iguaçu. Se eu não dissesse que foi num universo paralelo você jamais acreditaria que este é um caso real.

 Na verdade, em relação a nós, este planeta Terra está localizado nos mesmos pontos das três dimensões de espaço e da dimensão de tempo, mas num local diferente na dimensão da probabilidade. Nesta Terra, coisas absolutamente improváveis para nós acontecem frequentemente. Para fim de desambiguação, chamarei o planeta de Terra 2.0.

 Na Terra 2.0, a cidade de Nova Iguaçu/RJ abrigava uma das maiores empresas de TI do país. Nesta empresa, chamada Metabook, João Bonsenso foi trabalhar como Scrum Master.

 Durante uma Sprint Planning, a PO do time dispara:

– Vamos paralisar todas as Melhorias e Evoluções para focar na estabilidade do sistema. A meta da Sprint é recuperar a confiança dos clientes no produto, reduzindo o número de bugs e aumentando a cobertura de testes.

Imediatamente os Desenvolvedores se insurgiram.

– De jeito nenhum! Nós somos desenvolvedores de soluções, não bombeiros.

 João Bonsenso poderia terminar a discussão em 2 minutos, mas preferiu criar polêmica. Simplesmente pediu aos desenvolvedores para explicarem porque pensavam desta forma.

– Um time ágil é criador de soluções, não apagador de incêndios!

– Nós não somos tarefeiros, não queremos fazer número com o suporte!

– Correção de Bug não agrega valor!

 Bonsenso retomou a palavra e perguntou:

– Por que você diz que time ágil não é apagador de incêndios?

– Porque está no "É - Não É - Faz - Não Faz" do time. Aqui, ó! – Respondeu o Dev.

 Bonsenso seguiu:

– Por que vocês associam essa meta a "tarefeiros" e "número com o suporte"?

 E choveram respostas...

– Porque número de bugs é uma Métrica de Vaidade.

– Isso mesmo, é Métrica Tóxica!

(...), (...), (...) 

 Mais uma vez Bonsenso levantou uma questão:

– Por que vocês acreditam que correção de bug não agrega valor?

– Porque a própria Milena disse, quando implantou a metodologia ágil!

– E ela explicou o motivo? – Indagou Bonsenso.

– É porque bug não acrescenta nada de novo no sistema.

 Agora Bonsenso passa a palavra para a PO:

– Por que você acredita que aumentar a estabilidade é o maior valor que podemos entregar na Sprint?

– Porque um sistema de escrituração fiscal que erra no cálculo do imposto não tem valor nenhum. Não existe nada pior para o contador do que mandar o cliente pagar o valor errado. 

 Com as palavras da PO os desenvolvedores bugaram e a sala ficou silenciosa por alguns minutos, até que as mentes dos devs fosse reiniciada. Em seguida, os desenvolvedores concordaram que a melhor opção era fazer a "Sprint de Debug" e perguntaram a João Bonsenso se isso não seria contra o Mindset Ágil.

– Vamos por partes: Em primeiro lugar, o "É - Não É - Faz - Não Faz" tem que refletir a realidade do time e não o time se ajustar ao que diz o quadro. Se "apagar incêndios" é parte da rotina do time, e vocês sabem que é, isso tem que sair da coluna "Não Faz"; jamais o contrário.

 Segundo: não existem métricas de vaidade, nem métricas tóxicas, apenas métricas. Métricas são fatos e todos os fatos são neutros. O que atribui significado, seja positivo ou negativo, a um fato é a interpretação dada a ele. O que define se uma métrica é produtiva ou vaidosa não é o número, é o uso que você faz dele.

 Medir quantidade de bugs para dizer "Reduzi de 1.000 bugs para menos de 10!", é pura vaidade. Acompanhar o número de bugs para identificar se a cada versão o sistema tem se tornado mais instável e se a experiência dos usuários está fortemente comprometida pelos erros, é essencial.

 Terceiro: o Agile Galaxy Manifest diz que a principal medida de progresso é software funcionando. O Scrum Guide of Agile Galaxies diz que o time deve entregar um incremento de produto potencialmente utilizável no final da Sprint.

 Nenhum dos dois fala em entregar "algo novo", ambos falam em entregar algo que funcione. Se corrigir um bug vai fazer uma funcionalidade finalmente funcionar... a entrega incrementa o produto e, portanto, atende plenamente aos requisitos.

 Quarto: a principal responsabilidade do papel de PO é nos indicar como gerar mais valor. Se a nossa PO diz que o maior valor é a estabilidade do sistema, vamos trabalhar na estabilidade do sistema. Não há nada de "anti-ágil" nisso.

 E foi assim que João Bonsenso ensinou ao seu time que correção de bug pode sim acrescentar valor ao produto e evitou a falência do modelo ágil na Metabook e, posteriormente, num efeito borboleta, em toda a Terra 2.0.


Destaco que esta é uma obra de ficção, sem qualquer relação com fatos ocorridos nas empresas nas quais trabalhei ou trabalho atualmente. 

terça-feira, 8 de fevereiro de 2022

Vamos falar sobre transparência?

 "O processo emergente e o trabalho devem ser visíveis tanto para quem executa o trabalho quanto para quem recebe o trabalho". Assim a transparência é definida no #scrum guide, mas será que isso é suficiente?

Para sustentar o pilar o empírico do Scrum, especificamente no desenvolvimento de um produto, acredito que sim. Contudo, quando penso na sustentabilidade do time e da empresa como um todo, entendo que não. Tenho plena convicção de que é preciso levar a transparência a níveis mais altos, alinhando Estratégico, Tático e Operacional em políticas, regras, processos e práticas transparentes. Sem esquecer, claro, da transparência com clientes, fornecedores e público em geral.

Para ilustrar como a falta de transparência da empresa, por exemplo, nas redes sociais pode levar à falta de transparência dos empregados com seus gestores, vou contar uma história verídica acontecida... digamos... no quinto planeta do sistema solar de Betelgeuse, conhecido como Betelgeuse V.

Betelgeuse V ganhara pela 14ª vez consecutiva o prêmio GPTW (Great Planet To Work) na categoria Tecnologia da Informação Intergaláctica. Em suas redes socias interdimensionais, Betelgeuse V não cansava de se vangloriar da conquista: "Somos mais uma vez GPTW!", "Venha tirar uma selfie com o troféu!", "Nossa satisfação interna está acima de 90% há décadas!" etc. etc. etc.

Dentro de Betelgeuse V a realidade parecia totalmente coerente e convergente, para o oposto do que dizia o setor de marketing. Vamos aos exemplos:


Caso 01 - Um Certo Alguém

Quando João Bonsenso chegou, em seu primeiro dia de trabalho, foi avisado de que, se quisesse algum dia crescer na organização, precisaria "cair nas graças" de Certo Alguém.

_ Mas por que isso? Ele é parente do dono?
_ Não, mas ele já foi pego roubando o planeta duas vezes e, em ambas, os denunciantes foram expulsos.
_ Como assim?
_ O diretor de produtos abraçou a questão, o transformou em vítima e ainda o promoveu.
_ Tem certeza de que foi assim mesmo?
_ Não há dúvidas, as provas ainda estão no Git. Só que o diretor lançou um campo de "problema de outra pessoa" sobre elas e agora ninguém mais as vê. Mas você consegue enxergar se se esforçar o suficiente.

Aqui faltou transparência sobre as denúncias, a apuração dos fatos e as decisões subsequentes.


Caso 02 - Encontro com Deus

Certo dia, João Bonsenso teve um problema e buscou seu gestor (aquele Certo Alguém) para resolver a questão. Certo Alguém respondeu:


_ Por que você está me trazendo este problema que pode ser resolvido por mortais?
_ ???
_ Antes de vir a deus você precisa passar pelos Bispos, o Papa, os Santos, Jesus... depois fala comigo.

Neste caso faltou transparência sobre os procedimentos internos para solução de problemas e comunicação.
 


Caso 03 - Ideias apropriadas

João Bonsenso recebeu de Certo Alguém uma tarefa muito importante, perguntou se havia alguma instrução especial para a execução da tarefa e ouviu que não. Ele teria liberdade para executar como preferisse.

Passado um mês, Certo Alguém chama Bonsenso e lhe aplica uma bela bronca.

_ Isso é completamente inadmissível!
_ O que houve?
_ De onde você tirou essa ideia absurda de fazer Sprint Planning deste jeito.
_ Eu sempre fiz assim onde trabalhei
_ Então sempre fez errado. Vou te perdoar porque foi a primeira vez comigo, mas eu não admito um segundo erro. Outra coisa: Ouvi muitos elogios sobre você ultimamente.
_ Obrigado
_ Não! Isso é péssimo! Se os outros setores estão te elogiando é porque você está olhando muito pras dores deles e se esquecendo das nossas. Eu espero que você se preocupe primeiro com as nossas próprias necessidades.

Passados mais dois meses, Certo Alguém reúne metade do planeta para anunciar que, pesquisando as melhores práticas difundidas nos confins da Via Láctea, desenvolveu um novo e revolucionário processo de Sprint Planning. Por ser uma técnica recém-criada na mente dele, começaria em modo experimental para ser evoluída aos poucos.

E apresentou exatamente aquele modo "inadmissível" que João Bonsenso havia usado. Ficando com os louros betelgeusianos da vitória apenas para si.

_ Fica triste não Bonsenso, é assim que se cresce aqui. Agora ele te deve um favor. – Disse um colega.


Agora temos um caso de falta de transparência generalizada. O "mentor" da novidade foi ocultado, a forma como essa novidade foi descoberta também. Este é o famoso castelo de mentiras.


Caso 04 - Sprint Infinita

Certo Alguém criou uma nova regra para as Sprints de Betelgeuse V: Os desenvolvedores deveriam trabalhar até que todos os itens de backlog estivessem completos. Não importando se para isso teriam que fazer horas extras, trabalhar sábados, domingos ou feriados. Sem receber nada por esse trabalho além do expediente.


_ A empresa se comprometeu a pagar os salários de vocês. Vocês se comprometeram a entregar essa Sprint. A empresa cumpre o compromisso dela e vocês tem que cumprir o de vocês. Quero tudo pronto na segunda-feira às 08h. – Disse ele.

Este caso final mostra a falta de transparência dentro do Scrum. A Sprint perdeu sua característica de ser timeboxed e deixou de ter compromisso com sua meta. Tudo foi substituído por um compromisso com tarefas, e estas são concluídas de modo artificial. Escondem-se os problemas atrás de trabalhos "não-CLT" que obviamente são escondidos de "agentes externos".



Citados exemplos do que ocorria cotidianamente em Betelgeuse V, eu chego à pergunta chave: Como uma empresa (digo: planeta) assim consegue ter 90% de satisfação e ganhar um prêmio GPTW?

– Simples, basta destruir a transparência.

Neste caso, a diretoria incluiu a nota da pesquisa de satisfação interna como gatilho para o pagamento do Programa de Participação nos Lucros. Bonsenso e seus colegas preferiram mentir na pesquisa do que perder o décimo-quarto salário. – Afinal de contas, de que adiantaria reclamar contra o Certo Alguém que se autointitula deus e tem apoio de um diretor?

O planeta em questão criou um incentivo financeiro para que seus funcionários buscassem melhorar a satisfação interna. No entanto, recompensas não incentivam as pessoas a fazerem suas tarefas, apenas a conseguirem a recompensa. Desta forma, em vez de melhorar o clima, resolveram violar a transparência da pesquisa, dando sempre respostas que não baixassem a nota do planeta.

A falta de transparência nas avaliações fez com que o C-Level deixasse de ouvir a verdade sobre a saúde do "planeta" e seus trabalhadores, permitindo que práticas antiéticas, e até mesmo criminosas, se tornassem sistemáticas, institucionais e culturais. – Destacando-se que, aparentemente, até mesmo um diretor se envolveu na coisa toda.

Claro que, se a pesquisa de satisfação é a única forma de um gestor acompanhar seus times, já há algo muito errado. – Destaco que esta é apenas uma situação-exemplo. – Muitos outros sinais claros de falta de transparência entre gestores e geridos eram vistos, mas ninguém notava: era "problema de outra pessoa".

E assim os maiores talentos de Betelgeuse V buscavam, constantemente, empregos nos planetas vizinhos e faziam de tudo para levar consigo os seus poucos amigos que ainda estavam no planeta. O destino de Betelgeuse V não parece muito promissor.

P.s. Essa é uma obra de ficção que não tem necessariamente nenhuma relação com as empresas nas quais trabalhei ou trabalho atualmente. É apenas uma representação lúdica e exagerada do que poderia acontecer.

Scrum - You're doing it the right way! Or... maybe... not at all

     Once upon a time, a long time ago, in a galaxy far, far away, there was a human called John Goodsense. John was a senior Scrum Master, ...