Publiquei na semana passada um post sobre disfunções ágeis comuns na implementação do framework Scrum.
São elas.
- Reunião diária Zombie
- Trabalho empurrado
- Métricas míopes
- Servidão ao backlog
- Escopo fixo e prazo aberto
Apontamos também alguns antídotos para essas disfunções, que são:
- Pergunte ao quadro Kanban
- Trabalho puxado
- Métricas acionáveis
- Gestão do upstream
- Fluxo contínuo e MVPs
Caso ainda não tenha lido recomendo a leitura para contexto.
Dando sequência ao tema de disfunções ágeis, relato aqui mais disfunções ágeis que podem drenar todo o dinheiro da sua iniciativa ágil como um chupa-cabra de métodos ágeis. Mais à frente, apresentamos antídotos para esses problemas.
Mais 5 disfunções ágeis
-
Critério de preparado (Ready) ausente ou mal especificado
Um problema comum em vários times que operam Scrum é não estabelecer um acordo claro para aceitar um requisito e iniciar a sua construção. Isso se manifesta com reuniões de planejamento longas e cansativas e, pior, problemas de entendimento que acompanham a sprint e um número excessivo de defeitos de negócio em ambientes de produção.
2. Critério de aceite (Acceptance) ausente ou mal especificado
É também comum quando POs novatos ou que estendem a confiança ingenuamente não definem os critérios de aceite funcionais e não-funcionais externos, como por exemplo a usabilidade, performance ou segurança.
“O óbvio é individual”, já disse um sábio certa feita. Assumir que o time de engenharia de produtos irá incorporar aspectos de qualidade porque aquilo é óbvio é uma decisão ingênua.
3. Critérios internos de qualidade ausentes
Quando desenvolvedores e QAs olham apenas para os requisitos funcionais, uma dívida técnica será naturalmente introduzida dentro do sistema. A razão é a entropia crescente nesses sistemas complexos. Exemplos incluem:
- Ausência de automação de testes
- Códigos-fonte sujos (mal-cheiros)
- Arquiteturas de software erodidas
- SQLs ineficientes
- Problemas de segurança
Se um time não age proativamente e introduz políticas para pagamento permanente da dívida técnica, os sistemas irão apenas degradar ao longo do tempo e eventualmente gerarem problemas gravíssimos para suas áreas de negócio.
4. Ausência de folgas (Slack) e previsibilidade inconsistente
Tom de Marco escreveu um livro muito instigante em 2001 (Slack) mostrando a estupidez da hiper-otimização dos trabalhadores do conhecimento e os seus efeitos ruins para as pessoas e também para a própria organização em médio e longo prazo.
Nicholas Taleb também nos adverte, de forma ainda mais contundente no seu livro Antifragilidade – Coisas que se beneficiam do caos, da fragilidade inerente de organismos hiper-otimizados. A natureza e os sistemas complexos amam redundâncias.
Donald Reinertsen, outro grande pensador, nos mostra também que sistemas de trabalho ocupados afetam brutalmente e negativamente a previsibilidade de entrega de novas funcionalidades.
Assumir que alguém trabalha exatamente 7 ou 8 horas por dia e tentar alocar o esforço de pessoas como se fossem máquinas é ruim economicamente para a organização, psicologicamente para as pessoas e também para a previsibilidade de entregas.
Em linguagem simples, você observa essa disfunção através de sprints “que falham”, i.e, não entregaram todo o “escopo” porque as pessoas não “trabalharam” de forma eficiente. Ou titica de galinha sobre esterco de vaca.
5 – Heroísmo. Ou síndrome de Tanus.
Outra disfunção comum é esperar que pessoas e times ágeis irão ter comportamentos heróicos e irão fazer o que for necessário para bater as “metas” definidas pela gerência.
O heroísmo na construção de produtos digitais é um fenômeno estudado há décadas. E a “má notícia” é que não existem heróis. Você não está em um filme de espionagem onde hackers com “intelecto avançado” teclam um monte de comandos mágicos e o sistema começa a operar. E até nos filmes mais recentes, basta alguém estalar os dedos e metade dos heróis vai embora.
Modelos de maturidade mais modernos, como por exemplo o excelente Kanban Maturity Model, mostram que o heroísmo é um sintoma de serviços de baixa maturidade (ML1). Não é algo sustentável em médio e longo prazo e impede a criação de serviços previsíveis e aptos para o propósito de negócio.
Mais Antídotos
1. Gestão do Upstream (para o critério de Preparado mal especificado)
A gestão de upstream é uma técnica descrita no KMM (Kanban Maturity Model) e assunto central do livro Essential Upstream Kanban.
Entre o Upstream (território do PO) e o Downstream (território da engenharia e Scrum Masters) existe o ponto de compromisso que precisa ser bem estabelecido através de políticas explícitas, prática geral de todo sistema Kanban maduro.
2. Compromisso em duas fases (Two Phase Commit)
Sistemas de trabalho bem estruturados devem ter não apenas o ponto de compromisso bem estabelecido para iniciar o trabalho. Devem ter também o ponto de compromisso onde o trabalho seja aceito. E para isso precisamos ter políticas explícitas indicam como o trabalho deve ser entregue para ser considerado como finalizado.
Se você quer que o seu copo de água seja servido em copo de vidro, com duas pedrinhas de gelo e uma rodela de limão siciliano, explicite isso no começo do jogo. O combinado não é caro.
O Two Phase Commit é uma técnica Kanban que reduz, semana após semana, a ambiguidade para iniciar e fechar um trabalho do conhecimento. Ela permite que você crie critérios de preparado e de aceite incrementais e que funcionem na sua realidade objetiva.
3. Critérios internos de qualidade
Ninguém em sã consciência pede para um cozinheiro não lavar as verduras para apressar o preparo dos pratos. E provavelmente cozinheiros profissionais não aceitariam essa proposta estranha. Lavar as verduras é dever ético e de higiene em uma cozinha profissional.
Da mesma forma, nenhum desenvolvedor deveria negociar aspectos básicos da higiene do seu código no dia a dia. Refatorar e fazer testes de unidade devem ser parte integrante e diária do trabalho. Como tomar banho e escovar os dentes. E não um trabalho adicional que deveria ter permissão gerencial.
Lógico. Falar isso é fácil. E reconheço que isso é ainda muito difícil em ambientes abusivos onde metas de prazo são impostas de cima para baixo e não descobertas pela vazão do time.
Mas é dever ético de qualidade de um time expor e brigar por seus critérios internos de qualidade. Git Pull Requests, Pair Programming, Mob Programming, Testes de Unidade, Refatoração, entre outras práticas, são exemplos nesse sentido.
E se você quiser se armar com argumentos sólidos para conversar com a sua chefia, recomendo dois clássicos a respeito do sempre incansável Uncle Bob, um dos signatários do Manifesto Ágil de 2001.
4. Limitar o trabalho em progresso, políticas explícitas e gestão do fluxo (para atacar o problema de previsibilidade)
Times sem políticas de limitação do trabalho e outras políticas explícitas são facilmente abusados no seu dia a dia. Um dos papéis de um sistema de trabalho é conhecer e estabelecer a capacidade de trabalho apropriada para um time em um contexto real de forma a:
- Reduzir os prazos de entrega
- Reduzir a variabilidade.
Fato curioso é que o tempo médio de entrega é inversamente proporcional ao volume de trabalho em progresso, como já nos mostrou John Little ainda nos anos 60 na sua Lei de Little.
Quando você introduz sistemas Kanban sobre times que estão operando o framework Scrum, você ganha consciência da utilização de trabalho mais apropriada para aquele time e evita problemas de sobrecarga que se manifestam como engarrafamentos (muita coisa para fazer, muito estresse, pouca vazão e resultados pífios).
5. Limitar o trabalho em progresso, políticas explícitas e gestão do fluxo (para atacar o problema de heroísmo)
O heroísmo é sintoma de um sistema de trabalho frágil, i.e., onde as metas são impostas de cima para baixo sem conhecer a vazão possível e ideal dos times. É um sintoma de um sistema desequilibrado, onde medições não são realizadas consistentemente, onde políticas corretas estão ausentes e sistemas de feedback não estão instalados.
Novamente, o mesmo antídoto aplicado no item 4 pode ser usado para identificar as causas raízes que levam aos atos de heroísmo, introduzir hipóteses de melhoria e com base no pensamento científico testar e manter as hipóteses que melhorem o sistema de trabalho. Através de um processo contínuo de melhorias através da abordagem de mudanças evolucionárias, criamos um sistema robusto de trabalho em médio e longo prazo.
A mensagem desse post é simples. Faça uso do sistema de gestão de mudanças Kanban para melhorar o seu trabalho como Scrum Master.
Marco Mendes 