Hacer las Políticas Explícitas

Las reglas implícitas crean problemas:

• Las personas hacen diferentes suposiciones
• Surgen conflictos sobre "cómo hacemos las cosas"
• Los nuevos miembros del equipo no conocen las reglas no escritas
• Las mejoras son difíciles porque la línea base no está clara

Las políticas explícitas son acuerdos escritos y visibles sobre cómo fluye el trabajo a través de tu sistema.

No tienen que ser complejas. "Revisamos PRs en 4 horas" es una política. "Los elementos bloqueados van al inicio de la columna" es una política. "QA solo comienza si las pruebas unitarias pasan" es una política.

Criterios de entrada: ¿Qué debe ser cierto para que el trabajo entre a una etapa?

• "Listo para Dev: Criterios de aceptación escritos, diseños adjuntos"
• "Listo para Revisión: Todas las pruebas pasando, sin commits WIP"

Criterios de salida (Definición de Terminado): ¿Qué debe ser cierto para salir?

• "Desarrollo Terminado: Código revisado, CI en verde, docs actualizados"

Límites WIP: ¿Cuántos elementos pueden estar en esta etapa?

• "Dev: Máximo 3 elementos en progreso"

Políticas de manejo: ¿Qué sucede en situaciones específicas?

• "Bloqueado: Agregar etiqueta de bloqueo, discutir en standup, escalar después de 24 horas"
• "Conflicto de prioridad: El dev senior decide, escalar al líder si es necesario"

Políticas de tiempo: ¿Expectativas sobre tiempos?

• "Revisiones de código completadas en 4 horas laborales"
• "QA comienza dentro de 1 día de estar listo"

Políticas de selección: ¿Cómo elegimos en qué trabajar después?

• "FIFO dentro de la clase de prioridad"
• "Bugs de cara al cliente antes que problemas internos"

Las políticas deben ser visibles, no enterradas en documentos que nadie lee.

Opciones:

• En el tablero: Escribe las políticas arriba o al lado de cada columna
• Documento vinculado: Mantén un documento vivo de políticas, enlázalo desde el tablero
• Tooltip/hover: Los tableros digitales a menudo soportan descripciones de columnas
• Tarjeta de encabezado: La primera tarjeta en cada columna describe la política

La prueba: ¿Puede un nuevo miembro del equipo entender las políticas en 5 minutos de mirar el tablero?

Cadencia de revisión: Las políticas no son estáticas. Revísalas en retrospectivas:

• ¿Estamos siguiendo esta política?
• ¿Esta política está ayudando o perjudicando?
• ¿Qué falta?

Las políticas impuestas no se mantienen. Las políticas colaborativas sí.

Proceso para crear políticas:

1. Observar la práctica actual: "¿Cómo decidimos realmente en qué trabajar después?"
2. Revelar desacuerdos: "¿Parece que Alice toma lo más antiguo, pero Bob toma lo más pequeño?"
3. Discutir compensaciones: "¿Cuáles son los pros y contras de cada enfoque?"
4. Acordar la política: "Intentemos FIFO durante las próximas dos semanas"
5. Hacerla visible: Escríbela en el tablero
6. Revisar y adaptar: "¿Cómo funcionó FIFO? ¿Deberíamos ajustar?"

Principio clave: Las políticas son experimentos, no mandamientos. Si una política no está ayudando, cámbiala.

Sobre-documentación: 20 políticas por columna que nadie lee. Comienza con 2-3 políticas esenciales por etapa.

Falta de aplicación: Las políticas existen pero se ignoran rutinariamente. O las aplicas o las eliminas.

Reglas rígidas: "Nunca romper el límite WIP bajo ninguna circunstancia." La realidad es más desordenada. Permite el juicio mientras haces visible la excepción.

Escalamiento faltante: ¿Qué sucede cuando las políticas entran en conflicto o se rompen? "Si se alcanza el límite WIP y llega trabajo urgente, escalar al líder del equipo."

Políticas obsoletas: Reglas de hace seis meses que ya no encajan. Revisa las políticas regularmente.

Políticas individuales: "El trabajo de Bob no pasa por revisión de código." La equidad importa. Las políticas deben aplicarse al trabajo, no a las personas.