Sem categoria

Cinco Ideias Inesperadas e Efetivas para Reduzir o Tempo de Entrega das Suas demandas

~ Marco Mendes ~ Deixe um comentário

Muitos times em empresas de serviços profissionais lutam com o cumprimento dos tempos de entrega de suas demandas. Estima-se que 80 a 90% dos times no Brasil e no mundo sofram de problemas tais como:

  • Clientes frustrados ou infelizes com os tempos de entrega
  • Tempos de entrega altos frente aos propósitos de negócio
  • Muita variabilidade nesses tempos de entrega
  • Frustrações gerenciais por não conseguir atacar esse problema.

Nesse sentido, apresento aqui cinco técnicas inesperadas que podem lhe ajudar, como líder ou colaborador do seu time, a atacar de frente esse problema.

Use a Via Negativa

Reza uma lenda que o Papa Júlio II perguntou a Michelangelo qual era o segredo da sua enorme habilidade ao contemplar a estátua de David. A resposta do escultor foi:

“É simples. Tudo o que eu tive que fazer foi remover o que não era o David da pedra bruta.”

Já os hackers da saúde sabem há muito tempo que remover agressores do seu organismo é muito mais efetivo que criar dietas esotéricas, procedimentos invasivos ou tomar remédios como se fosse bala chita. Você remove o agressor, como por exemplo comer 50 quilos de açúcar por ano (a média do Brasileiro), e o seu corpo se reequilibra naturalmente depois de alguns meses.

A via negativa trabalha na remoção das fragilidades, ao invés de tentar adicionar novas técnicas, práticas ou frameworks ao seu modo de trabalho.

O mesmo vale para o tempo de entrega. A grande maioria das pessoas pensa, ao lidar com demandas, que devemos fazer que as pessoas trabalhem mais rápido ao realizar as suas tarefas. Mas o problema do tempo de entrega não está no tempo de trabalho de uma demanda. Está no tempo que a demanda não é trabalhada. Troy Mageniss, Alexei Zheglov e David Anderson, por exemplo, já nos mostraram em seus estudos que a maior parte do tempo de entrega de demandas é gasta com:

  • Repasses do trabalho entre áreas
  • Impedimentos
  • Defeitos
  • Retrabalhos
  • Dependências por outros times na sua organização
  • Dependências por fornecedores externos
  • Espera em filas

Outro monstro sagrado da área de produtividade, Donald Reinertsen, sugere através de suas pesquisas que a eficiência de fluxo na maioria dos times de produtos é entre 5 a 15%. Ou seja, 85% do tempo a demanda não está sendo trabalhada. Ela está esperando.

Compartilho meus dois centavos aqui da minha experiência pessoal de implantação de agilidade como consultor nos últimos 12 anos. Nunca medi uma eficiência de fluxo acima de 30% em nenhuma organização que já tive contato.

Ou seja, se você quiser melhorar o tempo de entrega do seu trabalho, não ataque o trabalho. Ataque o não-trabalho. Ataque os fatores que irão formar filas, socialize acordos de gestão de dependências e reserva de capacidade que irão reduzir as dependências internas e externas. Socialize também políticas que reduzam defeitos e retrabalhos.

O Aumento da Consistência é um Caminho Indireto para Reduzir o Tempo de Entrega

Você conhece duas pizzarias. A primeira tem um tempo de entrega médio de 15 minutos. A segunda tem um tempo de entrega médio de 30 minutos. Onde você escolhe a sua pizza se você quer comer mais rápido?

A resposta, apressada e ingênua, é a primeira pizzaria. Mas você pode estar terrivelmente enganado e vai ficar com fome mais tempo.

A resposta mais precisa requer entender como é a variabilidade no tempo de entrega da sua pizzarias. Vamos assumir que a primeira pizzaria tem tempos de entrega que variam entre 10 e 90 minutos com um percentil p90 de 60 minutos. Já a segunda pizzaria tem tempos de entrega que variam entre 20 a 55 minutos, com um percentil p90 de 45 minutos. A escolha segura é a segunda pizzaria.

Quando você gerencia um sistema de trabalho, devemos reconhecer o tempo de entrega não é um número, mas uma distribuição estatística. Um exemplo simples pode ser visto aqui nesse artigo que fiz sobre como interpretar um histograma de tempo de entrega.

Reconhecer isso nos revela que melhorar a consistência é um caminho indireto para melhorar o tempo de entrega.

Se você cria consciência para o tempo de envelhecimento das suas demandas, você cria ações que vão evitar que tenhamos amostras muito à direita no seu histograma. Isso irá criar dois efeitos:

  • Reduzir o efeito de caudas longas. Eventualmente, você pode mover a sua distribuição de tempo de entrega para uma distribuição de cauda curta.
  • Mover a mediana e percentis do tempo de entrega para à esquerda. Isso te torna mais rápido.

Ou seja, busque melhorar a sua consistência no trabalho diário. Ataque ativamente as fontes de variabilidade e use a via negativa. Ao se tornar mais consistente, você irá se tornar mais rápido.

Use o argumento de Amdahl para Reduzir as Crenças em Balas de Prata e Heróis

O Argumento de Amdahl é usado para encontrar a máxima melhoria esperada para um sistema em geral quando apenas uma única parte dele é melhorada.

Uma forma simples de entender essa lei é pensar que você está em um carro super possante (vamos sonhar, uma Bugatti Chiron que acelera de 0 a 100 km/h em 2.4 segundos). Mas você está no meio de uma avenida engarrafada, com sinais de trânsito a cada 100 metros. Um carro possante não é muito útil aqui, certo?

O argumento de Amdhal pode ser expresso matematicamente da seguinte forma.

Onde:
  • s= melhoria introduzida em uma parte do sistema, e
  • p= proporção do tempo que essa parte do sistema pode ser usada

Em termos simples. Você contrata um novo líder técnico para o seu time que consegue dobrar a produtividade do seu núcleo de desenvolvimento. Uma impressionamente melhoria local de 100%. Mas o tempo de ciclo do desenvolvimento é responsável por 20% do seu tempo total de entrega. Ao calcular a melhoria esperada no seu sistema de trabalho, você vai observar que a melhoria global não será maior que 11%.

O grande Frederik Brooks, no seu clássico artigo No Silver Bullet – Essence and Accident in Software Engineering nos avisa que não existe um desenvolvimento, seja tecnológico ou gerencial, que em si mesmo possa prometer melhorias de dez vezes na produtividade, confiabilidade ou simplicidade de um sistema de trabalho.

A lição aqui é clara. Não superestime as suas intervenções gerenciais. Nenhuma intervenção pontual irá criar uma bala de prata que irá matar os seus lobisomens. Melhorias serão sempre incrementais.

Embora incrementais, os seus efeitos podem ser multiplicativos.

Incorpore Sistemas Multiplicativos no Seu Dia a Dia

A General Motors, fundada no começo do século, chegou a dominar o mercado automotivo americano com 50% de participação de mercado por meio de uma série de inovações brilhantes e práticas de gestão no século XX. Por muitos anos ela foi a corporação dominante e mais admirável nos EUA. Mas os acionistas originais da GM terminaram com um zero em 2008 quando a empresa entrou em falência devido a anos de má administração financeira. Ela foi fragilizada pela famosa crise financeira daquele ano. Não importava que eles tivessem várias gerações de liderança: tudo isso se torna nada em um sistema multiplicativo.

Você aprendeu na terceira série do ensino fundamental que multiplicar algo por zero torna o todo zero. Mas poucos gerentes param para avaliar o efeito das restrições em seus sistemas de trabalho. Identificar as restrições é essencial. Por exemplo, a vazão de um sistema de trabalho é limitada pelo ponto mais frágil no fluxo de trabalho.

Se você não implementar ações que vão (1) proteger o gargalo; (2) submeter as decisões do sistema ao gargalo ou (3) elevar o gargalo, você pode sub-otimizar o seu trabalho e ter um resultado composto pífio.

Tudo isso remete à consistência novamente. Consistência é essencial para estabelecer robustez e resultados sólidos ao longo do tempo.

Sistemas Kanban, por exemplo, usam limites de WIP sobre o fluxo de trabalho para estabelecer consistência, entregas previsíveis, evitar a formação de fila, aumentar a eficiência de fluxo (via negativa) e fazer bom uso dos sistemas multiplicativos.

Remover a Obsessão em Times e Squads e Evoluir para o foco em Serviços

O mercado Brasileiro de agilidade colocou o conceito de times no centro do seu sistema solar. E a cópia do modelo de time da Spotify virou um conceito popular nas mesas de diretores de TI. Mas o conceito de time é limitante, como já mostra o modelo de maturidade KMM. Foco em time te leva a maturidade 1 (em uma escala de 0 a 6). E lá você irá permanecer.

Deixo aqui um exemplo simples de um trabalho provavelmente muito menos intelectual do que aquele que você, leitor, está fazendo hoje. Quando você pede uma pizza no seu local favorito, pelo menos os seguintes times precisam ser envolvidos para a pizza chegar plena na sua casa:

  • A equipe de expedição de entrada e saída da pizzaria
  • Os pizzaiolos e outros cozinheiros
  • A rede de entregadores
  • O time de TI que suporta a plataforma que você usou no seu App de compras.
  • A rede de fornecedores que entregam ingredientes e insumos para a sua pizzaria.

No mundo dos serviços profissionais é ainda pior. Já observei casos onde o trabalho de um time dependia de mais 10 times. Isto é, cada demanda dependia de dez times para que a “pizza” chegasse na mesa dos clientes. E, ainda assim, o foco em time leva a comportamentos auto-centrados e métricas de vaidade tais como:

  • Numero de pontos entregues na sprint
  • % de Acerto do Trabalho Planejado versus Realizado

Observe que não estou dizendo que focar em times é ruim. Quando a maturidade da sua área é zero, frameworks como o Scrum ou o modelo de Squads podem te levar muito rapidamente à maturidade 1. O foco em times é aqui bem saudável e pode promover maior colaboração social e senso de propósito local. Mas acreditar que isso é o fim da jornada é ingênuo e perigoso e é conhecido hoje em vários círculos como o Kanban e o Flight Levels como um platô de mediocridade.

O KMM nos ensina que o foco em serviços, que coloca o cliente no centro do jogo, é uma abordagem superior para você atingir maior maturidade do seu processo de agilidade e reduzir os tempos de entrega. Como boa parte do tempo de vida de uma demanda está nos repasses, impedimentos e dependências, uma visão integrada do serviço incentiva que exista feedback e colaboração entre times.

Em termos simples, o que estou dizendo aqui é que não é suficiente você ter uma cozinha com pizzaiolos com estrela Michelin no currículo e uma rede de entregadores formadas por motociclistas profissionais. Se o produto fica quinze minutos parado entre a cozinha e a rede de entregas, a seu pizza vai chegar fria e borrachuda na sua casa.

O genial Russel Ackoff, pensador seminal do campo do pensamento sistêmico, nos lembra.

“Para gerenciar um sistema de forma eficaz, você deve se concentrar nas interações entre as partes, em vez do comportamento das parte em separado.”

Resumo

Aplique a Via Negativa aos seus processos de agilidade. Lembre-se que o conhecimento cresce mais por subtração do que por acréscimo. No caso do tempo de entrega, ataque o tempo que o trabalho está esperando, muito mais o tempo que o trabalho está sendo trabalhado.

Entenda que a busca pela consistência é uma poderosa arma para achatar as caudas do seu histograma de tempo de ciclo e o efeito colateral de primeira ordem é reduzir as médias e percentis e portanto reduzir o tempo de entrega percebido pelos seus clientes.

Se lembre do Argumento de Amdahl para limitar as suas crenças em balas de prata. Lembre-se que as mudanças serão incrementais. Mas os efeitos podem ser multiplicativos se realizados ao longo de meses ou anos.

E. finalmente, entenda que existem grandes oportunidades de melhorias nas interações dos times. Promover a produtividade relacional pode ser de benefício enorme na redução dos seus tempos de entrega.

Ponto de Compromisso – A Apólice de Seguros do Agilista

~ Marco Mendes ~ Deixe um comentário

Em um famosa cadeia de lanchonetes conhecida mundo afora, dezenas de milhares de pedidos são feitos ao longo de um dia.

No início da sua operação, algumas décadas atrás, as pessoas faziam pedidos sem qualquer formalização. Os pedidos eram automaticamente enviados para a cozinha. O ponto de compromisso era imediato, assim que o cliente falava algo. “Um X-bacon e uma coca-cola”, e o pedido era comandado.

Inicialmente isso funcionou, mas com o crescimento da rede e novos funcionários sem experiência vários pedidos vinham errados e o retrabalho passou a operar acima de níveis aceitáveis. Tudo isso afetava a satisfação dos clientes, além de gerar prejuízos financeiros para a essa rede de lanchonetes.

Depois de algum tempo, o sistema para aceitar pedidos mudou. Quando um cliente chegava ele entrava na fila, um atendente o recebia e começava a organizar o pedido. Ele perguntava agora o sanduíche desejado, acompanhamentos como batatinhas fritas ou saladas com molhos, refrigerantes, sucos e sobremesas. Mas a cozinha não estava trabalhando para o cliente. Não ainda. Não existia formalmente nenhum compromisso. O ponto de compromisso não havia sido estabelecido. Apenas depois do pagamento realizado o pedido era comandado.

A Apólice de Seguros da Lanchonete

Veja as duas figuras do sistema de trabalho dessa lanchonete, modeladas como quadros Kanban.

Observe o papel do ponto de compromisso nas figuras. Ele separa as opções que chegam mais acima (Upstream Kanban) dos compromissos que devem ser honrados (Delivery Kanban). Se você quer saber mais sobre Upstream Kanban, a arma destruição em massa de POs e SMs, fiz um post sobre essa importante técnica aqui

Na primeira figura o ponto de compromisso (momento no tempo onde o pedido é formalizado pela cozinha) está muito mais acima.

Na segunda figura o ponto de compromisso desceu. Existe agora um processo de preparação do pedido. Existe um atendente que está ajudando os clientes a preparar o pedido. Observe que isso é custo, mas ele se justifica para evitar que pedidos errados entrem na cozinha, o retrabalho aumente e clientes fiquem insatisfeitos.

Formalmente, o ponto de compromisso é assim definido no método Kanban.

“O ponto do processo em que ocorre a transição entre as etapas de trabalho descomprometido e comprometido”, Portal KMM

Quando descemos o ponto de compromisso, estamos dizendo que iremos “investir” tempo e profissionais na qualificação da demanda. Isso é custo, que pode ser pensando como um equivalente a uma apólice de seguros.

Um Caso Real em um Equipe de Produtos

Quando desenvolvemos produtos, o trabalho que chega pode ser empurrado para o time. Se assim ocorre não existe ainda um ponto de compromisso e isso pode provocar os seguintes problemas:

  • desequilíbrio entre a demanda e capacidade.
  • pedidos mal qualificados
  • pedidos que estão alinhados com a estratégia da organização
  • retrabalhos diversos

Nesse time de produtos, cuja empresa vou chamar de ACME, todos esses problemas eram observados.

A liderança do time, após compreender o conceito de um ponto de compromisso derivado de seus estudos Kanban, orientou o time na introdução dessa técnica.

Em um sistema Kanban, para dizer que um item de trabalho está comprometido, ele deve atender a duas condições:

  • (1) o cliente tem uma forte expectativa de que o trabalho em sua solicitação deve agora prosseguir para a entrega e está comprometido em receber (e pagar) pelo resultado;
  • (2) a equipe de serviço tem capacidade disponível para realizar o trabalho e se compromete a começar a trabalhar e entregá-lo. O trabalho é puxado e não mais empurrado

Foi importante que o time definisse um critério para a preparação do trabalho. Inicialmente, apenas os requisitos eram previamente preparados. O retrabalho foi reduzido e o alinhamento com os OKRs da organização melhorou, mas ainda haviam problemas técnicos e de usabilidade. A apólice de seguros ainda não estava alta o suficiente para lidar com o risco.

Posteriormente, o ponto de compromisso desceu para depois da etapa de UX e arquitetura. Isso indicou que o time precisava “pagar” por um seguro maior antes que o compromisso com o cliente pudesse ser realizado. O efeito foi que em algumas semanas os problemas de natureza arquitetural e de usabilidade foram minimizados. O seguro se mostrou apropriado para mitigar o risco.

As figuras abaixo mostram a jornada nesse time de um trabalho empurrado para um sistema com pontos de compromisso bem delimitados.

  • Momento 1
  • Momento 2

  • Momento 3

Tornar o ponto de compromisso explícito traz clareza e transparência ao processo de tomada de decisão. Remover a ambigüidade sobre o ponto de solicitação e o ponto de compromisso e esclarecer o significado de do “compromisso” torna o tempo de entrega do sistema e o tempo de entrega do sistema similares.

De volta ao time ACME, depois de alguns meses, a arquitetura de produto se tornou estável o o time subiu o ponto de compromisso novamente. Agora eventuais trabalhos de arquitetura eram realizados depois do ponto de compromisso. Havia maior confiança técnica compartilhada e o ponto de compromisso se moveu apropriadamente. Esse momento é mostrado abaixo.

  • Momento 4

Ponto de Compromisso Como Apólice de Seguros

Um time ágil pode decidir que precisar investir 10% do seu tempo para qualificar demandas antes que ela sejam comprometidas.

Esse mesmo time pode resolver pagar ou menos nessa “apólice”, usando como fator decisor os problemas observados no seu fluxo de entrega.

Alguns sintomas comuns que já observei nos quadros de entrega e que podem orientar você em investir na sua apólice de seguros incluem:

  • Muito retrabalho nas demandas
  • Trabalho empurrado
  • WIP sem controle
  • Trabalho comprometido abortado com frequência
  • Usabilidade pobre
  • Impacto técnico subestimado

Em um sistema Kanban, então, se você quer aumentar a apólice de seguro você desce o ponto de compromisso. Mas se existe baixo risco você sobe o ponto de compromisso.

Resumo: Pense como o ponto de compromisso como um nivelador de risco. Riscos maiores exigem preparações maiores. Riscos menores sinalizam preparações menores.

Quatro Métricas Essenciais para Melhorar o Seu Processo Ágil — Parte 4: Vazão

~ Marco Mendes ~ Deixe um comentário

Chegamos à quarta métrica essencial para a gestão do seu sistema de trabalho, a vazão. Em conjunto com as métricas de Trabalho em Progresso, Tempo de Entrega e Eficiência de Fluxo, descritas anteriormente aqui, você terá condições fortes de identificar fragilidades e introduzir estressores de melhoria para criar serviços cada vez mais aptos para o propósito.

Caso você não tenha lido os posts anteriores, veja aqui as Partes 1, 2 e 3.

A vazão (throughput) é uma medida de quanto trabalho você recebe ou entrega por período de tempo. Por exemplo, quantas histórias do usuário o seu time entrega por semana, ou quantos épicos o seu time entrega por trimestre.

A vazão está intimamente ligada à sua demanda e capacidade e, portanto, essencial para você compreender se o seu sistema de trabalho está equilibrado e se a sua produção está apta ao seu propósito.

Um exemplo simples – Chegadas e entregas de pedidos em um restaurante

Vamos compreender esse conceito primeiramente um contexto de pedidos em um restaurante em um certo turno de trabalho.

Você, como gerente da expedição, olha para os números e observa a seguinte demanda de pedidos.

11:00 as 12:00 – 20 pedidos
12:00 as 13:00 – 45 pedidos
13:00 as 14:00 – 35 pedidos
14:00 as 15:00 – 10 pedidos

Você olha também para a sua capacidade de entrega e observa o seguinte:

11:00 as 12:00 – 10 entregas
12:00 as 13:00 – 40 entregas
13:00 as 14:00 – 35 entregas
14:00 as 15:00 – 15 entregas

Ao observamos a demanda e a capacidade, vemos que temos um sistema em desequilíbrio. Pedidos se acumulam entre 11:00 e 13:00, e somente depois desse horários começamos a ter uma vazão de saída maior que a vazão de entrada.

Isso fica mais aparente ao enxergarmos isso graficamente, em um gráfico que mostra os pedidos e as entregas de forma acumulada no período onde o restaurante ficou aberto (11:00 as 15:00). A barriga azul mostra o desequilíbrio durante o período de atendimento.

“Mas a barriga é tão pequena”, alguém pode dizer.

Não necessariamente. Veja que entre 12:00 e 13:00 temos quase 20 pedidos empilhados na cozinha. E cada pedido representa alguém com fome. Alguém, literalmente, com a barriga roncando. Então tenha atenção às barrigas nos gráficos de chegadas e partidas, criado nos anos 60 por John Little e que agora é conhecido na comunidade de agilidade como Fluxo Cumulativo de Valor.

Um exemplo real em um time de desenvolvimento de software

Vamos para um caso real agora em um time que cuida de melhorias em um sistema de TI, mas que poderia ser usada em qualquer trabalho do conhecimento (marketing, publicidade, RH ou áreas contábeis)

No começo de Abril, início da nossa análise nesse gráfico, a barriga amarela é pequena e não maior que 10 atendimentos empilhados. Mas durante o período de análise vemos que a barriga começar a crescer e observamos que ao longo de maio já temos quase 50 atendimentos empilhados. Em outras palavras, o WIP ( trabalho em progresso) cresceu de 10 para 50.

Esse gráfico mostra um sistema de trabalho desequilibrado. O efeito prático para os demandantes serão tempos de entrega cada vez piores. Sabemos que quanto maior o WIP, maior será o tempo de entrega. A relação entre o WIP e o tempo de entrega é mostrada abaixo, na fórmula que é conhecida como Lei de Little.

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.

Além disso, a consequência da demanda e capacidade em desequilíbrio é que as pessoas se tornam sobrecarregadas. Isso implica em estresse, menor rendimento, mais defeitos e mais retrabalho no seu sistema de trabalho. Organizações de maturidade zero no KMM sempre apresentam sobrecarga e sistemas de trabalho com forte desequilíbrio.

Usando a vazão para melhorar a saúde do seu sistema de trabalho

Até agora vimos que a vazão pode revelar se a sua demanda e capacidade estão desequilibrados. Isso é chamado de um sistema instável. E isso não é bom.

Para criar sistemas estáveis, precisamos buscar equilibrar a demanda com a capacidade. Existem duas formas de lidar com isso:

(1) Aumento da capacidade (Taxa de Saída)
(2) Limite da demanda (Taxa de Entrada)

O aumento da capacidade (1) é um processo orgânico e depende de muita repetições de estressores de melhoria (ex. práticas de agilidade ou práticas DevOps). Ao mesmo tempo, a capacidade pode ser muito impactada se não houver limite da demanda. Isso porque os colaboradores precisam trocar de contexto e o efeitos de filas, bloqueios e impedimentos se manifestam com muito mais frequência.

Ou seja, a melhor forma de criar um sistema estável, reduzir tempos de entrega, qualidade e previsibilidade é trabalhar no limite de demanda (Taxa de Entrada) (2).

Isso pode ser realizado de uma forma simples olhando a quantidade de entregas nos últimos períodos (ex. semanas ou sprints). Veja o gráfico abaixo, que mostra a quantidade de entregas realizadas ao longo de cinco sprints.

Observamos que nesse período tivemos entre 76 a 132 entregas, com um média de 108 entregas.

A taxa de entrega é distribuída de forma Gaussiana, i.e, podemos usar os valores das médias para projeções futuras. De forma simples, um gerente que observe o seguinte comportamento poderia se comprometer com 108 demandas para o próximo sprint. Isso cria um limite de entrada seguro, que te apresenta muitas vantagens gerenciais tais como:

  • Previsibilidade de entregas;
  • Estabilização do WIP;
  • Redução do tempo de entrega;
  • Contribuição para a criação de um sistema estável;

Um sistema estável é um sistema de entrega previsível – aquele que permite que você tome decisões baseadas em dados confiáveis e produz previsões probabilísticas precisas. Em sua forma mais simples, o fluxo de trabalho de entrega funcionará como um sistema estável quando você mantém um trabalho em andamento consistente e uma idade média consistente de trabalho em andamento ao mesmo tempo.

Usando a vazão para identificar gargalos e promover conversações ricas

Uma outra grande utilidade do gráfico de vazão é identificar gargalos. Considere o exemplo abaixo, que mostra um processo de trabalho com etapas de Análise, Desenho e Implementação e um processo de desenvolvimento de software.

Observe a coluna chamada de Throughput items/day, que significa a vazão média de saída. Podemos observar que a vazão média das etapas é diferente, sendo que a maior vazão é a etapa de análise (0.62) e a menor vazão é a etapa de testes (0.58). Observe, então, que a etapa de testes se apresenta com o gargalo do nosso sistema de fluxo.

Alguém apressado ou ingênuo poderia dizer. “A culpa é do time de testes”.

As razões, no entanto, podem ser muito mais complexas do que isso e podem envolver:

  • Dívida de fluxo (trabalho mal especificado ou mal desenvolvido, que provocam bloqueios e impedimentos na etapa de testes)
  • Trabalho em progresso alto na etapa de testes.
  • Um processo de engenharia de testes ruim, com muito esforço e retrabalho manual.

No mundo real, identificar os gargalos permitem que possamos criar conversações ricas entre os times de forma e reequilibrar o fluxo. Um fluxo saudável deve habilitar uma vazão média similar ao longo das etapas, que contribui também para melhorar a estabilidade do sistema.

Métrica de vazão – Um canivete suíço para a sua gestão

A vazão (de entrada e saída) é um ferramenta poderosa para a sua gestão. Com ela você pode:

  • Observar se o seu sistema está instável, com demanda e capacidade desequilibrados.
  • Controlar o WIP (trabalho em progresso)
  • Reduzir a sobrecarga no time
  • Equilibrar a demanda e a capacidade
  • Reduzir tempos de entrega
  • Melhorar a saúde do seu sistema de trabalho.

Use o fluxo cumulativo de valor como ponto de partida para compreender como o trabalho e chega e parte do seu sistema de trabalho e pouco a pouco comece a equilibrar o seu trabalho.

Quatro Métricas Essenciais para Melhorar o Seu Processo Ágil — Parte 3: Eficiência de Fluxo

~ Marco Mendes ~ 1 comentário

É quarta-feira 9:00 da manhã. Você recebe uma missão do seu chefe de montar um relatório importante para a diretoria. Ele confia no seu trabalho e delega isso a você. Você estima o trabalho e calcula criteriosamente que 8 horas vão ser suficientes. O seu chefe, astuto, racionaliza que o relatório estará na mesa dele Quinta-Feira cedo! Ele está bem animado.

Você inicia o trabalho e começa o seu relatório. Mas hoje é uma meio de semana e o seu WhatsApp está frenético. E o seu telefone também não para. Você é interrompido várias vezes. E, para piorar, surgiu uma urgência em produção que requer a sua atenção… AGORA. No final do dia, você faz o seu apontamento de horas e observa que não teve mais que 2 horas para se concentrar no relatório.

Quinta-Feira chega. Uma novo dia. Vai ser melhor, você pensa. E você começa a trabalhar no seu relatório. Mas observa as 9:30 que os dados que você precisa foram extraídos com erro de intervalo de datas e você vai precisar da ajuda do seu colega de trabalho que trabalha na área de BI. Com urgência você liga para ele para solicitar as informações. Mas a fila dele é maior que a sua! E ele não pode parar o que ele está fazendo agora. Você está parado também pois as suas análises dependem dos dados corretos. E você precisa esperar até que ele lhe retorne.

Agora já se passou um dia e meio quando você finalmente recebe o email dele com os dados correto. Agora é Sexta-Feira, 15:00. Você está realmente muito cansado e não consegue se concentrar muito mais. Depois de 2 horas trabalhando, seu cérebro já está travado. Sua família lhe liga, demandando a sua atenção. Você encerra a semana.

Agora é Segunda-Feira, aquele dia onde você tem várias reuniões. Toda a sua manhã está ocupada. Finalmente, você consegue foco no turno da tarde. Você se concentra e depois de 3 horas mágicas, com poucas interrupções, você termina o seu trabalho. Você envia o email com o documento para o seu chefe as 18:00.

Terça-Feira se passa e você não recebe nenhum retorno do seu chefe. Você, preocupado, tenta entender o porque. E descobre que ele precisou fazer uma viagem para São Paulo para visitar um cliente muito importante. Ele irá retornar de viagem apenas Quarta-Feira à noite.

Agora é Quinta-Feira, 10:00 da manhã. Mas da semana seguinte à promessa manifestada na mente do seu chefe. Ao receber o email, ele observa que o relatório está razoável e o aceita. Mas ele está profundamente irritado com o atraso. “Como você me entrega o relatório com 7 dias de atraso?”

Você fica confuso. Na sua mente, você foi muito eficiente. Você prometeu que trabalharia 8 horas no relatório. E você foi melhor, certo? Você trabalhou 7 horas e entregou o seu relatório. Mas na mente do seu chefe, o relógio é claro. Ele esperou 8 dias pelo relatório. E por isso está tão bravo com você.

Eficiência de Fluxo

Podemos definir a eficiência de fluxo é relação do tempo onde realmente trabalhamos com o tempo total medido no relógio.

No nosso exemplo acima, baseado em uma triste história real, o tempo trabalhado foi de 7 horas. Mas o tempo decorrido no relógio até o aceite do trabalho foi de 48 horas úteis. E portanto podemos calcular a real eficiência na montagem do relatório, conforme mostrado abaixo.

Como a eficiência de fluxo pode ter sido tão baixa na montagem desse relatório?
É simples, se observamos a narrativa. Lá iremos encontrar:

  • Interrupções
  • Impedimentos
  • Bloqueios
  • Esperas
  • Filas
  • Dependências de outros times
  • Cansaço humano

E o que pode aparentar um caso isolado, é infelizmente um fato comum no trabalho do conhecimento. Especialistas no trabalho de fluxo como Troy Mageniss, Vasco Duarte, Donald Reinertsen já mostraram evidências sólidas que a eficiência de fluxo no trabalho do conhecimento é entre 5 a 15%.

David Anderson, líder da comunidade Kanban, nos apresenta uma heurística simples para você observar a sua eficiência de fluxo. Meça a relação do tempo gasto em um trabalho que foi realmente urgente na sua empresa o tempo médio que o trabalho demora para fluir nesse mesmo tipo de trabalho. Ele usou esse racional para mostrar que a eficiência de fluxo para produzir uma vacina não é maior que 10%, quando comparamos o tempo recorde de 10 meses para produzir a vacina da COVID contra o tempo típico observado em casos comuns, que é de 10 anos ou mais.

O fato concreto e matemático aqui é que não devemos colocar atenção inicial se o nosso liderado é “eficiente”, no sentido comando e controle da palavra. O foco deveria ser observar como o trabalho flui pelo sistema. E por isso a eficiência de fluxo é uma métrica tão poderosa para observar o trabalho em times ágeis.

Por que as nossas estimativas falham?

Quando pedimos para alguém para estimar quanto tempo levará para desenvolver uma funcionalidade ou projeto, a pessoa pensa em quanto tempo levaria com uma entrega perfeita entre equipes e outros funcionários com as habilidades especializadas. 

Isso nunca acontece!

O trabalho espera em filas; as pessoas trabalham em mais de um projeto de cada vez; as pessoas tiram férias, as pessoas são interrompidas, as pessoas ficam bloqueadas, as pessoas tem problemas pessoais, as pessoas se cansam ao longo da semana.

Troy Mageniss afirma, com sabedoria: “Estimamos o trabalho, quando precisamos estimar quanto tempo esse trabalho leva para passar por um sistema complexo, dado todas as suas falhas”, Troy Mageniss

De fato, o trabalho do conhecimento flui através de um sistema de trabalho. Sem entender como esse sistema funciona através de métricas como a eficiência de fluxo, o melhor que podemos fazer é estimar um dia de engenharia “perfeito”. E esperar um dia de engenharia “perfeito” é puro pensamento mágico – Wishful Thinking.

Como medir a eficiência de fluxo no meu time Scrum?

Sabemos que o método Kanban e o KMM são esteroides naturais para implementações baseadas em Scrum. Alguns padrões visuais nos ajudam a evidenciar os vilões invisíveis que afetam a produtividade dos times. Apresento nesse artigo aqui três padrões úteis para o seu dia a dia.

Padrão 1 – Filas

No padrão acima evidenciamos os estágio em filas (sub-colunas Pronto). Isso é muito pois permite evidenciar o trabalho que está parado pois ainda não foi puxado pelo estágio de conhecimento seguinte. Por exemplo, vemos que os trabalhos #3, #5 e #7 estão parados. Se o tempo parado for alto, isso pode evidenciar que existem gargalos no estágio em verificação causados por dívida de fluxo, trabalho desbalanceado ou outros motivos que podem ser investigados nas reuniões diárias ou retrospectivas.

Times com mais maturidade avaliam, inclusive, o tempo de ciclo de cada estágio e sub-estágio. Isso permite que você calcule a ineficiência de fluxo do seu sistema de trabalho causada apenas pelas filas.

Da minha experiência implementando sistemas Kanban, observo que filas contribuem com 30, 40 ou até mesmo 50% de ineficiências em fluxo.

Padrão 2 – Impedimentos, Bloqueios, Defeitos

Na figura acima vemos que o trabalho #6 está impedido. Podemos então usar o Kanban para evidenciar os impedimentos, bloqueios, defeitos e qualquer coisa que impeça o trabalho de fluir da esquerda para a direita.

Times com maturidade em sistemas de fluxo atacam em base diária nas reuniões diárias bloqueios, impedimentos e outros ofensores do fluxo. Ter isso evidenciado, portanto, é o primeiro passo.

Times com mais maturidade medem também qual a razão do bloqueio e o tempo que o trabalho ficou bloqueado. Isso permite que façamos, de tempos em tempos, uma reunião de análise de bloqueios agrupados. Isso gera muito aprendizado e oportunidade de melhorar a colaboração dentro do time e a cooperação entre gerências distintas.

Padrão 3 – Esperas por Grupos Externos

Se você trabalha em uma grande empresa, provavelmente o serviço que o seu time está envolvido depende, também, de múltiplos outros times. Em um diagnóstico que estou trabalho para um serviço complexo de uma empresa, observamos dependências de dez outras áreas! E isso é um sinal que provavelmente a eficiência de fluxo será muito baixa nesse ambiente.

Para isso, buscamos evidenciar no quadro Kanban uma sub-coluna para evidenciar, onde necessário, a espera por grupos externos. Isso permite que você compreenda o tempo gasto nessas esperas e gere oportunidade de criar maior cooperação gerencial entre áreas.

O método Kanban e o Kanban Maturity Model apresenta diversos outros padrões para você evidenciar problemas de ineficiência. Aqui nós apenas arranhamos o assunto com algumas possibilidades.

A Atenção do Líder Inteligente

O líder inteligente sabe que o grande problema no tempo de entrega não está na “produtividade” do indivíduo. O grande problema está nos 80 ou 90% do tempo desperdiçados em filas, bloqueios, impedimentos, esperas e outras fontes de ineficiências.

Já o gerente ingênuo ainda acredita que o problema está na produtividade do indivíduo. E daqui derivam os comportamentos de microgerenciamento tão comuns no mercado.

A boa notícia é que você pode escolher ser um líder inteligente. Para isso, comece a medir a sua eficiência de fluxo agora.

“Ausência de evidência não é evidência de ausência”, Carl Sagan

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

~ Marco Mendes ~ 3 Comentários

É 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: Dê–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 vendo 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

~ Marco Mendes ~ 2 Comentários

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

~ Marco Mendes ~ 4 Comentários

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. 

Um sistema ruim sempre derrota pessoas boas

~ Marco Mendes ~ 1 comentário

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

~ Marco Mendes ~ Deixe um comentário

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

~ Marco Mendes ~ Deixe um comentário

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.