¿Cómo abordar la entrega de arreglos de producción en scrum?

Grandes respuestas arriba.

Pero agregaré... Tómese un tiempo con el PO y el DT para discutir las correcciones de errores de producción e intente tener una política implementada para que su equipo comprenda mejor las correcciones Scrum Vs Emergency.

Por lo general, los equipos adoptan una metodología... "Si es tan importante... arreglarlo, implementarlo, volver a las tareas de sprint".

Luego, tenga cuidado con el cambio furtivo de PO como emergencias cuando, de hecho, solo son requisitos que no se cumplieron.

¡Buena suerte!

Scrum es el vehículo para llegar a tu destino de forma más rápida y cómoda. No es un garrote para golpearse en la cabeza...

No hay nada en Scrum que le impida renegociar el alcance de este sprint o lanzar una nueva versión durante el sprint. SCRUM solo dice que los sprints deben ser lo suficientemente cortos como para que, por lo general, este tipo de cosas no sean necesarias (es decir, el PO puede esperar al próximo sprint para todo lo que surja). Pero el objetivo de Agile es que puede adaptarse a las circunstancias cambiantes. Además, Scrum no dice que solo puede entregar al final del sprint, sino que debería poder liberar al final del sprint.

Si el impacto del error o la funcionalidad faltante es tan grande como dice el pedido de compra, entonces debe abordar esto de inmediato y lanzar una nueva versión dentro del sprint. También debe usar su próxima retrospectiva para abordar cómo fue posible pasar por alto este problema.

Individuos e interacciones sobre procesos y herramientas.

Software de trabajo sobre documentación completa

Colaboración con el cliente sobre la negociación del contrato

Responder al cambio sobre seguir un plan

He visto a personas agregar un carril de emergencia a su tablero Kanban, y esos boletos tienen prioridad.

Esto evita romper el concepto Kanban, pero, como Kempeth ya respondió con tanta elocuencia, existen herramientas de gestión de proyectos para facilitar (y, con suerte, acelerar) el proceso de entrega, con la última esperanza de enriquecer a la empresa. :-)

Tratar a PjM como reglas inmutables es una tontería, aunque hay que tener cuidado de no tener una lista interminable de " emergencias " que destruyan todo el concepto.

Diría que hay algunas cosas diferentes que abordar.

La situación es diferente si se trata de un error o de una funcionalidad faltante. Si se trata de un error, analice realmente el alcance y el posible impacto del mismo. El propietario del producto debería poder decidir realmente con sentido común si esto es algo que puede esperar hasta el próximo sprint. Por lo general, puede. Y si no, el enfoque probablemente debería ser: arreglarlo, volver al sprint y tener esto en cuenta cuando el Equipo Scrum inspeccione ese sprint en la retrospectiva y hable sobre cómo mejorar para que eso no suceda muchas veces en el futuro. . Por ejemplo: ¿El equipo tenía una definición de hecho? ¿El desarrollo desplegado pasó la definición de "lista de verificación" completa?

Si es una funcionalidad faltante, negocie con el Equipo de Desarrollo. Es importante no cambiar el alcance de un Sprint porque estás afectando tu Sprint Goal. Si se trata de unas pocas horas de trabajo, probablemente puedan aceptar trabajar en ello. Pero nuevamente, hable de esto en la retrospectiva e intente analizar por qué una funcionalidad, que parece ser un requisito faltante, aparece de repente de una manera tan urgente que no puede esperar al próximo sprint.

Acerca de las implementaciones, Scrum dice que debe tener un incremento de producto al final del sprint. No dice que tiene que implementar la funcionalidad solo al final del sprint. Puede tener tantas implementaciones como desee, necesite o pueda realizar durante un sprint.

Muchas formas de lidiar con esto, pero en mi opinión, las siguientes dos son las más sostenibles:

1. Si la velocidad del equipo es de 50 pisos, comience el sprint con 35 pisos. Dejando 15 para corrección de errores y/o mejora/aprendizaje continuo.
2. Acortar el sprint tanto como sea posible. No tiene sentido distraer al equipo con errores. La mayoría de los errores podrán esperar a que se priorice la planificación del próximo sprint.

Obviamente, el objetivo a más largo plazo debe ser minimizar los errores mediante la introducción de prácticas que promuevan la calidad. Si tiene un gran % de esfuerzo destinado a errores, entonces lo anterior será útil.

Después de hacer todo, es posible que los tapones de la producción rara vez aparezcan. Mi enfoque es detener a todo el equipo, arreglarlo y seguir adelante.

Lo que hacemos en este momento.

Tenemos un sprint planeado que constará de 2 partes.

• obra nueva (70%)
• Corrección de errores/incidentes/producción en llamas

Con esta propuesta se tiene en cuenta el tiempo para corregir errores. No los soluciona todos en un solo sprint, sino que simplemente adopta un enfoque continuo para eso. Cuando el PO tiene un problema de producción muy alto, se tiene en cuenta el tiempo de error. De esa manera, el nuevo desarrollo no se detiene y puede solucionar el problema de producción.

Esta es una situación en la que el producto está activo y tenemos muchos errores (compramos el maldito precio fijo). Funciona bastante bien para nosotros.

Sea consciente de llamar a esto pequeños sprints más o menos. Si esto es realmente un problema, tal vez haga sprints un poco más cortos. 1 (o máximo 2) semanas. De esa manera, también puede entregar más rápido esos molestos problemas de producción.