terça-feira, 19 de janeiro de 2021

Elimine a Vaidade das suas Reviews

    Há alguns dias, pensando sobre como poderia ajudar um time Scrum, me deparei com uma situação: Eles faziam Sprint Reviews puramente vaidosas. E a busca pela causa-raiz dessa distorção do evento me levou ao maior problema daquele time, que era a falta de trabalho em equipe.

   — Review Vaidosa? De onde você tirou isso?

   Vamos primeiro entender o contexto, para depois avançar sobre as conclusões. Conversando com os membros do time, descobri que o Scrum Master era um desenvolvedor sênior que foi empossado no cargo sem jamais ter visto um Scrum rodando nem sequer ter lido o Scrum Guide. — Diga-se de passagem, foi exatamente isso que eu fiz comigo mesmo há uns 10 anos — Ele leu artigos na internet e começou a fazer conforme foi capaz de entender. Preciso destacar que ele, considerando o contexto, estava fazendo um bom trabalho.

   A partir disto eu pedi que as pessoas detalhassem como aconteciam os eventos... Terminada a reunião, comecei a meditar sobre o que havia escutado para definir quais seriam as entradas das próximas sessões.

   Eis que surge o problema...

   Durante a sessão, o time revelou que fazia regularmente Sprint Reviews, mas delas somente participavam os membros do próprio time. Eu perguntei qual era o objetivo dessa reunião e eles responderam que eram dois:

  1. Revisar o que foi desenvolvido para identificar os ajustes que precisam ser feitos antes de enviar ao cliente.
  2. Apresentar aos outros membros do time o que cada um fez.
   O fato de eles identificarem ajustes a serem feitos na Review demonstra que a Definição de Pronto deles estava mal definida, mas o meu foco aqui é o segundo motivo. Por que eles viam utilidade em apresentar para os outros o que cada um fez?

   A resposta é óbvia: Porque eles não trabalhavam em equipe! Se todos estivessem envolvidos em todas as tarefas, não haveria nada a ser apresentado; todos saberiam o que os outros fizeram. Ou melhor: todos teriam feito tudo juntos. E aí me veio o insight que dá título a este artigo.

   O time usava as Reviews para admirar o próprio trabalho e trocar aplausos com os colegas, ou seja, para um momento vaidoso. Esse momento de vã exibição acontece principalmente porque cada desenvolvedor faz o seu próprio trabalho e, no final da Sprint, esses trabalhos são ajuntados num mesmo produto. O principal problema disso é que a colagem de vários trabalhos individuais não é, nem nunca será, um trabalho em equipe. 

   Falarei mais sobre a diferença entre o "trabalho em equipe" e a "coleção de trabalhos individuais" numa próxima publicação; e farei o mesmo sobre "celebração" e "exibição vaidosa". Por enquanto, deixo o alerta:

Reviews Vaidosas são sintoma de falta de trabalho em equipe!

sexta-feira, 18 de dezembro de 2020

Como se tornar um verdadeiro líder?

 Nesse artigo eu não vou falar nada. Vou apenas abrir o espaço para você assistir essa verdadeira pérola entregue por Simon Sinek:



Depois disso eu vou falar o que?

segunda-feira, 14 de dezembro de 2020

A Fábula dos Porcos Assados

Este texto me foi apresentado numa aula de Organização Empresarial, quando cursava o Ensino Médio, em 1998. Agora, que estamos literalmente em outro milênio, por acaso o encontrei no arquivo do site passeidireto.com e fiquei impressionado com o quanto isso ainda faz sentido.

Quando falamos de Agile, Lean etc. ainda é assim que muitos pensam. Há algumas semanas contei aqui uma situação pela qual passei, que mostra bem como essa fábula continua atual.

Vamos a estória:

Certa vez, aconteceu um incêndio num bosque onde se encontravam alguns porcos. Estes foram assados pelo incêndio. Os homens, acostumados a comer carne crua, experimentaram os porcos assados e acharam deliciosos. Logo, toda vez que queriam comer carne assada incendiavam o bosque...

O sistema foi desenvolvido e aperfeiçoado. Mas nem sempre as coisas iam bem: às vezes os animais ficavam queimados ou parcialmente crus; outras, de tal maneira queimados que era impossível utilizá-los. Como era um procedimento montado em grande escala, isso preocupava muito a todos, porque, se o Sistema falhava, as perdas ocasionadas eram igualmente grandes. Milhões de pessoas alimentavam-se só de carne assada e também muitos eram os que tinham ocupação nessa tarefa. Portanto, o Sistema simplesmente não devia falhar. Mas, curiosamente, à medida que se fazia em maiores escalas, mais parecia falhar e maiores perdas parecia causar.

Em razão das deficiências, aumentavam as queixas. Já era um clamor geral a necessidade de se reformar profundamente o Sistema. Tanto assim que, todos os anos, realizavam-se congressos, seminários, conferências e jornadas para achar a solução. Mas parece que não acertavam o melhoramento do mecanismo, porque no ano seguinte repetiam-se os congressos, os seminários, as conferências e as jornadas. E assim sempre.

A causa do fracasso do Sistema, segundo os especialistas, podiam ser atribuídas ou à indisciplina dos porcos, que não permaneciam onde deviam, ou à inconstante natureza do fogo, difícil de controlar, ou às árvores excessivamente verdes, ou à umidade da terra, ou ao serviço de informações meteorológicas que não acertava o lugar, o momento e a quantidade de chuva, ou...

Como se vê, as causas eram difíceis de determinar, porque na verdade, o Sistema para assar os porcos era muito complexo. Fora montado uma grande estrutura; uma enorme maquinaria com inúmeras variáveis tinha sido institucionalizada. Havia indivíduos dedicados a acender – os incendiadores – que, ao mesmo tempo, eram especialistas de setores. Havia incendiadores da Zona Norte, da Zona Oeste, etc., incendiadores noturnos, diurnos, com especialização matutina e vespertina, incendiadores de verão, inverno, com disputas jurídicas sobre o outono e a primavera.

Havia especialista em vento, os anemotécnicos, um Diretor Geral de Assamento e Alimentação Assada, um Diretor de Técnicas Ígneas (com seu conselho geral de assessores), um Administrador Geral de Florestação Incendiável, uma Comissão Nacional de Treinamento Profissional em Porcologia, um Instituto Superior de Cultura e Técnicas Alimentícias (ISCUTA) e o BODRIO (Bureau Orientador de Reformas Ígneo-Operativas).

O BODRIO era tão grande, que tinha um inspetor de reformas para cada 7.000 porcos, aproximadamente. E era precisamente o BODRIO que propiciava anualmente os congressos, os seminários, as conferências e as jornadas. Mas isto só parecia servir para incrementar o BODRIO em burocracia. Tinha se projetado e encontrava-se em pleno crescimento a formação de novos bosques e selvas, seguindo as últimas indicações técnicas, em regiões escolhidas segundo determinada orientação, onde os ventos não soprassem mais de 3 horas seguidas e houvesse reduzida porcentagem de umidade. Havia milhões de pessoas trabalhando na preparação dos bosques a serem incendiados. Alguns especialistas eram enviados para a Europa e os EUA, com a missão de estudar a importação das melhores madeiras, árvores, sementes, fogos melhores e mais potentes, além de pesquisar ideias operativas, por exemplo, como fazer buracos para que neles caíssem os porcos.

Havia também grandes instalações para manter os porcos antes do incêndio, mecanismos para deixá-los sair no momento oportuno, técnicos em sua alimentação, etc. Havia construções de estábulos para porcos, professores formadores de especialistas na construção de estábulos para porcos, universidades que preparavam os professores formadores dos especialistas na construção dos estábulos para porcos, fundações que apoiavam os investigadores que davam o fruto do seu trabalho às universidades que preparavam os professores formadores na construção de estábulo para porcos, etc.

As soluções que os congressos sugeriam eram, por exemplo, aplicar triangularmente o fogo após Va -1 pela velocidade do vento sul, soltar os porcos 15 minutos antes que o fogo-promédio da floresta alcançasse 47°; outros diziam que era necessário instalar grandes ventiladores que serviriam para orientar a direção do fogo e assim por diante. Poucos especialistas estavam de acordo entre si e cada um tinha investigações e dados para provar suas afirmações.

Um dia, um investigador da categoria SO/DM/VCH , chamado João Bonsenso falou que o problema era muito fácil de se resolver. Tudo consistia, segundo ele, primeiramente, em matar o porco escolhido, limpando e cortando adequadamente o animal e colocando-o, posteriormente, numa jaula metálica ou armação sobre brasas, até que o efeito do calor e não das chamas, o assasse ao ponto.

Ciente, o Diretor Geral de Assamento mandou chamá-lo e perguntou que coisa esquisita ele andava falando por ali. Depois de ouvi-lo, disse-lhe:

- O que o senhor fala está bem, somente na teoria. Não vai dar certo na prática. Pior ainda, é impraticável. Vamos ver: o que o senhor faria com os anemotécnicos, no caso de se adotar o que está sugerindo?

- Não sei, respondeu João.

- Onde vai por os acendedores das diversas especialidades?

- Não sei.

- E os indivíduos que foram ao estrangeiro para se especializar durante anos e cuja formação custou tanto ao país? Vou pô-los para limpar porquinhos?

- Não sei.

- E os que têm se especializado todos esses anos em participar dos congressos, seminários e jornadas para a Reforma e Melhoramentos do Sistema? Se o que você fala resolve tudo, que faço com eles?

- Não sei.

- O senhor percebe agora que a sua solução não é aquela de que todos nós necessitamos? O senhor acredita que, se tudo fosse tão simples, os nossos especialistas não teriam achado a solução antes? Veja só! Que autores falam isso? Que autoridade há para avaliar sua sugestão? O senhor, por certo, imagina que eu posso dizer aos engenheiros em anemotécnica que é questão de por brasinhas sem chamas! O que eu faço com os bosques já preparados, no ponto de serem queimados, que somente possuem madeira apta para fogo-em-conjunto, cujas árvores não produzem frutos, cuja falta de folhas faz com que não prestem para dar sombras? O que faço? Diga-me !!!

- Não sei.

- O que faço com a Comissão Redatora de Programas Assados, com seus Departamentos de Classificação e Seleção de Porcos, com a Arquitetura Funcional de Estábulos, estatística, população, etc. ?

- Não sei.

- Diga-me: o Engenheiro em Porcopirotecnia, o Sr. J.C da Figuração, não é uma extraordinária personalidade científica?

- Sim, parece que sim.

- Bem, o simples fato de possuir valiosos e extraordinários engenheiros em Porcopirotecnia indica que o Sistema é bom. E que faço com indivíduos tão valiosos?

- Não sei.

- Viu? O senhor tem é que trazer solução para certos problemas: como fazer melhores anemotécnicos , como conseguir mais rápido acendedores do Oeste (que é a nossa maior dificuldade), como fazer estábulos de oito andares ou mais, em lugar de somente sete, como até agora. Tem que melhorar o que temos e não mudá-lo. Traga-me uma proposta para que nossos bolsistas na Europa custem menos, ou mostre-me como fazer uma boa revista para análise profunda do problema da Reforma do Assamento. É disso que necessitamos. É disso que o país necessita. Ao senhor falta sensatez, senso – comum ! Diga-me, por exemplo, o que faço com meu bom amigo (e parente), o Presidente da Comissão para o Estudo de Aproveitamento Integral dos Resíduos dos Ex-Bosques?

- Realmente, estou perplexo! - falou João.

- Bem, agora que conhece bem o problema, não diga por aí que o senhor conserta tudo. Agora, o senhor vê que o problema é mais sério e não tão simples como o senhor imaginava. Tanto os de baixo como os de fora dizem: “Eu conserto tudo”. Mas tem que estar dentro para conhecer os problemas e saber das dificuldades. Agora, cá entre nós, recomendo-lhe que não insista com sua ideia, porque isso poderia trazer problemas para o senhor no seu cargo. Não por mim! Eu falo pelo seu próprio bem, porque eu o compreendo, entendo seu posicionamento, mas o senhor sabe que pode encontrar outro superior menos compreensivo. O senhor sabe como são, às vezes, não é?

João Bonsenso, coitado, não falou um “A”. Sem despedir-se, meio assustado e meio atordoado com a sensação de estar caminhando de cabeça para baixo, saiu e nunca mais ninguém o viu. Não se sabe para onde foi. Por isso é que, até hoje é costume dizer que, na tarefa de reforma e melhoria do Sistema, falta o bom senso.


Artigo originalmente publicado em:

Juicio de la Escuela,

CIRIGLIANO, F. T.. Editorial

Humanitas, Buenos Aires,

1976.

terça-feira, 1 de dezembro de 2020

Automóveis, Explosões e Decisões

No último domingo, durante a transmissão do Formula 1 Gulf Air Bahrain Grand Prix 2020, esta foi a imagem mais alegre e consoladora que tivemos: Um piloto pulando o muro de proteção após escapar de um carro em chamas. 



— Ok, mas o que isso tem a ver com agilidade? 

Nada, e tudo também. Participando do treinamento High Impact Agile, ministrado pelo grande mestre Gino Terentim, fui introduzido ao Cynefin Framework e nesse acidente pude ver todo o framework em ação.

Para quem não conhece nada de Cynefin (e eu conheço apenas um pouquinho), vou explicar os fundamentos do framework antes de mostrar como o relacionei a uma corrida de automóveis.



O Cynefin é uma ferramenta para tomada de decisões que distribui os problemas em três tipos de sistemas: Ordenado, Complexo e Caótico.

  1. Ordenado - Onde é possível estabelecer relações do tipo causa-efeito e ter alguma previsibilidade. Os sistemas ordenados se subdividem em dois.
    1. Claro - É a situação em que "todo mundo" sabe a resposta. Já existe uma Melhor Prática, Protocolo ou Checklist para a solução do problema. Por exemplo: Trocar uma lâmpada.
    2. Complicado - É uma situação em que a resposta não é óbvia, mas um especialista saberá o que fazer. Após a análise, o especialista adotará as boas práticas que melhor se adequam àquele caso. Por exemplo: Um diagnóstico médico (os procedimentos já estão definidos e documentados mas o somente um especialista pode decidir quando e como aplicá-los).
  2. Complexo - Neste mundo não há definições claras sobre causa e efeito e o ambiente é o chamado VUCA. Neste ambiente as práticas e métodos ágeis produzem resultados incríveis. Um exemplo de situação complexa é o desenvolvimento de uma nova Vacina.
  3. Caótico - O nome já diz tudo, aqui não há nenhuma ordem, clareza ou metodologia. O objetivo primário é sobreviver até que o caos se dissolva. Vale destacar que o Caos é também o maior gerador de inovações, mas isso já está além do escopo deste artigo.
Há ainda as áreas limítrofes e o domínio da Confusão, sobre as quais não falarei neste post.

Para cada domínio, o Cynefin prega maneiras diferentes de se tomar decisões e agir. E é este o gancho que vou usar para puxar o acidente sofrido pelo piloto Romain Grosjean para dentro do Cynefin e mostrar a minha visão disso tudo.

A corrida começou agitada, com alguns pequenos toques e esbarrões entre os carros até que, ainda na primeira volta, um dos competidores cruzou a pista de forma desgovernada e atingiu uma parede de aço a mais de 220km/h. O que se viu em seguida foi uma explosão: O Caos.




O piloto do carro médico e o médico responsável, que chegaram ao local poucos segundos após a colisão, relataram que nunca tinham visto uma situação como aquela. Eles precisaram de um ou dois segundos para perceber o que estava acontecendo (a Confusão). Viram metade de um carro virada em sentido contrário ao percurso e uma bola de fogo à direita. Ficou claro que o piloto estava dentro do fogo.

Neste momento eles estavam num sistema caótico. Não há treinamento, técnica ou protocolo que se aplique a um veículo partido ao meio, envolto em chamas, com o piloto preso dentro dele. O  Dr. Ian Roberts relatou que, como médico, ele precisava salvar a vida do piloto; por isso pegou um extintor de incêndio e disparou em direção às chamas procurando algum sinal. — O que diz o Cynefin sobre situações caóticas? Aja - Entenda - Responda. — E foi isso que eles fizeram: agiram com o extintor, entenderam onde estava o piloto e responderam iniciando a tentativa de tirá-lo das chamas.


Aqui o caos se desfaz momentaneamente e temos uma situação complexa. O carro continua em chamas... Quanto combustível ainda há para queimar? Pode haver outra explosão? O piloto está com o macacão queimado e a viseira do capacete derretida... Qual o estado de saúde dele? Ele consegue andar até o carro médico? E o estado mental de quem acabou de passar 29 segundos dentro de uma bola de fogo? — O que diz o Cynefin sobre resposta a problemas complexos? Sonde - Entenda - Responda — O que eles fizeram? Apoiaram o piloto e tentaram levá-lo até o carro médico. Tentaram remover o capacete e as luvas queimadas. O restante da equipe de pista foi tentar apagar o incêndio. Eles experimentaram pequenas soluções. Neste ponto, já era possível dar pequenos passos e observar se o risco aumentava ou diminuía. Um erro ao tirar as luvas poderia agravar uma possível lesão nas mãos, mas não colocaria a vida do piloto em risco. O próprio médico responsável admitiu depois que deveria ter sido mais sutil quando ajudou o piloto a pular o muro mas, naquele momento (ainda na borda do caos), ele só queria afastá-lo do fogo o mais rápido possível.




Está dando certo levar o piloto até o carro e remover parte do equipamento? Sim. As chamas estão sendo controladas? Sim. Se a sondagem sobre os resultados dos experimentos foi positiva, a resposta é continuar neste caminho. Uma vez que o piloto chegou a um "lugar seguro" e a equipe de crise entendeu o incêndio, a complexidade se encerra e temos um problema complicado.

Na complicação, o framework sugere que nós chamemos especialistas para que eles Entendam - Analisem - Respondam. Como isso se deu? O médico examinou rapidamente o piloto, conferiu seus sinais vitais, fez testes para identificar possíveis ferimentos e fraturas. Analisou os resultados do exame e Respondeu adotando o protocolo de remoção para situações em que não há risco de morte.

Enquanto isso, os especialistas em incêndios e na estrutura de segurança da pista escolhiam e adotavam os protocolos para combate ao fogo e, posteriormente, liberação da pista.

Falar em protocolos nos leva à clareza, onde existem melhores práticas definidas. A atitude é Entender - Categorizar - Responder. A equipe médica continuou avaliando o piloto, categorizou os ferimentos e sintomas identificados e respondeu noticiando a inexistência de lesões graves e levando-o ao hospital de referência para tratamento. Para eles era óbvio o que deveria ser feito.

Assim, demos uma volta completa no quadro do Cynefin, do Caos à Clareza, passando por segundos de confusão, num evento que durou apenas alguns minutos. Vimos que os profissionais altamente capacitados envolvidos tomaram as decisões de acordo com o que diz o framework. Talvez estes nunca tenham ouvido falar em Cynefin e, neste caso, a "coincidência" seria uma demonstração de que a ferramenta orienta corretamente a tomada decisões.

Antes de terminar, ainda destaco mais um ponto: O Cynefin aponta que existe um atalho para caos, conhecido como Abismo da Complacência. Caímos nele quando tratamos como Claro algo que não é tão protocolar assim, quando abrimos uma porta para a negligência, a imprudência ou a imperícia. — E isso tem a ver com o acidente da F1? Tem sim!

O guard rail colocado naquele ponto do circuito deveria ter amortecido o impacto do carro e o devolvido à área de escape. Mas o que aconteceu foi que o carro literalmente furou a proteção. Metade do carro atravessou o muro e somente a segunda metade foi rebatida como esperado. Ainda é cedo para falar sobre isso e os especialistas analisarão exaustivamente o acidente para encontrar as causas, falhas e possíveis melhorias. Eu, que sou leigo e sofro do efeito Dunning-Kruger, penso que existem soluções relativamente simples para evitar que isso ocorra. Por exemplo a colocação de uma barreira de pneus na frente dos guard rails, para que a borracha amorteça o impacto. E por que não havia uma proteção de pneus ali? Porque ninguém imaginava que um carro pudesse atingir aquele ponto do muro num ângulo de quase 90º.

 
Imagem retirada do vídeo ao final do post.



As curvas são mais protegidas, mas nas retas os acidentes com carros saindo perpendicularmente à pista são raríssimos. Apesar de todos os protocolos de segurança, a organização da prova pode ter sido complacente, acreditando que naquele ponto não havia necessidade de dispositivos de segurança adicionais aos guard rails. E a complacência é um atalho para o caos.

Qual lição tiramos disso para nossos times de desenvolvimento? Não trate situações complexas como óbvias (e vice-versa) e planeje as suas respostas conforme o sistema no qual o problema está inserido.

Não estou ganhando nada mas, para fins educativos, faço a propaganda: Quem quiser conhecer mais sobre o Cynefin pode procurar um treinamento (eu recomendo os da Hiflex e do Gino Terentim) ou comprar o livro Cynefin - Weaving Sense-Making into the Fabric of Our World. (Hoje está sendo vendido a R$24,00, em formato digital, na Amazon).




Todas as imagens do acidente utilizadas neste post estão linkadas diretamentes a publicações em redes sociais e plataformas de streaming. Os direitos autorais estão preservados na sua fonte. A imagem ilustrativa do framework Cynefin foi retirada do material oficial do treinamento High Impact Agile.

quarta-feira, 18 de novembro de 2020

Desmistificando o papel do Scrum Master - Parte I

Na minha primeira postagem sobre Scrum, entitulada "Scrum Master - você está fazendo isso errado", citei alguns desvios de função comuns entre os SMs. Neste artigo vou falar sobre os dois primeiros:

  • Se o Scrum Master é responsável por emitir relatórios de status para gestores a partir das informações da Daily Scrum: Você está fazendo isso errado!
  • Se o Scrum Master é responsável por criar Gráficos, atualizar as Stories ou escrever Planos de Ação: Você está fazendo isso errado!
  • O problema nestas situações reside no fato de Scrum Master não responder pelo time e nem ser o secretário da equipe. O SM deve estar focado em fazer o Scrum acontecer.
    Vamos analisar mais detalhadamente os pontos:

    • Emissão de Status Report a partir da Daily: Essa é a melhor forma de destruir as suas reuniões diárias. As Dailies existem para o time se organizar, portanto pertencem ao time, somente ao time, ninguém mais que o time.
      Ao saber que estão sendo controlados, ou medidos, pelo que falam na Daily, os membros do time passarão a se preocupar mais com o "status" do que com a organização para completar a Sprint. Problemas serão omitidos, impedimentos serão diminuídos e tudo estará sempre sob controle até que a bomba estoure na mão de alguém. Scrum é um processo empírico e empirismo se mede por aprendizado, não por tarefa realizada.
      Um dos pilares do Scrum é a transparência, portanto, qualquer parte interessada tem acesso às informações da Sprint. É por isso se usa o conceito da "gestão à vista". Cabe ao SM, neste caso, garantir que as partes interessadas tenham uma maneira de se informar sobre a Sprint. Em geral, um simples Burndown Chart na parede resolve essa necessidade de Status Report pelas partes interessadas. Mas, repito: O Scrum é um processo empírico e empirismo se mede por aprendizado, não por tarefa realizada.
    • Criação de Gráficos: Naturalmente o Scrum Master pode, e deve, criar gráficos para apoiar a gestão do time. Contudo, isso é uma atividade de apoio, não uma responsabilidade primária.
      O ideal seria os gráficos serem gerados por uma ferramenta automatizada para serem analisados e não se tornarem mais uma obrigação do Scrum Master. Na falta de ferramentas automatizadas, qualquer um pode assumir esse papel, preferencialmente quem tiver mais habilidade para isso — até mesmo o SM.
    • Atualização de Stories: Essa eu não vou me alongar — Quem atualiza a story é quem está trabalhando nela! — Por incrível que pareça, já vi um caso em que o time fazia o refinamento dos itens de backlog e passava por e-mail para o SM para que ele atualizasse as stories. E eu prefiro não comentar sobre isso.
    • Planos de Ação: Não sei se eu já disse, mas os times ágeis são auto-organizados. "Planos de Ação" são montados pelo próprio time e a responsabilidade por executá-los também é igualmente repartida entre todas as pessoas. Espera-se que os planos emerjam das Retrospectivas, onde o time discute e decide como melhorar.
      Claro que o Scrum Master pode agrupar as ideias e escrever um documento com o plano de ação estabelecido pelo time, mas isso não pode ser visto como uma responsabilidade dele. Qualquer pessoa do time pode ser a responsável por resumir a discussão num documento. Ou, o que acho melhor, pode simplesmente não ser feito nenhum documento. — Por que não, simplesmente, criar tickets e colocá-los num kanban de tarefas?

    Acredito que as organizações (entenda-se: as pessoas que compõem as organizações) ainda têm o pensamento cartesiano, linear, hierárquico. Por isso esperam que o Scrum Master assuma o papel de "chefe", uma vez que ele é o líder, e responda pelo time junto à alta gestão. Da mesma forma, o time espera que o Scrum Master cuide das "burocracias", livrando-os da necessidade de executar qualquer tarefa que não seja diretamente o desenvolvimento do projeto/produto. Por isso empurram para o SM atividades como preenchimento de planilhas de controle, de "atas" de reunião, lançamento de dados em sistemas etc.

    Ser a interface entre o time e os stakeholders significa que o Scrum Master pode representar o time nas reuniões com a Diretoria, para evitar que o desenvolvimento do projeto/produto pare por causa da reunião. E isso não dá ao SM o poder de tomar quaisquer decisões pelo time nem aos Diretores o direito de cobrar ao SM pelo que o time fez ou deixou de fazer. Nesta situação, o papel do SM se assemelha mais ao de um porta-voz do que ao de um gerente.

    Ser o facilitador significa que o Scrum Master deve ajudar o time a entender seus objetivos, se autoconhecer e se auto-organizar. E isso inclui a condução de eventos e dinâmicas, a mediação de discussões e debates e a condensação das ideias em acordos ou planejamentos. Em nenhum momento isso obriga o SM a ser o "anotador oficial" do time. Nesta situação, o papel do SM é o de mediador, não o de secretário.

    Como você já deve ter visto várias vezes: Scrum Master não é Chefe, Scrum Master não é Gerente, Scrum Master não é Secretário e — essa é nova! — Scrum Master não é Burocrata.

    terça-feira, 27 de outubro de 2020

    A fábula do bacon com ovos

     

       Conheço poucas coisas que gerem tantos mal-entendidos sobre agilidade quanto essa famosa fábula. A ideia de intensificar o significado do comprometimento é ótima, mas a visão passada não apenas não corresponde à realidade como ainda contraria alguns princípios dos times ágeis.

       Para quem não conhece, ou não se lembra, a fábula do bacon com ovos (em uma de suas várias versões) narra a história da criação de um restaurante que teria como prato principal: Bacon com Ovos. Os proprietários seriam um porco e uma galinha.

       O porco acaba entendendo que a parceria não daria certo porque ele estaria comprometido (dando a própria vida para produzir o bacon) enquanto a galinha estaria apenas envolvida (simplesmente pondo ovos).

       O grande problema gerado por essa fábula é que muitas pessoas levam o comprometimento do porco ao pé-da-letra e acham que trabalhar num time ágil significa dedicar toda a sua vida ao time.

       Na prática, se o porco desse a própria vida para produzir o bacon, o restaurante fecharia, visto que perdeu seu fundador e fornecedor de matéria-prima no primeiro dia de funcionamento.

       A cada dia a galinha precisaria encontrar um novo sócio disposto a morrer por um negócio do qual não tiraria nenhum proveito. O porco nem sequer saberia se os clientes gostaram do prato servido, nem receberia nenhum lucro; estaria morto antes da entrega.

       Quando falamos em times ágeis, pensamos em times preocupados com a satisfação contínua do cliente ao longo das iterações e isso requer que os membros estejam vivos.

       As práticas de gestão de pessoas aplicadas a times ágeis partem da valorização e do respeito às pessoas. Pedir que alguém se sacrifique por uma entrega, definitivamente, não é uma forma de valorizar nem de demonstrar respeito.

       O comprometimento de uma pessoa com o time inclui o comprometimento com sua própria integridade física e mental.

       Outra versão desta fábula narra que um fazendeiro determinou a seus animais, uma galinha e um porco, que preparassem, a cada dia, um saboroso e diferenciado café da manhã. Caso falhassem, o café seria Bacon com Ovos.

       O porco se empenha e se esforça ao máximo para providenciar o café da manhã que seu proprietário pediu, enquanto a galinha faz “corpo mole” e apenas observa o porco trabalhar.

       No final da fábula, o porco não consegue entregar uma refeição satisfatória e o fazendeiro ordena que seus empregados matem o porco para fazer bacon e peguem os ovos da galinha.

       Isso também não retrata nenhuma realidade de times ágeis, nem de times tradicionais. Retrata apenas o ciclo de vida da má gestão, que termina com a punição dos inocentes e a promoção dos não envolvidos.

       E eu vejo “agilistas” perguntando a seus times se são porcos ou galinhas; se estão comprometidos ou envolvidos... sem se dar conta de que esta ideia de dar a vida pelo projeto/produto é altamente tóxica e prejudicial. Sem perceber que este “comprometimento” viola os princípios da boa gestão de pessoas.

       Não estimule seu Dev Team a morrer, estimule-o a permanecer vivo e saudável. Pessoas doentes e exaustas não entregam valor, pessoas saudáveis e felizes produzem mais e melhor.

    segunda-feira, 19 de outubro de 2020

    Você desenvolve Projetos ou Produtos?

       Lendo o artigo Why Agile Transformation sometimes fail da Magdalena Firlit, especialmente no tópico Project-oriented organization (instead of a product), lembrei de uma situação ocorrida comigo há alguns anos.

       Eu gerenciava um projeto de desenvolvimento de um software para apoio ao Centro de Controle Operacional de um cliente. O CCO era uma sala onde ficavam dezenas de operadores e dezenas de computadores, monitores de vídeo, TVs e painéis, de onde eram comandadas operações da empresa.

       Naquele projeto nós não utilizávamos MVPs, mas a sua versão "raiz", conhecida como PoC (Prova de Conceito — sigla em inglês). E, ao final de cada PoC, realizávamos uma reunião de avaliação e definição da próxima fase. Eis que, numa destas reuniões, um analista percebe que mais de 80% do trabalho realizado pelas dezenas de operadores era mecânico e automatizável por software.

       Imediatamente chamei o Diretor para a reunião e o analista lhe deu a notícia:

    _ Conseguimos uma solução que vai acabar com o CCO do cliente!

       O Diretor ficou vermelho...

    _ Ele pode ficar só com 20% daquela estrutura toda. Aquilo é tudo desperdício de dinheiro! 80% do trabalho deles o nosso sistema vai fazer. Se ele quiser, nem precisa mais ter um CCO.

       O Diretor respirou fundo e, após se recuperar da taquicardia, respondeu:

    _ Se é isso que você pensa, e ninguém aqui se manifestou contra, vamos encerrar esse projeto agora mesmo, porque vocês estão jogando meu dinheiro fora. Esse projeto tem um objetivo só: implantar o CCO do cliente do jeito que ele imaginou. E eu não vejo ninguém aqui defendendo isso, que é o mais importante.

       O Diretor enxergou aquele insight como uma ofensa aos objetivos do projeto, sem perceber que aquilo seria o grande diferencial do produto. Será que o cliente não gostaria de saber que poderia reduzir a estrutura planejada em 80% e obter o mesmo resultado? Nunca saberemos a resposta.

       Desta forma, a limitação de escopo do projeto matou o empirismo, a criação, a disrupção, a inovação, o time e o próprio projeto. Sei que 4 dos 7 membros da equipe original do projeto (incluindo eu e aquele analista) saíram da empresa nos meses seguintes e, pelo que ouvi falar, o projeto foi cancelado.

    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, ...