El equipo entrega algo que no coincide con lo que esperaba el negocio. ¿Cómo lo manejas?

Establece dónde divergió el entendimiento antes de decidir quién tiene razón. Vuelve al requisito escrito y a los criterios de aceptación: si eran ambiguos, eso es de la especificación; si eran claros, es un problema de construcción. Arregla la brecha inmediata y luego cierra el agujero de proceso que dejó que llegara a la entrega sin que nadie lo cazara antes.

Primero voy y leo lo que se escribió de verdad, antes de que nadie empiece a discutir, porque la respuesta suele estar justo ahí. Si los criterios eran ambiguos, eso es mío y lo digo rápido, porque ponerse a la defensiva con una especificación gasta un día y te cuesta la buena voluntad que vas a necesitar más adelante. Si eran claros y aun así se construyó de otra forma, esa es una conversación distinta y mucho más fácil. En cualquier caso acordamos el arreglo y dónde encaja frente a todo lo demás. La parte que me importa más es por qué llegó hasta la entrega sin que nadie se diera cuenta, porque eso significa que falta un paso de revisión o que se lo están saltando. En un proyecto la respuesta era que el negocio había dejado de asistir a las demos de sprint, así que no se veía nada hasta las pruebas de aceptación. Lo cambiamos por un recorrido de quince minutos con los usuarios reales a mitad de sprint, y ese tipo de problema prácticamente desapareció.