Tornar as Políticas Explícitas

Regras implícitas criam problemas:

• As pessoas fazem suposições diferentes
• Conflitos surgem sobre "como fazemos as coisas"
• Novos membros da equipe não conhecem as regras não escritas
• Melhorias são difíceis porque a linha de base não está clara

Políticas explícitas são acordos escritos e visíveis sobre como o trabalho flui pelo seu sistema.

Elas não precisam ser complexas. "Revisamos PRs em até 4 horas" é uma política. "Itens bloqueados vão para o topo da coluna" é uma política. "QA só começa se os testes unitários passarem" é uma política.

Critérios de entrada: O que deve ser verdadeiro para o trabalho entrar em uma etapa?

• "Pronto para Dev: Critérios de aceitação escritos, designs anexados"
• "Pronto para Revisão: Todos os testes passando, sem commits WIP"

Critérios de saída (Definição de Pronto): O que deve ser verdadeiro para sair?

• "Desenvolvimento Pronto: Código revisado, CI verde, documentação atualizada"

Limites WIP: Quantos itens podem estar nesta etapa?

• "Dev: Máximo de 3 itens em progresso"

Políticas de tratamento: O que acontece em situações específicas?

• "Bloqueado: Adicionar tag de bloqueio, discutir no standup, escalar após 24 horas"
• "Conflito de prioridade: Dev sênior decide, escalar para o líder se necessário"

Políticas de tempo: Expectativas sobre prazos?

• "Revisões de código concluídas em até 4 horas úteis"
• "QA começa em até 1 dia após estar pronto"

Políticas de seleção: Como escolhemos o que trabalhar a seguir?

• "FIFO dentro da classe de prioridade"
• "Bugs voltados ao cliente antes de problemas internos"

As políticas devem ser visíveis, não enterradas em documentos que ninguém lê.

Opções:

• No quadro: Escreva as políticas acima ou ao lado de cada coluna
• Documento vinculado: Mantenha um documento vivo de políticas, vincule do quadro
• Tooltip/hover: Quadros digitais frequentemente suportam descrições de colunas
• Card de cabeçalho: Primeiro card em cada coluna descreve a política

O teste: Um novo membro da equipe consegue entender as políticas em até 5 minutos olhando para o quadro?

Cadência de revisão: As políticas não são estáticas. Revise-as nas retrospectivas:

• Estamos seguindo esta política?
• Esta política está ajudando ou atrapalhando?
• O que está faltando?

Políticas impostas não funcionam. Políticas colaborativas sim.

Processo para criar políticas:

1. Observe a prática atual: "Como realmente decidimos o que trabalhar a seguir?"
2. Revele desacordos: "Parece que Alice pega o que é mais antigo, mas Bob pega o que é menor?"
3. Discuta trade-offs: "Quais são os prós e contras de cada abordagem?"
4. Concorde com a política: "Vamos tentar FIFO pelas próximas duas semanas"
5. Torne-a visível: Escreva no quadro
6. Revise e adapte: "Como funcionou o FIFO? Devemos ajustar?"

Princípio-chave: Políticas são experimentos, não mandamentos. Se uma política não está ajudando, mude-a.

Documentação excessiva: 20 políticas por coluna que ninguém lê. Comece com 2-3 políticas essenciais por etapa.

Aplicação insuficiente: Políticas existem mas são rotineiramente ignoradas. Ou as aplique ou as delete.

Regras rígidas: "Nunca quebre o limite WIP sob nenhuma circunstância." A realidade é mais complexa. Permita julgamento enquanto torna a exceção visível.

Escalação ausente: O que acontece quando as políticas entram em conflito ou falham? "Se o limite WIP for atingido e trabalho urgente chegar, escalar para o líder da equipe."

Políticas obsoletas: Regras de seis meses atrás que não se encaixam mais. Revise as políticas regularmente.

Políticas individuais: "O trabalho do Bob não passa por revisão de código." Justiça importa. Políticas devem se aplicar ao trabalho, não às pessoas.