Os 7 desperdícios (Muda) e o 8º princípio Ágil: equilíbrio através da eliminação

No Toyota Production System (TPS), desperdício (Muda) significa aquilo que não agrega valor para o cliente, ou seja, atividades que são realizadas e que o cliente não está disposto a pagar. Existem sete tipos de Muda que, na literatura, também são conhecidos como “Os 7 desperdícios do Lean”. Um processo ágil verdadeiro é capaz de identificar e remover desperdícios prontamente promovendo desenvolvimento sustentável do produto, processo e de pessoas.

1. Transporte (de material)

Transporte é o deslocamento de materiais de um local para o outro. Representa um custo que não adiciona valor para o produto, mas que aumenta o risco de um produto ser danificado, perdido ou atrasado.

Dado haver intangibilidade no desenvolvimento de software, não há materiais físicos sendo processados. Contudo, fazendo uma analogia com a manufatura, materiais seriam os artefatos produzidos por um time como, por exemplo, user stories. O cliente não paga por user story. O cliente não está interessado em saber quantas user stories foram criadas para entregar uma funcionalidade. O transporte, neste caso, seria o deslocamento de uma user story desde o product backlog (estoque) até a sua entrega em produção. Uma user story com bugs, com critério de aceite não definido ou até mesmo grande demais para ser trabalhada em uma sprint são exemplos de riscos que podem danificar o produto, perder valor ou atrasar a sua entrega para o cliente.

Outra forma de enxergar o transporte seria os itens de trabalho de uma sprint: os itens são repriorizados constantemente, há muita troca de contexto, interrupções, tarefas são movimentadas de um lado para o outro no board do time e não há foco. Há também o transporte de informações entre um departamento e outro ou entre o time e os stakeholders: detalhes que precisam ser alinhados antes de considerar uma user story ready consomem tempo e recursos. Isso tudo representa desperdícios e custos que o cliente não está pagando diretamente, porém custam para o projeto e comprometem a qualidade e o prazo das entregas.

2. Inventário (estoque)

Inventário representa desembolso de capital em algo que se não for processado imediatamente, não produz receita. Cada item ou material parado no estoque tem um custo (de armazenamento, transporte, etc.) que aumenta a medida que o tempo passa e esse item não é utilizado.

O estoque seria o product backlog de um time. Quanto mais ele cresce em quantidade de itens, maior é o custo de manutenção. São mais itens para priorizar e detalhar, com o passar do tempo alguns deles se tornam obsoletos, o mapeamento dos itens com as respectivas features leva mais tempo, daqui a pouco tem user story duplicada, as product backlog refinements são intermináveis e por aí vai.

Defeitos e incidentes parados por vários meses geram insatisfação dos clientes. Alinhe o que não será corrigido e remova do backlog. Débitos técnicos parados geram insatisfação do time uma vez que eles não tem espaço para melhorar o código e o custo de manutenção tende aumentar. Lembre-se: manter um backlog enxuto reduz diversos outros tipos de desperdícios.

3. Movimentação (de pessoal)

Segundo TPS, movimentação é qualquer dano causado pelo processo de produção, como desgaste natural do equipamento, lesões por esforço repetitivo ou acidentes imprevistos. Perda de tempo e esforço relacionados a movimentos desnecessários de pessoas geram desperdícios.

A forma como times/squads/tribos são configurados dentro de uma empresa, muitas vezes, mais atrapalha do que ajuda: problemas de comunicação, dependências, desalinhamento, dificuldade de gerenciar o backlog ou até mesmo mais de uma pessoa gerenciando o mesmo product backlog. Outro exemplo seria o Kanban board de um time com colunas que não fazem mais sentido ou não representam o fluxo atual de trabalho: falta de visibilidade, processo burocrático demais, tarefas movimentadas para frente e para trás constantemente, microgerenciamento desnecessário, etc.

As ferramentas homologadas pela empresa já não atendem mais as necessidades do time e as tecnologias utilizadas estão defasadas: executar o trabalho passa a ser mais oneroso, leva mais tempo, dá mais trabalho, tarefas simples tornam-se complexas, o time começa ficar cansado e estressado. Lembre-se: É saudável parar o time de tempos em tempos e refletir sobre como eles estão trabalhando, entender se o processo continua fazendo sentido e quais são as suas dores.

Eliminar esse tipo de desperdício compreende estudar o processo atual, entender como o trabalho é realizado e reorganizar o fluxo ou até mesmo prover novas ou melhores ferramentas visando otimizar o processo e melhorar o bem estar dos funcionários.

4. Espera

Produtos ou materiais que não estão em transporte ou sendo processados são desperdícios. Simple like that. É o tipo de desperdício mais comum, mais fácil de ser identificado e que causa grande impacto no lead e cycle time.

Se o board de um time tem as colunas “wait for code review”, “wait for testing” ou “wait por alguma outra coisa”, está aí a oportunidade perfeita de monitorar possíveis desperdícios: se os itens estão parados por muito tempo, alguma coisa está acontecendo e impactando o fluxo de trabalho. Incidentes abertos em produção que levam muito tempo até serem corrigidos: verifique o SLA e pense como otimizar o processo para agilizar o tempo de resposta. Uma user story que não pode ser testada, pois o ambiente de teste está indisponível também é outro exemplo de material que está parado, esperando alguém dar continuidade ao trabalho.

A daily é um ótimo momento para inspecionar “esperas”: não é muito difícil identificar a situação do tipo “estou esperando por algo”. Passa dois, três dias e o time continua esperando. Isso pode ser por falhas no processo, problemas de comunicação, desalinhamento de prioridades, user story que não estava pronta e necessita de informações do cliente, etc. Monitorar o tempo de espera (lead time) desde que uma user story foi criada até ser entregue em produção ou verificar quanto tempo os itens ficam parados no product backlog podem gerar bons insights sobre onde as perdas de espera estão acontecendo.

5. Super processamento (excesso de funcionalidade)

O super processamento pode acontecer quando é feito mais trabalho do que o necessário, ou quando as ferramentas são mais complexas, precisas ou caras do que o necessário. Em outras palavras se o produto final contém especificações, atributos ou funcionalidades não solicitadas pelo cliente ou se os recursos e tecnologias utilizadas na produção são mais complexos que o necessário, então custos que o cliente não está disposto a pagar (conceito de desperdício em sua forma pura) estão sendo adicionados na linha de produção gerando desperdícios.

Adicionar funcionalidades extras no produto, refatorar código no momento inadequado, não entender o problema real do cliente e desenvolver um produto baseado no achismo, testar dezenas de cenários sendo que a maioria nunca ocorrerá em produção, adicionar muitas etapas ou atividades tornando o processo de trabalho complicado demais e utilizar algoritmos complexos para resolver problemas simples são apenas alguns exemplos das diversas formas de elevar os custos do projeto ao adicionar trabalho que não agrega valor para o cliente.

Pro tip: sempre que for fazer algo, comece pelo porque. Por que estamos fazendo isso? Qual o propósito desta funcionalidade? Faz sentido fazer isso neste momento? Foi isso mesmo que o cliente pediu? Qual é o real problema que deveríamos solucionar? Essas perguntas poderosas com certeza evitarão super processamento.

6. Superprodução (excesso de quantidade)

Lotes maiores ou mais produtos sendo feitos do que o necessário. Se a produção é maior que a demanda do cliente ou a entrega contém mais itens que o acordado para aquele momento, então há desperdício. A superprodução é o desperdício mais perigoso, pois pode gerar outros tipos de perdas. Quando há superprodução, tem-se mais itens para transportar e manter no estoque, o tempo de espera pode aumentar assim como a incidência de defeitos, retrabalho e estresse. Tudo fica mais complexo do que deveria.

Na minha opinião, a superprodução e o super processamento andam juntos quando analisamos sob a ótica do desenvolvimento de software. Contudo, tentando isolar, seriam exemplos de superprodução: a) um item que foi acordado com o cliente para ser entregue daqui duas sprints, mas foi adicionado na sprint atual “just in case” gerando mais trabalho para o time e comprometendo os objetivos da sprint; b) trabalhar em sprints, porém entregar o produto somente no final (tipo um waterfall dentro do Scrum – clássico!), ou seja, trabalhar com prazos longos e sem incrementos gera demora no feedback e aumenta os custos do projeto em caso de retrabalho; c) uma pessoa que produz muito mais que as outras pode sobrecarregar as demais; e d) o PO produz itens de trabalho em um taxa superior à capacidade do time deixando-o sobrecarregado e estressado.

A pro tip nesse tipo de desperdício seria analisar os WIP Limits em toda a cadeia de valor, tanto no upstream quanto no downstream. Definir Max e Min WIP Limits ajuda manter o flow de trabalho balanceado evitando entregar de mais ou de menos. Além disso, definir objetivos (longo prazo) e metas (curto prazo) facilita o gerenciamento do product backlog. Entregar incrementos pequenos e com maior frequência evita sobrecarga no time e agiliza o ciclo de feedback com o cliente.

7. Defeitos

A definição da Toyota para esse tipo de desperdício é a seguinte: a perda envolvida na retificação de peças ou produtos defeituosos. Defeitos geram retrabalho, elevam os custos de produção, geram ou podem ser introduzidos através de irregularidades e sobrecarga em um sistema. Quanto mais tarde forem tratados, maior serão os custos e até mesmo a complexidade de correção.

Antes de trabalhar como Agile Coach & Scrum Master eu era QA. Então, eu posso afirmar que é comum defeitos serem introduzidos durante o desenvolvimento de software e que é melhor prevenir do que tentar detectá-los. Automatizar tarefas rotineiras e testes pode evitar dores de cabeça após uma refatoração de código ou uma implementação/ajuste em um componente bem antigo. TDD, BDD e ATDD são outras formas de prevenção de defeitos assim como pair programming e code review.

Pro tip: se um defeito for encontrado em um item de trabalho na coluna “In Test” ou “PO Validation”, então a sua correção deve ser priorizada para minimizar os custos e impactos na entrega.

O 8° princípio do Manifesto Ágil diz o seguinte: “Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente”. Sustentabilidade refere-se à busca pelo equilíbrio entre a disponibilidade e utilização de recursos. Um sistema balanceado é um sistema sem ou com baixo índice de desperdícios. Para alcançar um processo ágil os times necessitam ter a capacidade de identificar e remover desperdícios e, sobretudo, implementar mecanismos de prevenção visando maximizar a eficiência e a sustentabilidade na sua forma de trabalho. Um sistema livre de interrupções e distrações permite ao time ter mais tempo para focar no essencial, no que de fato agrega valor.

Por onde começar?

Para obter maior impacto e melhores resultados, a eliminação de desperdícios deve acontecer em toda a cadeia de valor. Contudo, começar por onde você está é uma boa opção. Apresente os sete tipos de desperdícios para o time e questione duas coisas: 1) “O que tem que ser eliminado no nosso processo?” e 2) “Como eliminar?”. A menos que o processo seja 100% independente, isolado do resto da organização, será necessário envolver diversos stakeholders para coletar feedback e gerar insights sobre o que e como eliminar desperdícios visando melhorar o fluxo de trabalho.