Poka Yoke en Scrum o el Procedimiento de Emergencia

La primera vez que escuché el término Poka-Yoke fue del propio Jeff Sutherland (te dejo la Entrevista que hice a Jeff Sutherland (Co-creador de Scrum)), con el que tuve la suerte de compartir unos días en Estocolmo, compartiendo, disfrutando y aprendiendo.

Poka-Yoke es un término japonés que significa algo así como «a prueba de errores», Poka vendría a ser “error” y Yoke “evitar”. Un Poka-Yoke es cualquier técnica o práctica que ayuda a evitar un error por parte de cualquier persona del equipo de trabajo. Hay un montón de ejemplos en nuestro día a día, como la cantidad de clavijas que sólo se pueden conectar de una manera, la correcta, para evitar el error humano y romper algo. El objetivo es eliminar los defectos mediante la prevención, la corrección o llamando la atención sobre los errores que se producen.

Las técnicas y prácticas Poka-Yoke fueron introducidas en el popular, ya mítico, sistema de producción de Toyota, aquel que hoy conocemos como Lean (te dejo aquel post de de dónde viene el Lean, el Lean Software Development y por qué se asocia con la agilidad).

Su aplicación al mundo Ágil, concretamente, en el caso que aquí nos centra, al uso de Scrum, es bastante obvia y necesaria (si bien su aplicación puede darse a casi cualquier cosa), hasta el punto de que Jeff Sutherland escribió un patrón de Scrum llamado “Procedimiento de Emergencia” inspirado en el Poka-Yoke y en los procedimientos de emergencia de los aviones (luego te cuento por qué).

La idea viene a ser la siguiente, si desarrollando un Sprint, durante el transcurso del mismo, se llega a la conclusión de que es imposible terminarlo con éxito… hay que hacer saltar la alarma lo más pronto posible. Es lo que cuentan que pasa en las cadenas de montaje japonesas, cualquiera puede parar el proceso cuando detecta un error, ya que es más barato parar y arreglar que dejarlo pasar a siguiente etapas.

Las causas por las que un Sprint no va a tener éxito son innumerables, típicamente van desde que se meten necesidades que no se esperaban, malas estimaciones, problemas técnicos, etc.

La agilidad requiere una respuesta rápida al cambio y esto choca con que haya miedo para hacer visibles los problemas. Por ello, y como hacen los pilotos de cazas cuando las cosas no van bien (ejemplo literal que usa Jeff Sutherland para contar eso, ya que fue piloto de cazas), ten previsto con anterioridad un “Procedimiento de Emergencia” a ejecutar en estos casos.

Y cuando las cosas van mal, NO se demora la ejecución del “Procedimiento de Emergencia”. Ejecución sin demora que, además, es responsabilidad del Scrum Master, en acción coordinada con el Product Owner (lo cual no implica que éste dé permiso para ello).

El “Procedimiento de Emergencia” puede ir por escalas, desde la más leve, por ejemplo, “cambiar el alcance del Sprint”, pasando por “reducir el alcance”, o llegando hasta la “cancelación” o informar al resto de la organización sobre el impacto que tendrán los problemas actuales en el Sprint.