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. 

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

~ Marco Mendes ~ Deixe um comentário

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

~ Marco Mendes ~ Deixe um comentário

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

~ Marco Mendes ~ Deixe um comentário

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.