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

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

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

Reunião diária zombie

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

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

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

Trabalho empurrado

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

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

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

Métricas míopes

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

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

Servidão ao backlog

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

Projetos centrados em escopo fixo e prazo aberto

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

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

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

Antídotos ao Scrum Medíocre

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

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

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

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

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

Trabalho puxado (Antídoto para o trabalho empurrado)

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

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

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

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

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

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

Por quê?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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