Nuestros dos equipos de desarrollo Scrum están ubicados en India. Nuestro propietario de producto compartido se mudará permanentemente a los EE. UU. y estamos a punto de terminar nuestro primer sprint. Él y el equipo sugirieron retrasar el próximo sprint una semana mientras está en tránsito. Me preocupa la pérdida de ritmo del equipo, además de violar una de las reglas fundamentales del scrum.
No formo parte de los equipos de scrum, pero soy un ScrumMaster certificado y he aprendido mucho de este sitio a lo largo de los años, por lo que actúo como un entrenador ágil dentro de la organización.
Así que iba a sugerirles que hicieran otro sprint de todos modos, pero que solo se centraran en la deuda técnica y simulen que están haciendo un sprint en el que se comprometieron a cero puntos de historia. Sé que retrasar un sprint no se recomienda en scrum, según la Guía de Scrum , pero comprometerse a menos para que el equipo pueda resolver la deuda técnica es algo que se recomienda en algún material que he leído.
El propietario del producto prefiere que el equipo no trabaje en ningún elemento de la cartera de productos hasta que pueda arreglar aún más la cartera de pedidos. Habíamos planeado llevar a cabo una reunión de refinamiento de la cartera de productos, pero nos dimos cuenta de que la carga de trabajo del PO era demasiado alta esta vez. Entonces, ¿hay algún peligro en comprometerse con cero puntos de historia pero ejecutando el sprint como si fuera un sprint real?
Desde mi experiencia, tomarse una semana libre y trabajar en otras cosas no suele ser un gran problema. Muchas veces es cuando los desarrolladores obtienen su propio tiempo para trabajar en cualquier proyecto favorito que tengan. Otras veces, es alrededor de las vacaciones de Acción de Gracias o las vacaciones de Navidad/Año Nuevo, por lo que una gran parte del equipo está fuera de todos modos.
¿Cuál es tu longitud normal de sprint? Si es una semana, entonces trabajar un sprint de una semana parece razonable. Si normalmente tiene sprints más largos y desea ejecutar este durante una semana, podría advertirle que no lo haga. Como mencionaste, hay un ritmo en un sprint. Si te tomas una semana libre de las carreras de velocidad, es como si hicieras una pausa y luego volvieras a jugar cuando volvieras a hacerlo. Cambiar la duración del sprint es más como cambiar lo que estás jugando, o al menos cambiar la temperatura de lo que estás jugando.
Ahora, si tiene sprints semanales y hay una deuda técnica en la que trabajar, parece una buena opción. Sin embargo, le preguntaría por qué no seguiría el proceso estándar. Lo que quiero decir con eso es escribir la deuda técnica en términos de valor para el equipo de desarrollo (lo que, por supuesto, también tiene valor para el cliente final, incluso si no pueden verlo tan fácilmente). Si trata la deuda técnica como historias, eso ayudará a garantizar que el equipo siga todas sus prácticas estándar y, con suerte, termine con resultados de calidad.
Creo que también es importante asegurarse de que el Product Owner entienda que él también tiene compromisos con el equipo. Si quiere que el equipo se comprometa a entregar las funciones planificadas al final del sprint, también debe comprometerse a alimentar al equipo con información de alta calidad del sprint: su requisito.
Así que creo que el equipo podría decidir por sí mismo, dependiendo de cuánta confianza tengan y qué tan buena sea la relación con el propietario del producto, si quieren seguir adelante y comenzar un nuevo sprint con investigación técnica o lo que sea que quieran hacer para usar pasar el tiempo, o simplemente relajarse y disfrutar de la vida durante una semana. Pero de todos modos, la próxima vez que realicen una reunión retrospectiva con el Product Owner, deben tener una conversación seria con el Product Owner sobre cómo asegurarse de que el equipo obtenga suficiente información, incluso cuando el Product Owner esté de viaje.
Me sorprende que tu Product Owner no quisiera hacer otro sprint. En general, los propietarios de productos tienden a presionar a los equipos de desarrollo para que publiquen los lanzamientos más temprano que tarde. Siempre se enfrentan a factores externos, como el lanzamiento en algún evento comercial o ganarle a un competidor en el mercado.
Sin embargo, su intuición va en la dirección correcta. Sí, deberías hacer otro sprint por las siguientes razones:
Para evitar la pérdida de ritmo, como bien comentas.
Más importante aún, al saltarse un sprint, está enviando un mensaje equivocado al equipo sobre la importancia de este proyecto, los plazos, etc.
Este sprint puede ser una mezcla de:
Resolución de deuda técnica.
Hacer trabajo de investigación sobre historias prioritarias que probablemente se programarán en los próximos sprints. Esto dará una oportunidad para que el equipo de desarrollo haga el descubrimiento o realmente construya una prueba de concepto para que estén en una mejor posición para dimensionar las historias y minimizar el riesgo cuando realmente estén programadas.
Además, no hay necesidad de que sea cero puntos. Si se está haciendo algún trabajo, se requiere esfuerzo y eso tiene puntos de historia asociados. Entonces, adelante y pon puntos de historia. En las historias de investigación, algunas personas prefieren poner un cuadro de tiempo en lugar de puntos de historia.
En su caso específico, sería mejor tratar la semana como un lastre para la productividad. Esto en realidad no afectará la velocidad del equipo si no haces jigger con la longitud de los sprints; lo que hará es actuar como un costo visible en la planificación de lanzamiento de su proyecto al reducir la cantidad de sprints completos restantes en su programación actual. This is a Good Thing™ porque refleja la realidad del proyecto.
¿Está bien tener un sprint en el que el equipo se comprometa a cero puntos de historia?
Sí, pero tu verdadera pregunta es algo diferente. :)
El propietario del producto prefiere que el equipo no trabaje en ningún elemento de la cartera de productos hasta que pueda arreglar aún más la cartera de pedidos. Habíamos planeado llevar a cabo una reunión de refinamiento de la cartera de productos, pero nos dimos cuenta de que la carga de trabajo del PO era demasiado alta esta vez. Entonces, ¿hay algún peligro en comprometerse con cero puntos de historia pero ejecutando el sprint como si fuera un sprint real?
Si bien la cadencia es importante para las metodologías ágiles, a menudo se pasa por alto la importancia de la transparencia. El problema real aquí es que retrasar el trabajo mientras el propietario del producto no está disponible es un costo real para el proyecto y, como tal , debe hacerse visible .
Con eso en mente, les diría a los desarrolladores que usen esta semana como tiempo libre relacionado con el trabajo. Permítales actualizar sus estaciones de trabajo, leer un libro sobre un nuevo lenguaje de programación que les interese o, de lo contrario, recibir un pago por hacer algo útil para ellos (y su futura productividad) sin formalizarlo.
Es importante no hacer de esta una semana de mucho trabajo. Eso no solo es antitético a los principios de autoorganización de Agile, sino que simplemente no es bueno para la moral del equipo. El trabajo ajetreado también crea la ilusión de que el equipo está trabajando en el valor del producto cuando, de hecho, este tiempo (aunque potencialmente útil para los desarrolladores) es explícitamente un lastre para el proyecto en su conjunto. Esta verdad central necesita ser firmemente mantenida.
En cualquier proyecto, hay tareas no relacionadas con el producto que necesitan atención. Los servidores CI necesitan actualizaciones, los servidores SCM necesitan parches, etc. En la medida en que estas cosas afecten al equipo, este es un buen momento para trabajar en ellas, pero el problema es que se convierte en un "trabajo invisible" porque no está priorizado en el Product Backlog.
Además, los gastos generales involucrados en la creación de un sprint de una semana en lugar de simplemente esperar hasta que el PO esté de vuelta en la silla de montar para la duración estándar del sprint probablemente no valga la pena. Creo que es mejor capturar esta pérdida de productividad como un freno a la velocidad del equipo y simplemente planificar mejor el futuro.
Los buenos propietarios de productos también suelen mantener algunas historias "perennes" e historias de deuda técnica en la cartera de pedidos para esas ocasiones. Luego, cuando nada más apremia, estas historias pueden trabajarse legítimamente sin que desaparezcan.
Finalmente, el problema con un sprint diseñado y ejecutado por el equipo sin la participación del PO son legión. Considere algunos de los siguientes:
Lo mejor que puede hacer es liberar a sus desarrolladores de manera informal durante la semana. Que trabajen en lo que les interese o en su desarrollo profesional. Si bien es posible que no avance directamente en el proyecto, contribuirá a la felicidad del desarrollador y mejorará la eficacia general del equipo a largo plazo, todo sin comprometer la integridad del proceso Scrum.
Así que iba a sugerir que hicieran otro sprint de todos modos, pero que solo se centraran en la deuda técnica...
Si está hablando de centrarse en la deuda técnica, suena como anticipar cuáles serán las prioridades en la cartera de productos. Puede que tengas razón, o puede que estés equivocado.
Esto puede parecer purista, pero sugeriría seleccionar elementos de la parte superior de la cartera de productos tal como existe . Debido a que se omitió el refinamiento de la cartera de productos durante el período previo a ese sprint, espero que la reunión de planificación del sprint sea más desafiante y consuma más tiempo, pero eso es solo una consecuencia natural de cómo han ido las cosas. Es "agua bajo el puente", por así decirlo.
Permítete tener una reunión de planificación de sprint más larga de lo habitual, en la que pases suficiente tiempo desglosando los elementos principales. Sea conservador en la cantidad de elementos de la cartera de productos principales que coloca en la cartera de pedidos del sprint. Haz lo que Scrum guía. Lo peor que puede suceder es que el OP decida que habría vuelto a priorizar los elementos elegidos a un nivel más bajo. Al menos habrá trabajado en lo que se identificó como la prioridad, en la medida de lo posible.
Entonces, ¿hay algún peligro en comprometerse con cero puntos de historia pero ejecutando el sprint como si fuera un sprint real?
Creo que el peligro es que emprendas un trabajo sobre una deuda técnica que asumes que será necesaria, y luego descubras que no era necesario, o no en la forma en que lo haces.
Cuando se trabaja como parte de equipos grandes (o cuando tiene varios equipos en una base de código), esto se puede conocer como un sprint de fortalecimiento . Aunque no está reduciendo los puntos destacados del mvp per se, está mejorando las cosas en general.
Puede realizar una serie de tareas para mejorar las cosas:
Estimaría estos y trabajaría en una cantidad similar de puntos a un sprint normal (suponiendo que haya estado registrando estos problemas como historias).
jmort253
jmort253
jmort253