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.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024
Me sorprende este post. por una parte me alegra y por otra me despista.
Es decir, en los cursos y actual trabajo con scrum el sprint debe estar bien claro, analizado y entendido por todo el equipo por lo que los errores técnicos que obliguen a detener un sprint no debieran existir al igual que una mala estimación y si metes necesidades que no estaban previstas es que algún product Owner ni esta jugando con las mismas reglas por lo que es obvio que no se cumplirá el Sprint salvo que saques algo equivalente.
Me alegra este post por que es algo que ocurre con mucha frecuencia la cual nunca se cuenta en los cursos ni en ningún sitio, parece todo un cuento de hadas y me apena por que al final son procedimientos que se usan en otras metodologías tradicionales. Siempre el caso esta en cuando levanta alguien la liebre para avisar de que se va mal o no se llega y cambiar la planificación o tareas.
Javi, contéstame una cosa, si tienes unas entregas con n sprint previstos, desglosados los puntos de historia en la pila, con un burndown de la pila que te dice cuando vas a terminar y es lo acordado con el cliente si vas introduciendo estos procedimientos de emergencia como le cuentas al cliente o product Owner que retrasas las entregas o que no tendrá lo que pedia. Si es por añadir alcance es relativamente sencillo por que es el propio cliente(product Owner) que asume que a añadido alcance, sino tienes el mismo problema de otras metodologías en cuanto a no cumplir expectativas, no?.
Es un tema que me da dolor de cabeza al trabajar con Scrum ya que se realizo un cambio de metodologia esperando cumplir mejor las entregas y no esta resultando tan facil, en algunos casos se ha mejorado pero es cierto que como cada proyecto es diferente no se sabria si ese mismo proyecto se hubiese realizado de la misma forma con otras metodologías.
Buenísimo!
Para Sutherland todo es cuestión del famoso loop OODA:
Observar, Orientarse, Decidir y Actuar de forma iterativa…
Este loop OODA cambió las tácticas del combate aéreo.
En su libro «Scrum» Sutherland lo explica fenomenal
Gracias Javier!!!