Sistemas de entrega en lugar de checklists

El error más común que veo en equipos de ingeniería, y uno que yo mismo cometí, es tratar la entrega lenta como un problema de velocidad.

Generalmente no lo es. Es un problema de sistema.

Cómo se siente una cultura de checklists

Sabes que estás en una cultura de checklists cuando la respuesta del equipo a un deadline fallado es agregar más pasos al proceso. Hay una retrospectiva. Se agregan ítems a una lista. Aparece un nuevo campo en Jira. Se programa un recordatorio recurrente.

Nada de eso aborda por qué se falló el deadline. Solo agrega fricción a cada entrega futura a cambio de la sensación de haber hecho algo al respecto.

Gestioné un equipo así durante aproximadamente un año. Teníamos un checklist detallado de sprint. Pasos de QA, pasos de despliegue, pasos de release notes. Al final del año, el checklist tenía 27 ítems y el equipo odiaba los viernes. Éramos más lentos que cuando empezamos.

Dónde los checklists sí funcionan

Los checklists son valiosos en dos contextos: repetición exacta con alto riesgo (pilotos, cirujanos, rollbacks de despliegue), y para incorporar personas nuevas a procedimientos establecidos.

La entrega de software no es ninguna de las dos. El trabajo cambia cada sprint. La composición del equipo cambia. El producto cambia. Un checklist construido para el trimestre pasado es un pasivo este trimestre: te dice qué hacer sin decirte por qué, así que nadie lo cuestiona cuando deja de tener sentido.

Cómo se ve un sistema en cambio

Un sistema de entrega responde una pregunta diferente que un checklist. No “¿qué pasos seguimos?” sino “¿qué condiciones necesitamos mantener para que el equipo entregue de forma consistente?”

Las condiciones que he encontrado que más importan:

Ownership claro a nivel de ticket. No ownership de equipo. Ownership de persona. Si dos personas son dueñas de algo, nadie lo es.

Un definition of done compartido. No un checklist, sino una definición compartida de qué significa “listo”. Parece obvio y casi nunca es explícito. He visto equipos debatir si algo está listo en reuniones de sprint planning porque nadie lo escribió.

Un ritmo semanal que expone bloqueos, no estatus. El estatus es lo que ya hiciste. Los bloqueos son lo que impide lo siguiente. La mayoría de los standups sacan a la superficie la cosa equivocada.

Una retro post-release con exactamente una mejora. No una lista de mejoras. Una. La que realmente implementarás antes de la próxima retro.

La parte incómoda

Construir un sistema de entrega implica resistir el impulso de agregar más proceso cuando algo se rompe. El instinto es parchear el hueco. La acción correcta es generalmente preguntarse si el sistema subyacente falló primero: claridad de ownership, que todos manejen las mismas definiciones, el ritmo del equipo.

En mi experiencia, casi siempre lo hizo.