Quatro Métricas Essenciais para Melhorar o Seu Processo Ágil – Parte 2: Trabalho em Progresso

É seis horas da tarde. Você pega o seu carro e precisa chegar do outro lado da cidade para uma visita a um casal de amigos. Mas o trânsito está carregado. Você não se move. E os carros a sua volta também não. Você demora quase uma hora chegar no seu destino. Não é muito agradável, certo?

Outra cena. Você vai até a sua sorveteria preferida para combater o calor infernal do verão brasileiro. Mas ao chegar lá você se depara com uma fila com 20 pessoas. Você já sabe, de antemão, que você demorará a ser atendido, a receber o seu sorvete e para piorar irá demorar para pagar a sua conta. Novamente, nada agradável.

Carros, Sorvetes e Demandas de Produto

O mais curioso é que essas cenas tem uma grande relação com métodos ágeis e o seu trabalho como Scrum Master ou Agile Coach.

A quantidade de carros em uma avenida ou a quantidade de pessoas em um sorveteria é, na perspectiva apropriada, o trabalho em progresso. E, por sabedoria, você já sabe que um trabalho em progresso alto implica em:

  • Tempo de atendimento alto (você fica muito tempo dentro do seu carro, você fica muito tempo na fila da sorveteria)
  • Vazão baixa (A avenida está congestionada e poucos carros fluem por minuto; A Sorveteria está abarrotada, os pedidos se acumulam e a fila não flui).

Essa relação entre trabalho em progresso, vazão e tempo de atendimento é bem conhecida. Ela foi sistematizada ainda nos 60 por John Little e é muito conhecida na engenharia da produção como Lei de Little. Na área do conhecimento e para o uso com o método Kanban, Scrum e outros métodos ágeis, podemos escrevê-la da seguinte forma – uma relação entre valores médios.

O termo WIP vem do inglês e significa Work In Progress ou Trabalho em Progresso.

Estamos dizendo que o tempo médio de entrega é uma relação entre o trabalho em progresso médio e a taxa média de entrega do seu sistema.

Em termos super simples, entenda que essa relação lhe diz que se você não controlar o seu WIP, o tempo médio de entrega das suas demandas será muito alto. E, além disso, a sua taxa de entrega (ou vazão) será muito baixa.

Monitorar o Trabalho em Progresso – A Alavanca de Arquimedes

Um italiano bastante astuto, chamado Arquimedes, disse uma vez: me uma alavanca e um ponto de apoio e levantarei o mundo. A monitoração do WIP é a nossa alavanca aqui. Vamos mover o mundo.

Se você monitorar o trabalho em progresso durante o fluxo do seu trabalho, você terá os seguintes benefícios:

  1. Compreender se o time está sobrecarregado.
    Se, por exemplo, você é um Scrum Master em um time com 5 pessoas e observa que o seu WIP está em 70 demandas (exemplo real de um time que observei em 2020), você já percebe que existe um desequilíbrio entre os compromissos assumidos e a capacidade do time.

    Um time sobrecarregado é um sinal claro de um serviço de baixa maturidade (ML0), frágil e com trabalho não sustentável ao longo do tempo.
  2. Observar se WIP está crescendo ou reduzindo indicará se o seu sistema está ficando sobrecarregado ou ocioso.
    Um aumento abrupto no WIP, por exemplo, pode indicar que um enxurrada de trabalho empurrado chegou para o time e que isso pode violar a capacidade do time. O efeito prático será um aumento no tempo de resposta e e redução da vazão.
  3. Observar se as políticas de Limite de WIP estão sendo respeitadas ou não.
    Se você é iniciado em Kanban, sabe que nesse método nós impomos limites ao WIP. Essa é uma política usada para transformar o seu sistema de empurrado para puxado, reduzir a sobrecarga dos trabalhadores e equilibrar a demanda com a capacidade.

    Quando um Agile Master ou um Coach Kanban negocia um limite de WIP com o time, esse limite não irá mudar o comportamento dos clientes internos da noite para o dia. Não é incomum termos violações a esses limites e por isso se torna crucial monitorar o WIP do seu sistema de trabalho.
  4. Compreender se o WIP está balanceado

    Vimos anteriormente que o WIP está ligado ao tempo de entrega. Quanto maior o WIP médio do seu sistema, maior o tempo médio de entrega. E quanto maior o WIP médio, menor a vazão do seu sistema.

    Se o seu sistema de trabalho flui abaixo do esperado e o seu tempo médio de entrega das suas demandas é muito alto, vale observar se não temos um WIP desequilibrado para o seu time ou serviço.
  5. Observar os itens envelhecidos nas reuniões diárias

Quando olhamos para o tempo de entrega das demandas, estamos observamos para um fato passado. Mas se você olha para as demandas em andamento durante o seu sprint ou fluxo contínuo, você irá observar o presente e pode então criar foco nos itens que estão ficando “velhos”.

Um exemplo de um gráfico que considero muito útil nesse sentido é o gráfico de envelhecimento de demandas. Um exemplo é mostrado abaixo.

Esse é um time de marketing com 2 pessoas. Vemos que o WIP instantâneo é 9 e que o WIP no mês de Dezembro variou para cima. O gráfico mostra as 9 demandas que estão em andamento e sinaliza na área vermelha as demandas que estão ficando “velhas”.

Uma demanda pode ser chamada de velha se ela excedeu a mediana no histograma de tempo de ciclo de demandas. E se essa frase ficou confusa, eu explico isso aqui no primeiro artigo dessa série aqui:
Quatro Métricas Essenciais para Melhorar o seu Processo Ágil – (1) Tempo de Entrega

6. Observar se estamos operando em um sistema de trabalho de alta maturidade com o uso do CONWIP

Sistemas de trabalho de alta maturidade tem um WIP estável através uma técnica chamada CONWIP. O CONWIP significa que temos um WIP constante no nosso sistema de trabalho. Por exemplo, se temos um time com 5 pessoas e um CONWIP de 15, nós iremos garantir por desenho e operação que sempre teremos 15 demandas em progresso. A consequência do CONWIP é a seguinte:

  • Toda vez que uma demanda é entregue reabastecemos o sistema de trabalho. O reabastecimento ocorre sob demanda.
  • Uma nova demanda somente pode ser puxada quando uma demanda for entregue (jogo soma zero).

Manter o WIP operando de forma constante tem efeitos incríveis na previsibilidade do tempo de entrega e também na previsibilidade da vazão.


Em resumo. A gestão do WIP é uma força motriz poderosa de serviços aptos para o propósito. Como um agilista, você pode compreender o WIP e usá-lo a seu favor para reduzir o tempo de entrega, aumentar a vazão, alcançar o equilíbrio entre demanda e capacidade e criar agilidade real na sua organização.

Quatro Métricas Essenciais para Melhorar seu Processo Ágil – Tempo de Entrega

Você está com fome e decide pedir uma pizza. Você abre seu App de pedidos e escolhe a sua pizzaria favorita. Depois de selecionar a sua pizza, você efetiva o seu pedido. O relógio marca 19:30 e você e sua família estão com fome. Independente do sabor e da qualidade da sua pizza, eu tenho certeza que você irá monitorar o tempo de entrega. E se o tempo de entrega exceder a sua expectativa, você irá ficar ansioso, com mais fome, ficará mais ansioso e eventualmente irá até mesmo cancelar o seu pedido.

Observar o tempo de entrega é perfeitamente natural na perspectiva do cliente. Trabalhe você com produtos digitais, varejo, TI ou qualquer área de serviços profissionais, o tempo de entrega é uma das principais métricas que qualquer cliente irá monitorar, de forma objetiva ou subjetiva baseada em expectativas de atendimento daquele serviço (SLE – Service Level Expectation).

O Tempo de Entrega Não é um Número

Mas, espere. O tempo de entrega não é um número. Ele é um animal bem diferente e compreender isso te dará uma perspectiva completamente diferente sobre o trabalho que você coordena como PO, Scrum Master ou Gerente de Projeto.

Você decide rever os tempos de entrega da sua pizzaria favorita ao longo de todo o ano de 2020. Você examina o seu histórico e observa que você fez 15 pedidos. Cada um desses pedidos tem um tempo de entrega. Depois de organizar a informação você tem uma tabela similar a abaixo.

Numero do PedidoTempo de Entrega (em Minutos)
#125
#230
#325
#440
#520
#625
#735
#830
#945
#1025
#1135
#1260
#1325
#1420
#1530

Podemos agora organizar essa informação de maneira gráfica da seguinte forma. Colocamos o tempo de resposta no eixo X e iremos empilhar o número de ocorrências que ocorreu em cada momento do tempo. Por exemplo, os pedidos #5 e #14 foram entregues em 20 minutos. E tivemos cinco pedidos (#1, #3, $6, #10 e #13) entregues em 25 minutos. O resultado é mostrado abaixo.

Você pode observar que o tempo de entrega é uma distribuição de números prováveis. Ele é de fato uma distribuição estatística. E observar essa distribuição te dará muita informação gerencial. Primeiro vamos realizar uma interpretação estatística básica dos números.

  1. O tempo de entrega mais comum é 25 minutos, com cinco ocorrências. Chamamos esse valor de Moda da distribuição.
  2. O tempo de 30 minutos divide, aproximadamente, metade dos pedidos com tempo abaixo e metade dos pedidos com tempo acima. Ela é chamado de Mediana da distribuição.
  3. Cerca de 90% dos pedidos foram entregues em até 40 minutos. Chamamos esse valor de percentil 90 da nossa distribuição.
  4. A entrega os seus pedidos varia entre 20 e 60 minutos. Essa é a variabilidade de entrega dos seus pedidos.

O Tempo de Entrega Mostra a Maturidade do seu Serviço

Vamos nos mover agora para dentro da Pizzaria. Se você é o Agile Master da Pizzaria, esse simples gráfico (que chamamos tecnicamente de histograma) lhe dará poderosas interpretações gerenciais. Vamos a ela.

  1. Você pode responder as perguntas sobre o tempo de entrega dos seus pedidos.

    Se um próximo cliente confirma um novo pedido as 20:00, você pode usar o percentil 90 para estabelecer uma expectativa de nível de entrega (SLE). Nesse caso, você pode dizer que em até 20:40 a pizza estará entregue na casa do seu cliente. Você não precisará mais recorrer a técnicas esotéricas como fase da lua, tamanho de camisa ou planning poker.

    Dica: O tempo de entrega da próxima entrega pode ser previsto com o percentil 90% do seu histograma.

2. Você pode analisar se a sua pizzaria entrega de forma consistente

A variabilidade do tempo de entrega mostra o quão consistente você é dentro do processo de trabalho. Se o seu processo apresenta uma cauda muito protuberante você está gerindo um serviço de baixa maturidade (ML0 ou ML1). Um truque simples para isso é dividir o seu percentil 98 pela mediana. Se o valor for menor que 6, é bastante provável que o seu processo tenha uma cauda fina.

No nosso exemplo acima, a razão p98/mediana é 2, que indica que estamos lidando com um processo de cauda fina. Isso indica um serviço de maturidade mais alta (ML2, ML3 ou acima).

Dica: Quanto mais acentuada é a cauda, menos maduro é o seu processo. Use a razão entre o percentil 99 e a mediana para determinar a maturidade do seu serviço que você está gerindo.

3. Você pode monitorar os pedidos que estão ficando “velhos”.

A mediana é um sinal de alarme gerencial importante para você como gestor do seu time. Como ela divide metade das demandas acima e abaixo, valores que excedam a mediana começam a puxar a cauda para a direita. No nosso exemplo, a mediana da distribuição é de 30 minutos. E então todo pedido cujo tempo esteja excedendo 30 minutos requer atenção gerencial. Ele é uma demanda que está ficando velha e irá começar a puxar a cauda da sua distribuição para a direita.

Dica: Use as suas reuniões diárias para monitorar os itens velhos. Use a mediana para determinar o que é “velho” no seu sistema de trabalho..

Compreensão Profunda do Tempo de Entrega – Um Caso Real

 Um exemplo real é mostrado abaixo para um time de desenvolvimento de software. Observe que poderia fazer a mesma análise para um time de RH, Marketing ou de Contabilidade.

Para referência, compilo os principais números aqui:
Moda = 1 dias
Mediana = 5 dias
Percentil 85 = 13 dias
Percentil 98 = 57 dias

Apenas com essas informações, eu consigo responder três questões cruciais.

  1. Qual o tempo de entrega da próxima demanda?
  2. Que demandas devo monitorar de mais perto no seu quadro Kanban?
  3. Estou operando um time de baixa ou alta maturidade?

Resposta 1. O nosso gráfico mostra que podemos estabelecer um SLE para o tempo de entrega do próximo pedido de até 13 dias. Temos uma confiança de 85% para essa previsão.

Na prática, podemos usar valores entre 80 a 99% para estabelecer níveis de confiança de previsão. Você usará valores mais conservadores (percentis mais altos) se você tem clientes ou chefes mais intolerantes com atrasos.

Resposta 2. Toda demanda que estiver no nosso quadro Kanban há mais de 7 dias (mediana) está ficando excessivamente velha. Uma dica de uma técnica que já usei para lidar isso é introduzir uma política que mude a classe de serviço daquela demanda. O efeito prático é o que time precisará focar naquela demanda.

Resposta 3. Esse serviço tem baixa maturidade. Se você dividir o percentil 98 pela mediana terá um valor aproximadamente de 11,4 (57 dias/ 5 dias). Isso indica que estamos lidando com um serviço de baixa maturidade (ML0 ou ML1).

E como aumentar a maturidade de um serviço?

A compreensão profunda do tempo de entrega – não como um número – mas como uma distribuição estatística é uma arma poderosa para Scrum Masters ou Agile Masters compreenderem a maturidade dos seus times, o tempo típico de entrega de demandas e a sua dispersão.

Uma ampla variedade de tempos de entrega indica que o seu tempo de ciclo varia significativamente e seu processo é inconsistente. A isso chamamos de cauda. Se a cauda é longa, então o nosso processo ágil ainda possui baixa maturidade.

Causas comuns para caudas incluem:

  • Tarefas paradas em filas
  • Dívidas de fluxo
  • Dívidas técnicas em sistemas de informação
  • Bloqueios
  • Impedimentos
  • Sobrecarga de trabalho
  • Retrabalho
  • Itens que envelhecem dentro de um sistema

Como Scrum Master, você precisa trabalhar ativamente para aparar a cauda. Afinal, caudas longas são ruins.

Nos próximos artigos dessa série irei lhe mostrar três outras métricas para você avaliar os seus esforços de aumento de maturidade no seu time. Elas são:

  • Trabalho em progresso (ou WIP)
  • Eficiência de fluxo
  • Taxa de entrega (Vazão de Entregas)

Gestão do Upstream – A arma de destruição em massa dos POs e Scrum Masters

Muitas implementações Scrum sofrem de problemas crônicos tais como:

  • Alto retrabalho nas demandas comprometidas.
  • Trabalho empurrado
  • Demanda e capacidade de entrega desequilibradas.
  • Reuniões de planejamento de sprint longas, cansativas e improdutivas.
  • Metas frustradas nos finais da sprint.
  • Baixa eficácia (muito trabalho e pouco valor de negócio)
  • Usuários insatisfeitos.

Esses e outros problemas muitas vezes tem origem antes mesmo que um Sprint se inicie. Como as falhas são sistêmicas e estão defasadas no tempo e no espaço, as retrospectivas muitas vezes não conseguem capturar com precisão a origem do problemas e fazer intervenções de melhorias precisas. As vezes precisamos olhar rio acima (upstream) ante que a agua do downstream (rio abaixo) esteja poluída.

Afinal, não há nada tão inútil como fazer com eficiência algo que não deveria ter sido feito.

Vamos conhecer uma arma poderosa para que você, Scrum Master ou PO, possa atacar esses problemas comuns nos seus serviços, times e projetos – A Gestão de Upstream.

Quadros de Entrega (Downstream)

Times ágeis usam quadros Kanban para organizar a sua entrega do trabalho.Não é incomum que se pareçam com o desenho abaixo.

Um típico quadro kanban usado por times Scrum

Normalmente a coluna Backlog é usada como repositório dos pedidos que devem ser trabalhados. O problema é que o BACKLOG é apenas isso (um repositório). Nele habitam toda tipo de fauna (demandas do tamanho de elefantes, demandas com armadilhas que lembram porco-espinhos, muitas demandas de valor de negócio minúsculo como formigas. E, para piorar, a palavra BACKLOG está associado como obrigação de entrega. O trabalho é empurrado, tenha o tipo capacidade de entrega, esteja ou não a demanda avaliada na perspectiva de negócio, esteja ou não pronta para a execução.

O quadro à esquerda do quadro de entrega O Quadro de upstream

Vamos melhorar o nosso sistema Kanban, conforme figura abaixo.

Essa figura apresenta duas melhorias.

  1. Um ponto de compromisso. Toda e qualquer demanda que esteja à esquerda do ponto de compromisso ainda não está na agenda de sprints do time. Ela ainda não é um compromisso.
  2. O quadro de qualificação das demandas à esquerda. Esse quadro tem por objetivo preparar as demandas para que elas sejam qualificadas conforme seu valor de negócio, refinadas e então sequenciadas para serem puxadas pelo time de entrega.

O quadro de upstream é trabalhado continuamente por todas as pessoas na sua empresa que são clientes do time que cuida do quadro de entrega. Se você tem um Product Owner, ele talvez tenha a função central de garantir que os itens fluam por esse quadro, mas ele não deve trabalhar sozinho nele. Isso seria um erro.

Gestão de Upstream – Muito mais que um quadro

Um quadro de upstream é apenas isso – um quadro, um desenho estático. A gestão de upstream, por sua vez, é um conjunto de processos que operam sobre esse quadro. Queremos criar um sistema Kanban aqui.

Vamos examinar a figura abaixo.

Aqui vemos que os processos de qualificação devem envolver políticas diversas. As políticas são particulares a cada serviço nas organizações, mas devem ser suficientes para garantir que tenhamos toda a informação necessária que o time possa puxar o cartão.

Um exemplo real de um time de TI onde implementei essa técnica gerou o seguinte conjunto de políticas

  • Análise do valor de negócio (feita pelo PO)
  • Determinação da classe de serviço. (feita pelo PO). A classe de serviço ajuda a sequenciar demandas, separando aquelas que precisam ser feitas agora (urgente), que possuem data fixa e também as demandas padrão.
  • Análise arquitetural (realizada pelo arquiteto de software do time)
  • Protótipo de alta fidelidade (feita pelo time de UX)
  • Compreensão das regras de negócio e impactos nos sistemas existentes (realizado pelo analista de negócio).

A ultima coluna do quadro de upstream é a coluna Pronto para Iniciar a Entrega. Aqui somente chegam as demandas que sobreviveram aos processos de análise de valor e refinamento. Elas são seguras e podemos começar a trabalhar nelas assim que tivermos capacidade para fazê-lo.

Gestão de Upstream como Funil de Demandas

O papel da gestão de upstream também e entregar opções na vazão correta para o downstream. Similar a um rio, não queremos inundar os terrenos mais abaixo. Mas também não queremos deixar o time sofre de inanição de demandas. E isso nos leva um desenho similar ao abaixo.

Veja no quadro de entrega que limitamos a capacidade máxima de cada estágio de conhecimento. Esses limites, conhecidos como limite de WIP, dizem o máximo de demandas que podem estar fluindo em cada estágio de conhecimento. Como no nosso exemplo definimos os limites para 5 nas três colunas, o limite total para o time é de até 15 demandas em paralelo.

O quadro mais à esquerda agora é modelado com o limite do primeiro estágio de conhecimento do quadro de entrega em mente (até 5 demandas em análise). Podemos receber infinitas demandas no estágio de ideias, mas vamos colocando limites mínimos e máximos de WIP em cada coluna do upstream. No exemplo acima, a coluna Pronto para Iniciar a Demanda tem pelo menos 5 demandas prontas para iniciar. Dessa forma, o time não irá morrer de inanição. Mas também vamos colocar limite máximo aqui. No exemplo, 10. Dessa forma, evitamos trabalho especulativo excessivo. Mantemos um estoque balanceado sempre.

Gestão de Upstream como Descarte de Opções Inválidas

Quando começamos a gerir o upstream, precisamos introduzir uma prática muito saudável que é o descarte ativo de opções de baixo valor ou que ainda não estejam prontas para fluir. Essa mortalidade infantil aqui é bem vinda. Queremos preservar o time de entrega mais abaixo de descobrir, como acontece muito, que a demanda não faz sentido ou que a urgência do cliente era muito mais desconfiança na entrega que qualquer outra coisa.

Empresas de alta maturidade Kanban, como por exemplo a Microsoft, tem casos documentados de uma mortalidade de demandas de cerca de 50%. Sim, 50%! Se você como PO, não tem ainda um processo ativo de qualificação e descarte de demandas, então o seu trabalho é apenas tirar pedidos.

Uma representação visual é fornecida aqui com o cantinho de descarte.

Gestão de Upstream – Uma Arma de Destruição em Massa

Vamos rever as dores que te apresentei mais acima e como a Gestão de Upstream pode contribuir.

  1. Alto retrabalho nas demandas comprometidas.
    As políticas de preparação de demandas reduzem os retrabalhos mais comuns que acontecem por ausência de informações ou ausência de identificação de dependências de outras áreas.
  2. Trabalho empurrado
    O ponto de compromisso separa o trabalho comprometido do trabalho em preparação. Nenhuma demanda nasce no quadro de entrega. As demandas nascem no quadro de descoberta e fluem na velocidade das suas classes de serviço e políticas.
  3. Demanda e capacidade de entrega desequilibradas.
    Os limites de WIP no quadro de entrega e no quadro de descoberta garantem que o time sempre estará bem abastecido, mas nunca afogado.
  4. Reuniões de planejamento de sprint longas, cansativas e improdutivas.
    Como as demandas plenamente qualificadas e limites claros na coluna de análise você pode fazer a sua reunião de planejamento com extrema velocidade.
  5. Metas frustradas nos finais da sprint.
    Os problemas de qualificação de demandas são atacados e o time recebe um pacote de demandas equilibrado para as suas sprints.
  6. Baixa eficácia (muito trabalho e pouco valor de negócio)
    O upstream faz análise de retorno sobre o investimento ou valor para o negócio. Ele é um instrumento e eficácia. Queremos que o time faça as coisas certas.
  7. Usuários insatisfeitos.
    Com todos os problemas acima atacado, você tem uma chance muito maior de atender a satisfação dos seus usuários.

Como começar a Gestão de Upstream no Meu Time

A minha dica aqui é. Comece de onde você está. Introduza os conceitos acima explicados aos poucos com pequenos experimentos seguros para falhar. Melhore colaborativamente e evolua experimentalmente. Esse é o caminho Kanban.

Felizmente, também existe já vasta literatura sobre gestão de upstream. O Kanban Maturity Model traz o Upstream Kanban como uma prática de nível 2. E o clássico livro Essential Upstream Kanban, Patrick Steyaert, é também uma leitura bem legal para fundamentar conceitos e aprender mais.

E você. Já usa essa arma de destruição em massa?

Efficiency is doing the thing right. Effectiveness is doing the right thing.” ― Peter F. Drucker

Negociando a implantação de métodos ágeis com o Capitão Kirk e o Mr. Spock

Jornada nas Estrelas foi uma série fora do seu tempo. Lançada no meio dos anos 60, essa série discutia guerra e paz, lealdade, autoritarismo, imperialismo, economia, racismo, existencialismo, metafísica, religião, direitos humanos, sexismo, feminismo e o papel da tecnologia. E tudo isso contado de forma leve e épica dentro do propósito da frota estelar de “audaciosamente ir onde nenhum homem jamais esteve”.

Esse série apresentava dois icônicos personagens, o capitão da nave James Tiberius Kirk e seu oficial Spock (o segundo em comando).

Kirk é passional, emotivo, intuitivo e com uma incrível facilidade para improvisar. Já Spock, filho de mãe terráquea e pai Vulcano, é racional, analítico, dedutivo e busca sempre ponderar e analisar todas as possibilidades antes de tomar as suas decisões.

Na série, eles tem diálogos que mostram suas naturezas distintas tais como:

– “Algumas coisas são impossíveis até o momento onde elas não são mais”, James. T. Kirk

– “Isso é altamente ilógico”, Spock

Para alguns fãs de ficção científica, Star Trek foi maior e mais importante que Star Wars. Mas não vamos iniciar uma guerra interplanetária aqui.

O Cérebro Humano – Spock e Kirk Juntos

Durante séculos, filósofos, psicólogos e cientistas distinguiram entre raciocínio intuitivo e o consciente. Platão, por exemplo, já falava em seu livro Psyche entre o nosso cérebro consciente (Logos), do nosso cérebro emocional – aquele dos desejos e apetite (Eros) e do afeto (Thymos).

Mais recentemente, Daniel Kahneman criou os termos sistema 1 e sistema 2 em livro “Rápido e Devagar”, que popularizou a distinção entre processos de pensamento automáticos e deliberados. O modelo de Kahneman divide os processos da mente em dois sistemas distintos:

O sistema 1 “é a abordagem rápida, automática e intuitiva do cérebro”, que apelido aqui de modo Capitão Kirk. A atividade do sistema 1 inclui as atividades mentais inatas com as quais nascemos, como uma preparação para perceber o mundo ao nosso redor, reconhecer objetos, orientar a atenção, evitar perdas. Outras atividades mentais tornam-se rápidas e automáticas através da prática prolongada.

O sistema 2 é “o modo analítico mais lento da mente, onde a razão domina”, que chamo aqui de modo Spock. Geralmente, a atividade do sistema 2 é ativada quando fazemos algo que não ocorre naturalmente e requer algum tipo de esforço mental consciente.

Daniel Kahneman fornece um exemplo comum usado para demonstrar os dois sistemas. Um taco e uma bola juntos custam US$ 1,10. O taco custa US $ 1 a mais que a bola. Quanto custa a bola? Diante desse quebra-cabeça, a maioria das pessoas adivinha instantaneamente 10 centavos. A resposta correta, no entanto, é de 5 centavos – o que, novamente, a maioria das pessoas pode resolver depois de passar mais tempo pensando sobre a questão.

Minimizando a resistência a mudanças

Quando buscamos implantar métodos ágeis, temos que ter atenção extrema às respostas dos outros. Peter Senge, exímio pensador sistêmico, já falava:

“As pessoas não resistem às mudanças. As pessoas resistem a serem mudadas”.

Ao reconhecer uma mudança, as pessoas podem trazer objeções no modo Kirk (Sistema Tipo 1 em ação) ou no modo Spock (Sistema Tipo 2 em ação).

O primeiro modo são receios emocionais tais como:

  • Dignidade
  • Respeito
  • Status
  • Identidade
  • Desejos
  • Confiança
  • Orgulho

O segundo modo está ligado a receios de natureza intelectual e aspectos que desafiam o seu modo de pensar. Busque reconhecer as objeções as mudanças quando você se depara como uma resistência.

David Anderson, líder da comunidade Kanban, nos apresenta as duas regras de ouro para lidar com objeções.

  1. Nunca combata uma objeção racional com um argumento emocional.
  2. Nunca combata uma objeção emocional com um argumento racional.

Trabalhar a primeira regra é menos complexo. Se você enfrenta objeções racionais, você pode desenvolver argumentos, trazer fatos e dados para criar um debate. O Spock que habita o cérebro racional da pessoa eventualmente fará as conexões.

A notícia ruim é que na grande maioria das vezes as objeções são emocionais. E enfrentar o capitão James T. Kirk não é tarefa simples. Se você enfrenta uma objeção emocional, você precisa trazer uma emoção ainda mais forte para lidar com a resistência. Emoções mais fortes podem ser aquelas que irão gerar neurotransmissores positivos como dopamina, oxitocina, serotonina e endorfinas ou mecanismos de urgência gerados por descargas de adrenalina e cortisol.

Cito aqui um caso extremo onde pude observar que um gerente de projeto que não aceitou uma mudança de papel para um novo papel de Scrum Master. Se uma mudança de papel afeta a dignidade ou identidade de um funcionário e ele resiste, uma ação que gera uma emoção mais forte (embora negativa) seria uma ameaça de demissão. E foi isso que o diretor fez. Ele ameaçou o gerente de projeto e disse que a mudança era mandatória. O medo de não ter comida ou casa é mais forte (gera adrenalina e cortisol) e sobrepuja o receio da sua mudança de identidade.

Não queremos, óbvio, fazer a mudança pelo medo. Até porque agile coaches não são, normalmente, ou donos das organizações. E mudanças baseadas em medos podem gerar efeitos colaterais muito ruins. Encontrar uma emoção mais forte pode ser difícil e demorado nesses casos, mas é o caminho para combater objeções emocionais. O método Kanban, por exemplo, não busca trabalhar reorganizações ou mudanças de papel na sua introdução pois esses tipos de mudanças estão mais suscetíveis a mudanças que ativem caminhos límbicos de pavor, medo ou perda da identidade.

Um exemplo positivo que pude observar em um time estava ligado a troca do trabalho empurrado para trabalho puxado em um time ágil. Havia uma cultura Scrum de assumir um lote de funcionalidades de uma única vez em uma reunião longa e demorada de Planejamento de Sprint. No final da reunião as funcionalidades já eram atribuídas aos desenvolvedores dessa organização. A gerente percebeu que esse modelo levava a falhas contínuas de entrega. As promessas eram continuamente quebradas. E isso minava a confiança dos diretores e clientes nesse time. Inicialmente a gerente tentou introduzir a mudança para um sistema puxado onde as demandas seriam trazidas uma por vez apenas quando houve capacidade disponível do time. Ao tentar propor a mudança, o time resistiu. Havia uma identidade muito forte ligada a papéis e práticas do Scrum.

Ela então buscou uma abordagem alternativa baseada em princípios Kanban. Primeiro, ela não atacou a identidade do time. Ela teve paciência. Durante algumas semanas ela melhorou a gestão à vista mostrando o trabalho em andamento, impedimentos e bloqueios. Ela também construiu métricas de fluxo como histogramas de tempo de ciclo e fluxos cumulativos de valor. Isso permitiu que as retrospectivas mudassem de momentos de pura lamentação para conversas mais ricas. A gerente também teve cuidado de apontar os problemas sobre o trabalho e não sobre os trabalhadores. A partir de conversas mais ricas e um ambiente seguro para falhar, o time desenvolveu uma base emocional mais sólida para lidar com os problemas de previsibilidade. Depois de poucos meses o time estava emocionalmente preparado para fazer a mudança de um trabalho empurrado para um trabalho puxado. E com o suporte de histogramas de tempo de ciclo o time agora era capaz de trabalhar previsibilidade sobre demandas novas para o seu sistema de trabalho.

Definitivamente, um caminho longo e duro. Mas é necessário quando um agente de mudança enfrenta objeções emocionais no seu caminho e queira criar mudanças consistentes e perenes.

A mensagem aqui é que criar uma cultura de agilidade de negócio é complexo. Não existem receitas de bolo. Ao mesmo tempo, existe hoje uma ampla base sociológica e de práticas de gestão para orientar agentes de mudanças ou agile coaches.

“Live long and prosper”, Mr. Spock.

Resiliência ou Morte

O evento da COVID-19 trouxe estressores fortes para toda a humanidade. E no meio empresarial ele provocou muitas demissões e até mesmo o fechamento de muitas empresas. O segmento de turismo e de aviação, por exemplo, foi brutalmente impactado.

Curioso, entretanto, é que fenômenos como a COVID-19 não são raros na história humana e também das organizações. Há exatamente 100 anos atrás os mesmos debates sobre isolamento social e uso de máscaras se formaram quando a gripe espanhola dizimou milhões de pessoas. Riscos e incertezas, com toda certeza, vão surgir nas próximas décadas com as mais diferentes formas. Sempre foi assim e sempre será assim.  

Quando olhamos para esses fenômenos, podemos classificá-los em três tipos.

Águas Vivas, Elefantes e Cisnes Negros

Uma água viva negra representa eventos ou fenômenos que tem o potencial de se tornarem pós-normais através de escala imensa e instantânea. As águas vivas negras são classificados como desconhecidos conhecidos (Unknowns knowns) — coisas que achamos que conhecemos e entendemos, mas que acabam por ser mais complexas e incertas do que esperamos. Enchentes, crises financeiras e acidentes trágicos são exemplos desses fenômenos.

Temos também um outro tipo de fenômeno chamado de elefantes negros. É um evento que é extremamente provável e amplamente previsto por especialistas, mas as pessoas tentam passá-lo como algo muito exótico (um tipo de Cisne Negro) quando finalmente acontece. Elefantes negros são classificados como conhecidos desconhecidos (Knowns unknowns). A COVID-19 por exemplo, é um tipo de fenômeno como esse. Epidemias e pandemias sempre ocorreram e são previstas por especialistas há décadas e se você fizer uma pesquisa rápida de pandemias na Internet você verá o quanto esse tipo de fenômeno é recorrente na história humana.

Finalmente, temos os cisnes negros, que podem ser negativos ou positivos. São eventos extremamente raros e tem três propriedades básicas.

  • O evento é imprevisível (para o observador)
  • O evento tem ramificações generalizadas
  • Depois que o evento ocorreu, as pessoas afirmam que foi realmente explicável e previsível (viés retrospectivo).

O ataque as torres gêmeas, o surgimento da Internet ou a dissolução da União Soviética são exemplos desse tipo de fenômeno. Esses eventos são chamados de desconhecidos desconhecidos (Unknowns unknowns).

Uma empresa que queira prosperar em tempos de incertezas precisa operar além da agilidade de negócio. Ela precisa ser ágil e também resiliente. A robustez é peça fundamental para você operar nas incertezas – os conhecidos desconhecidos; os desconhecidos conhecidos e os desconhecidos desconhecidos.

Um caso concreto é o das empresas Kodak e Fujifilm. Ambas as empresas faturavam 15 bilhões em 2000. A Kodak faliu e o caso é contato e recontado em prosas empresariais. Já empresa Fujifilm hoje fatura mais de 20 bilhões de reais porque desenvolveu um portifólio diversificado, criou robustez e soube lidar bem com o declínio dos filmes das câmeras analógicas.

Resiliência organizacional deve ser um valor cultural

Julian Birkinshaw, professor de empreendorismo da Business London School, classifica a resiliência organizacional em três níveis (Robustez estratégica, operacional e no nível pessoal).

  • Capacidade de resiliência estratégica da organização para monitorar e responder às mudanças no contexto e permanecer relevante para os clientes.
  • Capacidade de resiliência operacional para manter as operações principais funcionando, desde o fornecimento de produtos e serviços até o financiamento de negócios.
  • Capacidade de resiliência pessoal de funcionários e líderes individuais para suportar circunstâncias difíceis por longos períodos

A tese dele, mais relevante do que nunca, é que a resiliência deve ser um valor e também uma capacidade de negócio da sua organização. Valores definem a cultura. A cultura forma as práticas diárias. E as práticas apropriados para o contexto criam bons resultados de negócio.

Um mapa para a resiliência em organizações

Gosto muito da abordagem do KMM, um modelo de maturidade organizacional baseado no método Kanban. Ele possui princípios inspirados na teoria de antifragilidade de Taleb. Esses princípios permitem que você entenda a maturidade dos serviços de uma organização e introduza estressores apropriados para aquele nível de maturidade. Nem mais nem menos. E junto com mecanismos de reflexão periódicos e atos de liderança o modelo cria um mapa seguro para que serviços empresariais evoluam em uma jornada de fragilidade para a resiliência, robustez e antifragilidade.

O poster em tamanho grande pode ser baixado do sítio em http://www.kanbanmaturitymodel.com


A mensagem é clara. Empresas que querem sobreviver devem se parecer mais com camelos feiosos que sobrevivem em desertos do que com unicórnios fofinhos. Ser resiliente é uma condição essencial a toda organização em tempos pós-normais.

“Difficult to see. Always in motion is the future” , Master Yoda

As 10 práticas de agilidade mais populares do planeta em 2020

Métodos e frameworks ágeis como Scrum, Safe, LESS, DevOps ou Kanban não são atômicos. Eles são compostos por várias práticas de processo. Uma prática é uma estrutura pequena, uma parte do todo. E as partes organizadas em uma coleção ajudam a criar a essência e o comportamento do todo.

Entretanto, um método ágil não é apenas a soma de suas práticas constituintes. Quando examinamos partes e seus coletivos podemos ter arranjos muito interessantes.

  1. Por exemplo, podemos ter partes individualmente estúpidas e coletivos muito inteligentes. A epidemia do CoVid-19 é um exemplo de um organismo coletivo muito inteligente (e perverso) formado a partir de partes individuais estúpidas.
  2. Podemos ter também coletivos inteligentes formados por partes individualmente inteligentes. Por exemplo, uma matilha de orcas caçando um cardume de atuns é um exemplo desse arranjo.
  3. Um outro arranjo são coletivos poucos inteligentes formados por partes inteligentes, como uma carreata de pessoas, individualmente boas, defendendo uma ideologia política dogmática. O mesmo acontece em torcidas organizadas em estádios de garbo e elegância por todo o Brasil.
  4. Finalmente, temos também arranjos coletivos ruins formados por partes individualmente ruins. Se você já tentou fazer bom prato de comida com ingredientes ruins você entendeu a mensagem aqui.

Uma boa prática de processo não irá garantir um bom método (o nosso coletivo de práticas). Mas você não terá um bom método ágil com práticas pouco adaptadas na sua realidade prática. Ou seja, um ponto de partida ainda melhor que métodos quando pensamos em implantações ágeis é o conceito de práticas de processo. Práticas são recombináveis e podem ser experimentadas em virtualmente qualquer ambiente.  Práticas são seguras para falhas pois podem ser facilmente abandonadas se não se mostrarem viáveis.

E, principalmente, práticas são muito mais robustas do que grandes frameworks ágeis inerentes frágeis e que exigem pesados investimentos em treinamentos e reorganização de empresas.

As 10 Práticas de Agilidade Mais Populares em 2020

O Relatório do Estado da Agilidade publicou em 2020 as práticas ágeis mais adotadas por mais de 1100 entrevistados. Os resultados foram:

  1. Reunião Diária – 85% dos entrevistados.
  2. Retrospectivas – 81%
  3. Planejamento de Sprints – 79%
  4. Demonstrações/Revisão de Sprints – 77%
  5. Iterações Curtas – 64%
  6. Kanban – 63%
  7. Estimativas de Time – 60%
  8. Product Owner/Cliente Dedicado – 54%
  9. Planejamento de Releases – 51%
  10. Time integrado (Devs e Testers integrados) – 51%

Algumas interpretações a partir desses dados seguem abaixo.

1.As quatro primeiras práticas estão ligadas a cadências (ou ritos). Cadências formam um tipo de ciclo de feedback fundamental para que sistemas de trabalho possam ser melhorados em ambientes complexos. Muito vezes subestimadas ou tratados com desdém, devemos ter extrema atenção à execução dessas práticas.

Quando facilito essas cadências,  por exemplo, sempre uso um quadro Kanban (prática #6), com o uso da seguinte heurística: foco no trabalho e não nas pessoas. Para a retrospectiva, foco no trabalho entregue na coluna Terminado. Para a reunião diária, sempre pergunto ao quadro o trabalho que está em execução (Work In Progress). E para reuniões de reabastecimentos como o Planejamento de Sprints sempre olho para a coluna de histórias e pronto para iniciar.

2. A prática #5 está ligada a ciclos curtos, também propriedade fundamental de sistemas complexos adaptativos. Times ágeis normalmente trabalham com ciclos entre 1 a 4 semanas. Ciclos menores

3. A prática #6 está ligada a transparência, gestão à vista e gestão de riscos. Quadros Kanban também são um alicerce importante para observar sobrecarga e criar um ambiente de discussão para a introdução de políticas de melhoria.

4. A prática #7 mostra que quase dois terços do mercado ainda definem compromissos baseado em estimativas. É um sinal que existe muita oportunidade de avanço com o uso de elementos mais maduros e robustos que envolvem previsibilidade, métricas de fluxo e o movimento #noestimates. Tenho a esperança que essa prática não apareça mais aqui quando o mercado ganhar mais maturidade.

5. A prática #8 mostra que metade dos times já conseguem ter pontos focais dedicados para interagir com seus clientes. Isso é positivo em minha opinião pois mostra que a interface com áreas clientes está em franca melhoria.

6. A prática #9 exibe que metade dos times estabelecer planos de lançamento no mercado com produtos mínimos viáveis e entregas parciais. Me parece ser um passo de maturidade quando comparamos com abordagens de construção de elefantes em projetos que demoravam muitos anos.

7. Finalmente, a prática #10 mostra esforços de reorganização para a quebra de silos funcionais em metade das organizações. O uso de times multidisciplinares é sem dúvida um facilitador para times operarem e melhorar suas eficiências de fluxo. Vale apenas o ponto de atenção que não é uma receita de bolo que possa ser aplicada em qualquer contexto e não precisar estar no caminho obrigatório de qualquer implantação de agilidade.


Estudar e aplicar práticas é robusto. Quando você combina boas práticas em bons arranjos você poder criar, por emergência sistêmica,  um método muito mais poderoso que as práticas individuais.

 

Um sistema ruim sempre derrota pessoas boas

Brasil e Alemenha em 2014 - 7 x1

O dia era 8 de Julho, do ano de 2014. Era uma terça-feira com um céu azul e tempo agradável, como todo fim de outono em Belo Horizonte. Brasil e Alemanha iriam se enfrentar pela semifinal da copa do mundo. Nunca um jogo dessa magnitude havia acontecido na região das alterosas. E por todo o  Brasil havia uma grande expectativa da sua seleção estar em uma final de copa do mundo.

Só que não! A história, contada e recontada, você conhece bem. Não preciso repeti-la aqui.

Avancemos para o dia seguinte. Um vexame esportivo como nunca visto na história Brasileira. Jornais de todo o mundo destacam a excepcional vitória da Alemanha, nunca antes vista em uma semifinal.  E para o brasileiro comum, eu inclusive, restava erguer os dedos e apontar culpados. Afinal, é mais fácil culpar pessoas quando alguma coisa vai mal.

O mito dos heróis e vilões

Tendemos a supervalorizar o talento individual. Acreditamos que as maiores e piores coisas que acontecem são obras de pessoas; iluminadas ou amaldiçoadas. Fazemos isso o tempo todo, culpando aquele jogador, aquele político ou aquele colega de trabalho pelo insucesso das iniciativas que estamos observando ou participando.

Esse pensamento é ingênuo. Muito. E para piorar, somos programados a insistir nessa ingenuidade. Psicólogos já catalogaram esse viés, chamado de Viés de Atribuição. Esse viés cognitivo se refere aos erros sistemáticos cometidos quando as pessoas avaliam ou tentam encontrar razões para seus próprios comportamentos e os dos outros.

Se você corta alguém abruptamente no trânsito, você cria uma justificativa no seu cérebro. Estou atrasado para pegar meu filho na escola. Foi mal.

Mas se alguém faz o mesmo com você duas semanas depois, aquele sujeito é um babaca ignorante sem nenhum escrúpulo e educação. Ele merece morrer empalado em praça pública, sem sombra de dúvida.

O mito dos heróis e vilões nas empresas

Em muitas organizações, é inútil preocupar-se indevidamente com variações entre indivíduos. Tipicamente, a  cultura organizacional, políticas e a liderança tornam irrelevantes as diferenças entre indivíduos.

Por quê? Empresas não “criam” coisas pois elas são seres sencientes. Ao invés, empresas executam, competem e coordenam esforços de muitas pessoas. As empresas mais bem-sucedidas nestas tarefas são aquelas em que o sistema de trabalho é a estrela.

W. Edwards Deming já nos mostrava empiricamente na metade do século XX que a performance das instituições  é dirigida muito mais pelos sistemas de trabalho do que pelo talento individual.  Empresas são sistemas adaptativos complexos. E, em sistemas adaptativos complexos, os resultados são multifatoriais e não são óbvios. Se o fossem, todo empreendedor chefiaria uma Apple, Google ou Amazon nesse exato momento.

O que são sistemas de trabalho?

Vou trazer um relato de um caso que experienciei. Um trabalhador em uma organização era vilanizado por ser alguém que cometia muitos defeitos em suas tarefas. A área de qualidade dessa empresa o satanizava e discussões pesadas aconteciam com a área de engenharia por causa dessa pessoa.

A área de engenharia dessas organização trabalhava com políticas de remuneração variáveis. E essa pessoa, em particular, era premiada por cumprir tarefas no prazo; mesmo que a qualidade não fosse endereçada. Afinal, havia uma área de qualidade para “pegar” os defeitos. Com tais incentivos, ele se adaptou. E realmente o foco dele era apenas a velocidade de entrega das tarefas.

O efeito prático das políticas de otimização local do trabalho e da atribuição de problema para as pessoas contribuiu para que essa empresa tivesse tempos de resposta enormes para as demandas do time do tal garoto enxaqueca. Era um cenário destrutivo e todos perdiam. Um verdadeiro 7×1.

Quando um novo gestor entrou e começou a mudar as engrenagens do sistema (não as pessoas), as políticas foram mudadas e também os sistemas de incentivos. A cultura agora foi mudada de competição local para ganhos globais ou nada feito. Os incentivos financeiros valorizam de forma balanceada a velocidade e fatores de qualidade. Depois de alguns meses, a pessoa que era culpada por tantos defeitos passou a entrega tarefas com índices de qualidade excelente, na visão das outras áreas.

O que houve aqui? O sistema foi ajustado, gradativamente. E ajustes no sistema com políticas corretas ajudam a incentivar bons comportamentos. E bons comportamentos, repetidos em base diária, cultivam culturas de sucesso. E culturas de sucesso criam espaço para que oportunidades aleatórias catapultem organizações para o sucesso.

Como posso criar sistemas de trabalho na minha organização?

  1. Primeiro, combata a sua programação mental ingênua.Quando um erro grave acontecer, você vai querer a cabeça do infeliz que a cometeu. Em uma bandeja de prata. Esse é o seu modo lagarto em ação, tomando o controle mental do seu neocortex cerebral. Ao invés, pare e respire. Faça uma análise das fragilidades do seu sistema de trabalho. Se erros graves então acontecendo, o sistema de trabalho está frágil.Nada é verdadeiramente bom ou ruim, mas o pensamento faz com que o seja, já dizia William Shakespeare.
  2. Combata as fragilidades. E não as pessoas.Examine as políticas em curso, explícitas ou implícitas.  Examine a cultura e o efeito das políticas em curso no comportamento das pessoas. Finalmente, analise os sistemas de incentivos. Realize análises de causa raiz com instrumentos como o processo A3. E descubra com profundidade os fatos geradores dos comportamentos ruins que provocam erros danosos na sua organização.
  3. Mude o sistema de trabalho, um grão de area por dia. 

    Envolva as pessoas nas mudanças e busque atos de liderança. Em base  periódica, introduza mudanças evolucionárias na sua organização. Essas mudanças devem introduzir estressores de melhoria na sua organização e tornar os seus sistemas menos frágeis, resilientes, robustos e eventualmente anti-frágeis.Por exemplo, o Método Kanban possui um amplo catálogo de ideias de melhorias ligada a gestão visual, limitação do trabalho em progresso, políticas explícitas, gestão do fluxo, sistemas de feeback, entre outros. Somado a um mecanismo de mudanças evolucionárias e atos de liderança, ela pode ajudar você na mudança da sua organização para criar agilidade de negócio e mais robustez.Um outro exemplo é a cultura DevOps. Através de práticas evolucionárias de colaboração, automação, medição e gestão de fluxo, ela promove que empresas de TI possam reduzir tempos de entrega, melhorar feedbacks técnicos e promover mais experimentos.

    Um terceiro exemplo é o modelo mental do Management 3.0, que busca operar na energização de pessoas, empoderamento de times, alinhamento de restrições e desenvolvimento de competências em ambientes de gestão complexos.

    Então, pessoas são irrelevantes?

    Lógico que não. O oposto é verdade. Você deve energizar pessoas todo o tempo e de todas as formas possíveis. Fornece-las propósito, autonomia e oportunidades contínuas de desenvolvimento é fundamental para desenvolver e aprimorar os seus sistemas de trabalho.

    Aqui entra o papel da liderança. Quando um líder é fraco e cultiva sistemas de trabalho ruins, a colheita será pífia. Mesmo com pessoas brilhantes.

    Ao invés, se você como líder desenha bons sistemas de trabalho, você abre espaço para o desenvolvimento das pessoas e você terá resultados positivos para a sua gestão e a sua organização.

Os gerentes não são confrontados com problemas independentes entre si, mas com situações dinâmicas que consistem em sistemas complexos de problemas de mudança que interagem entre si. Eu chamo essas situações de bagunça. Os problemas são extraídos das bagunças pela análise. Os gerentes não resolvem problemas, eles gerenciam bagunças, Russel Ackoff

 

 

 

 

 

 

 

 

 

Retrospectivas ágeis sem frescuras

Avaliar se projetos e times estão indo bem é uma ideia já antiga, popularizada em corpos de conhecimento como o PMBOK (Project Review) ou RUP (Iteration Review). E com o crescimento dos métodos ágeis e do SCRUM, o termo retrospectiva ganhou muito popularidade nesse século (Sprint Review).

No Brasil vemos muitos times praticar retrospectivas. Ao mesmo tempo, vemos que muitas dessas reuniões estão focadas puramente em avaliar aspectos motivacionais das pessoas e capturar sentimentos de ansiedade, irritação, desespero ou melancolia.

O foco está primeiro nas pessoas e depois no trabalho. E essa abordagem é perigosa por vários motivos. Enumero alguns motivos aqui:

  1. Se você enquanto Agile Coach não tem formação em psicologia, você pode fazer mais estragos do que melhorias ao tentar promover mudanças comportamentais baseadas em percepções de problemas do campo do subjetivo.
  2. Tentar “melhorar” aquele garoto enxaqueca do seu time não é algo que possui receita, resultado garantido e muito menos tempo definido. O contrário é verdade. Converse com qualquer psicologo sobre o assunto e se surpreenda com o tempo necessário para trabalhar frustrações do campo do subjetivo. Definitivamente, não é algo que você possa colocar em um cartão e executar em uma sprint.
  3.  A sua reunião pode virar uma sala de lamentação, onde desenvolvedores passivo-agressivos vão ficar expondo lamúrias e riscando post-is sem parar para lidar com a agressividade reprimida.
  4. O papel conceitual de uma retrospectiva é o melhorar o seu sistema de trabalho. Se a reunião não cumpre esse objetivo, ela não é um ciclo de feedback de verdade para o sistema adaptativo complexo de trabalho.

Veja. Não estou dizendo que pessoas não são importantes. O contrário é verdade. E é justamente por isso que precisamos respeitar os adultos que estão ali convidados por você e honrá-los com uma reunião que funcione.

Retrospectiva Sem Frescura

Para isso vamos apresentar a Retrospectiva Sem Frescura, centrada no trabalho e respeitando as pessoas ali presentes.

Você deve conduzir uma retrospectiva olhando para o seu quadro Kanban de histórias. Observe a coluna de trabalho realizado. Para cada história ali depositada, pergunte:

  1. Os nossos clientes ficaram satisfeitos com essa história?
  2. Esse história atendeu aos parâmetros de qualidade, custo, e demais critérios de aptidão dos clientes internos e diretoria.
  3. Essa história fluiu bem ao longo do nosso quadro Kanban? O tempo de entrega dessa história foi boa? Ou tivemos impedimentos, bloqueios ou esperas em filas?

Observe também que essas perguntas vão trazer as insatisfações pessoais, com certeza. Por exemplo, se um desenvolvedor precisou esperar 3 dias para ter uma permissão em um banco de dados específico, a insatisfação concreta irá emergir e poderemos ter atos de liderança para endereçar essa situação específica. Mas a agenda é motivada pelo trabalho e para o trabalho, respeitando as pessoas e buscando soluções objetivas para melhorar aquele trabalho.

E se você nem consegue responder ao item 1 do roteiro acima, o seu trabalho está com problemas graves. Você está conduzindo uma retrospectiva onde não houve entrega de valor para os seus clientes. É um sintoma de empresas que focam mais em iniciar coisas do que terminar. Ao invés, pare de começar e comece a terminar.

O passo a passo – Retrospectiva Sem Frescuras

  1. A revisão é feito em frente ao quadro Kanban. Ela foca nos itens completados.
  2. Ela coleta observações, ocorrências, falhas, ideias a serem exploradas e políticas atuais.
  3. Ela categoriza o feedback coletado e define ações de melhoria no sistema de trabalho.

Gerencie o trabalho e não as pessoas

Corpos de conhecimento com o método Kanban e o Management 3.0 nos ensinam que a gestão deve ocorrer sobre o trabalho e não sobre as pessoas.

Ao focar no trabalho, você cria pragmatismo e honestidade com a sua empresa. Você cria foco também para lidar com os problemas e frustrações. E você respeita também o direito das pessoas estarem irritadas e ainda assim entregar um trabalho honesto e apto para o propósito da sua organização e seus clientes.

 

Scrum ainda mais medíocre – Mais disfunções ágeis e mais antídotos

Publiquei na semana passada um post sobre disfunções ágeis comuns na implementação do framework Scrum.

São elas.

  1. Reunião diária Zombie
  2. Trabalho empurrado
  3. Métricas míopes
  4. Servidão ao backlog
  5. Escopo fixo e prazo aberto

Apontamos também alguns antídotos para essas disfunções, que são:

  1. Pergunte ao quadro Kanban
  2. Trabalho puxado
  3. Métricas acionáveis
  4. Gestão do upstream
  5. Fluxo contínuo e MVPs

Caso ainda não tenha lido recomendo a leitura para contexto.

Dando sequência ao tema de disfunções ágeis, relato aqui mais disfunções ágeis que podem drenar todo o dinheiro da sua iniciativa ágil como um chupa-cabra de métodos ágeis. Mais à frente, apresentamos antídotos para esses problemas.

Mais 5 disfunções ágeis

  1. Critério de preparado (Ready) ausente ou mal especificado

Um problema comum em vários times que operam Scrum é não estabelecer um acordo claro para aceitar um requisito e iniciar a sua construção. Isso se manifesta com reuniões de planejamento longas e cansativas e, pior, problemas de entendimento que acompanham a sprint e um número excessivo de defeitos de negócio em ambientes de produção.

  2. Critério de aceite (Acceptance) ausente ou mal especificado

É também comum quando POs novatos ou que estendem a confiança ingenuamente não definem os critérios de aceite funcionais e não-funcionais externos, como por exemplo a usabilidade, performance ou segurança.

“O óbvio é individual”, já disse um sábio certa feita. Assumir que o time de engenharia de produtos irá incorporar aspectos de qualidade porque aquilo é óbvio é uma decisão ingênua.

3. Critérios internos de qualidade ausentes

Quando desenvolvedores e QAs olham apenas para os requisitos funcionais, uma dívida técnica será naturalmente introduzida dentro do sistema. A razão é a entropia crescente nesses sistemas complexos.  Exemplos incluem:

  • Ausência de automação de testes
  • Códigos-fonte sujos (mal-cheiros)
  • Arquiteturas de software erodidas
  • SQLs ineficientes
  • Problemas de segurança

Se um time não age proativamente e introduz políticas para pagamento permanente da dívida técnica, os sistemas irão apenas degradar ao longo do tempo e eventualmente gerarem problemas gravíssimos para suas áreas de negócio.

4. Ausência de folgas (Slack) e previsibilidade inconsistente

Tom de Marco escreveu um livro muito instigante em 2001 (Slack) mostrando a estupidez da hiper-otimização dos trabalhadores do conhecimento e os seus efeitos ruins para as pessoas e também para a própria organização em médio e longo prazo.

Nicholas Taleb também nos adverte, de forma ainda mais contundente no seu livro Antifragilidade – Coisas que se beneficiam do caos, da fragilidade inerente de organismos hiper-otimizados. A natureza e os sistemas complexos amam redundâncias.

Donald Reinertsen, outro grande pensador, nos mostra também que sistemas de trabalho ocupados afetam brutalmente e negativamente a previsibilidade de entrega de novas funcionalidades.

Livro Slack - Tom de Marco

Livro Antifragilidade - Taleb

Princípios de Fluxo no Desenvolvimento de Produtos

Assumir que alguém trabalha exatamente 7 ou 8 horas por dia e tentar alocar o esforço de pessoas como se fossem máquinas é ruim economicamente para a organização, psicologicamente para as pessoas e também para a previsibilidade de entregas.

Em linguagem simples, você observa essa disfunção através de sprints “que falham”, i.e, não entregaram todo o “escopo” porque as pessoas não “trabalharam” de forma eficiente. Ou titica de galinha sobre esterco de vaca.

5 – Heroísmo. Ou síndrome de Tanus.

Outra disfunção comum é esperar que pessoas e times ágeis irão ter comportamentos heróicos e irão fazer o que for necessário para bater as “metas” definidas pela gerência.

O heroísmo na construção de produtos digitais é um fenômeno estudado há décadas. E a “má notícia” é que não existem heróis. Você não está em um filme de espionagem onde hackers com “intelecto avançado” teclam um monte de comandos mágicos e o sistema começa a operar. E até nos filmes mais recentes, basta alguém estalar os dedos e metade dos heróis vai embora.

Modelos de maturidade mais modernos, como por exemplo o excelente Kanban Maturity Model, mostram que o heroísmo é um sintoma de serviços de baixa maturidade (ML1). Não é algo sustentável em médio e longo prazo e impede a criação de serviços previsíveis e aptos para o propósito de negócio.

Mais Antídotos

1. Gestão do Upstream (para o critério de Preparado  mal especificado)

A gestão de upstream é uma técnica descrita no KMM (Kanban Maturity Model) e assunto central do livro Essential Upstream Kanban.

Livro Essential Upstream Kanban

Entre o Upstream (território do PO) e o Downstream (território da engenharia e Scrum Masters) existe o ponto de compromisso que precisa ser bem estabelecido através de políticas explícitas, prática geral de todo sistema Kanban maduro.

2. Compromisso em duas fases (Two Phase Commit)

Sistemas de trabalho bem estruturados devem ter não apenas o ponto de compromisso bem estabelecido para iniciar o trabalho. Devem ter também o ponto de compromisso onde o trabalho seja aceito. E para isso precisamos ter políticas explícitas indicam como o trabalho deve ser entregue para ser considerado como finalizado.

Se você quer que o seu copo de água seja servido em copo de vidro, com duas pedrinhas de gelo e uma rodela de limão siciliano, explicite isso no começo do jogo. O combinado não é caro.

O Two Phase Commit é uma técnica Kanban que reduz, semana após semana, a ambiguidade para iniciar e fechar um trabalho do conhecimento. Ela permite que você crie critérios de preparado e de aceite incrementais e que funcionem na sua realidade objetiva.

3. Critérios internos de qualidade

Ninguém em sã consciência pede para um cozinheiro não lavar as verduras para apressar o preparo dos pratos. E provavelmente cozinheiros profissionais não aceitariam essa proposta estranha. Lavar as verduras é dever ético e de higiene em uma cozinha profissional.

Da mesma forma, nenhum desenvolvedor deveria negociar aspectos básicos da higiene do seu código no dia a dia. Refatorar e fazer testes de unidade devem ser parte integrante e diária do trabalho. Como tomar banho e escovar os dentes. E não um trabalho adicional que deveria ter permissão gerencial.

Lógico. Falar isso é fácil. E reconheço que isso é ainda muito difícil em ambientes abusivos onde metas de prazo são impostas de cima para baixo e não descobertas pela vazão do time.

Mas é dever ético de qualidade de um time expor e brigar por seus critérios internos de qualidade. Git Pull Requests, Pair Programming, Mob Programming, Testes de Unidade, Refatoração, entre outras práticas, são exemplos nesse sentido.

E se você quiser se armar com argumentos sólidos para conversar com a sua chefia, recomendo dois clássicos a respeito do sempre incansável Uncle Bob, um dos signatários do Manifesto Ágil de 2001.

4. Limitar o trabalho em progresso, políticas explícitas e gestão do fluxo (para atacar o problema de previsibilidade)

Times sem políticas de limitação do trabalho e outras políticas explícitas são facilmente abusados no seu dia a dia. Um dos papéis de um sistema de trabalho é conhecer e estabelecer a capacidade de trabalho apropriada para um time em um contexto real de forma a:

  • Reduzir os prazos de entrega
  • Reduzir a variabilidade.

Fato curioso é que o tempo médio de entrega é inversamente proporcional ao volume de trabalho em progresso, como já nos mostrou John Little ainda nos anos 60 na sua Lei de Little.

Quando você introduz sistemas Kanban sobre times que estão operando o framework Scrum, você ganha consciência da utilização de trabalho mais apropriada para aquele time e evita problemas de sobrecarga que se manifestam como engarrafamentos (muita coisa para fazer, muito estresse, pouca vazão e resultados pífios).

5. Limitar o trabalho em progresso, políticas explícitas e gestão do fluxo (para atacar o problema de heroísmo)

O heroísmo é sintoma de um sistema de trabalho frágil, i.e., onde as metas são impostas de cima para baixo sem conhecer a vazão possível e ideal dos times. É um sintoma de um sistema desequilibrado, onde medições não são realizadas consistentemente, onde políticas corretas estão ausentes e sistemas de feedback não estão instalados.

Novamente, o mesmo antídoto aplicado no item 4 pode ser usado para identificar as causas raízes que levam aos atos de heroísmo, introduzir hipóteses de melhoria e com base no pensamento científico testar e manter as hipóteses que melhorem o sistema de trabalho. Através de um processo contínuo de melhorias através da abordagem de mudanças evolucionárias, criamos um sistema robusto de trabalho em médio e longo prazo.


A mensagem desse post é simples. Faça uso do sistema de gestão de mudanças Kanban para melhorar o seu trabalho como Scrum Master.

 

Scrum Medíocre – 5 Disfunções ágeis e seus antídotos

O Scrum é o framework ágil mais usado na comunidade ágil. Desenhado ainda nos 90, ele trouxe um guia acionável para organizar e entregar projetos com ideias muito boas tais como:

  • Ciclos PDCA de curto prazo (Sprints) e ritos para sistematizar esses ciclos (planejamento de sprint, reunião diária, revisão e retrospectiva)
  • Papel de facilitador do método, combinando funções de processo e de gestão (Scrum Master)
  • Papel de interface com áreas de negócio e conceito mais claro de produto (Product Owner)
  • Times multidisciplinares (ao invés de pessoas que trabalham sozinhas e não colaboram).

Entretanto, a forma como o Scrum foi implementado em muitas organizações lá fora e no Brasil criou um monstrinho que apelido aqui de Scrum Medíocre. É fácil reconhece-lo através de disfunções comuns. Enumero 5 dessas disfunções ágeis aqui.

Reunião diária zombie

SM: – João, o que você fez ontem?
SM: – E você, Maria, o que fez ontem?
SM: – José, meu filho, me fala o que fez ontem?

João, Maria e José, como zombies, respondem de forma catatônica às perguntas do Scrum Master comando e controle. Eles estão com sono, não querem estar ali em pé, detestam aquele momento e estão contando os minutos para voltar às suas mesas e colocar o fone de ouvido.

Qual o problema aqui? Foco nas pessoas e não no trabalho.

Trabalho empurrado

Primeiro dia da Sprint 
PO: – Time, nos temos 7 histórias que devem ser completadas em 10 dias úteis. Ordens da chefia. João, você pega as histórias 1 e 2. Maria, você que é sênior irá trabalhar nas histórias 3, 4 e 5. José, conto com você para cuidar das histórias 6 e 7.

Ultima dia da Sprint
O time não entrega nem 50% do trabalho empurrado e é culpado pela sua performance ruim. Uma reunião de retrospectiva é chamada onde o time tem a sua atenção chamada pelos problemas de desempenho.

Primeiro dia da próxima sprint
A mesma história se repete.

Métricas míopes

Tudo o que o time conhece são sprints e suas métricas locais. O time estima com planning poker, tamanho de camisa e afins. E ele mede a sua produtividade local com gráficos de burndowns.

Mas se você pergunta a qualquer um, até mesmo o PO, quanto tempo demora em média uma demanda para fluir da chegada até a produção, a resposta é nula. Nenhuma métrica acionável de cliente é usada pelo time.

Servidão ao backlog

O backlog é cultuado como se os desejos ali colocados fossem ordens de Deus. O PO e o time não fazem nenhum engenharia de valor e o foco é puramente centrado na entrega de funcionalidades. O % de completude de backlog é usado como métrica de sucesso da iniciativa, centrada puramente em escopo.

Projetos centrados em escopo fixo e prazo aberto

O escopo, ao invés do tempo, é o principal guia para organizar quando um projeto deve terminar. Se um time trabalha 3 meses e o escopo não foi cumprido, novos sprints são abertos até que o escopo seja completado. O conceito de prazo fechado e MVPs são completamente ignorados. O dinheiro é drenado como em projetos tradicionais pelo modelo mental da fixação ao escopo.

Muitas dessas disfunções tem sido amplamente debatidas por agilistas que assinaram o Manifesto Ágil como Martin Fowler, Robert Martin (Uncle Bob) e Allistair Cockburn.

Juntas, essas disfunções criam um cenário terrível de agilidade burocrática que drenam o dinheiro do seu time como um tipo de chupa-cabra do mal.

chupacabra

Antídotos ao Scrum Medíocre

A boa notícia é que você pode incorporar ideias antifrágeis ao seu sistema de trabalho para sair da mediocridade Scrum.

Pergunte ao quadro (Antídoto para a Reunião Diária Zombie)

Ao invés de perguntas para as pessoas sobre o que elas fizeram ontem, pergunte ao quadro. Faça a reunião diária com o quadro Kanban aberto. Navegue da direita para a esquerda (e não da esquerda para a direita). Você quer terminar itens mais que começar novas coisas e aumentar de forma ingênua o trabalho em progresso.

Para cada cartão navegado, pergunte se existem gargalos. Exemplos de gargalos incluem itens bloqueados, tarefas que estão há muito tempo no quadro ou limites ao trabalho em progresso. Quando um gargalo é encontrado, você incentiva ações do time para desbloquear itens bloqueados ou atuar sobre itens parados. Mostre ao time que estamos interessados em fazer o trabalho fluir.

Em resumo. Não pergunte o que o João, Maria e José fizeram ontem. Queremos gerenciar o trabalho e não as pessoas. Essa pequena mudança de comportamento faz o time perceber que você está preocupado com a entrega. E não microgerenciamento do trabalho deles.

Trabalho puxado (Antídoto para o trabalho empurrado)

Ao invés de um trabalho empurrado de forma comando e controle para o time, o PO deve apenas alimentar uma coluna de pronto para começar.

E o time deve puxar o trabalho sob demanda, um item por vez. Ou seja, o time se compromete com poucas coisas. Isso cria foco para o time e reduz sua ansiedade. O compromisso estabelecido cria um trabalho que deve fluir pelo sistema e com a ajuda de reunião diária efetiva irá fluir.

O PO observa a vazão média de itens por  quinzena ou mês. E essa vazão permite que ele comece a compreender a dinâmica do time e a sua capacidade de entrega. E então ele fornece itens dentro da vazão possível pelo time. A realidade deve guiar o PO e não fantasias imaginárias de produtividade.  O trabalho puxado é o melhor aliado do PO para aumento da eficiência do seu time.

Métricas Acionáveis (Antídoto para métricas míopes)

O PO, SM e time devem observar duas métricas centrais na ótica dos clientes que são:

  • O tempo de ciclo das entregas (lead time)
  • A vazão das entregas (taxa de entrega de demandas em base semanal ou quinzenal)

Por quê?

Porque clientes querem saber quanto tempo um time vai demorar para fazer um trabalho e quantos itens são entregues por período (ou sprint).

Em última instância, essas métricas observam se o seu sistema de trabalho é solido, i.e, como o trabalho flui desde o momento do compromisso até o momento do aceite. Como o tempo médio, sua distribuição e a vazão estão se comportando dentro de cada etapa do seu fluxo de trabalho.

Ou seja, essas métricas permitem que você analise gargalos, critérios de aptidão para os seus clientes e lhe permitem estabelecer previsibilidade de trabalhos futuros. Se um time descobre, por exemplo, que o seu time demora 9 dias para entregar um trabalho comprometido, você consegue estabelecer compromissos baseados na realidade objetiva do histórico do seu time.

Gestão do Upstream (Antídoto para a Servidão ao Backlog)

A gestão do upstream é uma técnica onde o PO pode organizar um quadro Kanban específico para identificar, realizar processos de triagem, engenharia de valor e entregar itens prontos para a execução para o time de desenvolvimento de produtos.

Os processos de “triagem” de ideias podem eliminar demandas antes de irem para o time. Essa mortalidade é positiva. Isso gera economia de tempo e consequentemente de custo.

Além disso, o upstream também busca entender a melhor cadência para entregar os itens para o time de desenvolvimento de produtos e qual deve ser a taxa de entrega de itens em base periódica conforme a taxa de consumo viável do time de desenvolvimento. Um quadro de upstream que entrega trabalho além da capacidade de vazão do time de execução (chamado de downstream) gera um backlog  extenso. E essas demandas se tornam obsoletas enquanto aguardam serem atendidas

Fluxo Contínuo e MVPs (Antídoto para projetos centrados em escopo fixo e prazo aberto)

O conceito de fluxo contínuo é um antídoto que pode ser usado em times de maior maturidade. E é incrivelmente poderoso. Ao invés de fixação em projetos com escopo fixo que levam invariavelmente a conflitos terríveis entre times e clientes, buscamos entregas de fluxo contínuo.

Trabalhar em fluxo contínuo significa que um time pega um item quando tem capacidade disponível, se organiza para entregar o item de ponta a ponta dentro do menor tempo de ciclo possível e agrega valor de negócio incrementalmente.

Trabalho com fluxo contínuo em TI não é trivial e requer também que o custo de transação para implantar em produção seja baixo. Isso muitas vezes requer arquiteturas centradas em microsserviços e práticas DevOps CI/CD bem estabelecidas. Mas se você tem as premissas apropriadas, pode ser uma abordagem muito interessante.

O Catálogo de Antídotos do Método Kanban

Cada um desses antídotos faz parte do método Kanban. O método Kanban não é uma alternativa ao Scrum. Ao invés, ele é uma ferramenta para você introduzir mudanças no seu sistema de trabalho centrado em Scrum. Ele é uma lente de análise para você observar o trabalho do seu time, detectar fragilidades e melhorar continuamente o seu sistema de trabalho. Da fragilidade para a resiliências, robustez e então antifragilidade.

O método Kanban lhe fornece esteróides naturais para você introduzir estressores no seu Scrum e sair de um Scrum medíocre para um Scrum de alta maturidade.

Quer melhorar o seu Scrum? Adote práticas Kanban.

“The fragile wants tranquility, the antifragile grows from disorder, and the robust doesn’t care too much”, Taleb.