¿Cómo podemos reducir el tiempo de inactividad al final de una iteración?

Donde trabajo, practicamos el ágil de scrum con iteraciones de 3 semanas. Sí, sería bueno si las iteraciones fueran más cortas, pero cambiar eso no es una opción en este momento.

Al final de la iteración, generalmente encuentro que el último día pasa muy lentamente. El trabajo real ya ha sido completado y aceptado. Hay un par de reuniones (la planificación retrospectiva y la próxima iteración), pero aparte de eso, no está sucediendo mucho.

¿Qué tipo de técnicas podemos usar como equipo para mantener el impulso durante el último día? ¿Deberíamos abordar los defectos? ¿Empezar temprano en el trabajo de la próxima iteración de todos modos? ¿Algo más?

He estado luchando con la misma pregunta un poco últimamente. Estamos comenzando en la próxima iteración, pero creo que esto elimina la satisfacción de una iteración bien hecha.

Estoy pensando en la opción de dejarlo en manos de los desarrolladores, con la advertencia "siempre y cuando la intención sea beneficiar a la empresa".

Ejemplos:

• Pasa el día aprendiendo algo
• Gastarlo en un proyecto de tiempo de innovación
• Gasta el orden en ese código molesto que nunca podrás refactorizar
• Realice un buen recorrido por la aplicación con vistas a UX (que parece que nunca encontramos tiempo para hacer lo contrario)

Cualquier cosa que motive al programador, dándole un incentivo para entregar el lanzamiento a tiempo.

Tómate el día libre. Hiciste el trabajo que se suponía que debías hacer, ¿por qué sigues trabajando?

Si el cambio de proceso fuera posible, considere descartar iteraciones, lanzar continuamente y simplemente seguir sacando historias del trabajo atrasado. ¿Pero no mereces un poco de tiempo de inactividad?

He notado el mismo problema (y a veces usamos sprints de 2 semanas, lo que lo exacerba aún más). Lo que intento hacer para esos días (día de revisión de sprint y día de planificación de sprint) es ahorrar algo de trabajo que sé que querré hacer pero que no requiere mucha planificación o comunicación interna, como errores de baja prioridad, pulido, o mejoras de herramientas. A veces, esto se convierte en algo positivo, ya que crea un buen momento para hacer un trabajo importante pero no sexy para el que de otro modo sería difícil hacer tiempo.

Incluso si nuestras historias de usuario casi siempre terminan al final de una iteración, siempre tenemos una larga lista de "agradables" al final, junto con una lista de errores conocidos. Entonces, cuando la gente termina sus historias, siempre hay mucho que hacer.

Creo que hacer una reunión retrospectiva es el rey, incluso si se trata principalmente de los mismos problemas que se plantean, es muy importante pasar un poco de tiempo reflexionando sobre cómo fue la iteración, cómo vas a aprender, si no te das cuenta de tus errores y las cosas que salieron bien.

Si se hacen todos los errores, se ha hecho una larga lista de cosas para mejorar, junto con los puntos de acción, creo que es bueno reunir al equipo frente a una pantalla grande e intentar jugar con el software que fue construido, junto con algunas cervezas. No es muy productivo, pero es bueno hablar sobre lo que se ha implementado y cómo funciona realmente.

Si tienes días, entonces trataría de encontrar algo nuevo para aprender y tratar de jugar con él, tal vez sea la próxima gran cosa. Pero, de nuevo, si hay días, entonces probablemente haya una historia de usuario en el trabajo pendiente para hacer

Nuestras iteraciones terminan los jueves para poder solucionar cualquier problema de último minuto el viernes. Pero esos viernes (uno cada 2 semanas) coinciden con nuestros viernes de cerveza, por lo que tratamos de tomarlo con bastante calma. Arregle algunos errores menores, pase un tiempo leyendo cosas (libros, StackExchange, blogs, etc.) y relájese con una cerveza al final del día. De lo contrario, no llega a una sensación de finalización o cierre, y en cambio se siente como un hámster girando sin parar en una rueda.

No estoy seguro de que quieras terminar siempre exactamente a tiempo. Hacer tu trabajo un poco antes te permite pensar en historias, capacidades y características futuras. Le da un poco de pausa después de un trabajo bien hecho que puede ser más gratificante que comenzar temprano o comprometerse con más historias y siempre hacer que el trabajo se traslade.

Ken Schwaber afirma en su blog http://kenschwaber.wordpress.com/2010/06/10/waterfall-leankanban-and-scrum-2/

"Dios nos ayude. La gente encontró maneras de relajarse en la cascada, descansar y ser creativos. Con Lean y Kanban, esos escondites se eliminan. Ahora tenemos una marcha de la muerte progresiva sin pausa".

En mis proyectos, durante la planificación de la iteración, siempre seleccionamos algunas tareas adicionales y las etiquetamos como "tareas adicionales" en las que se trabaja si todo en la iteración termina. Pragmáticamente, estas "tareas de bonificación" son generalmente lo que se trabajaría primero en la próxima iteración de todos modos, pero llamarlas psicológicamente "tareas de bonificación" funciona mucho mejor que simplemente tener más trabajo planeado y luego se puede completar.

Para otras cosas, como el tiempo de aprendizaje o innovación, simplemente dejamos que cada desarrollador pase hasta un día a la semana en esas cosas como algo normal esperado. Puede ser cualquier día de la semana (es decir, no tiene que ser al final de cada semana).

Todos los desarrolladores de mi equipo usan el tiempo libre hacia el final de un sprint (siempre que todas las tareas de sprint hayan finalizado) como 'tiempo de Google'.

Aquí es donde cada desarrollador trabaja en su propia idea / proyecto siempre que beneficie a la empresa. Recomiendo encarecidamente establecer un sistema como este, esto realmente ha aumentado los niveles de satisfacción laboral dentro de nuestro equipo.

Si constantemente terminas tres días antes, me sugiere que no estás planeando suficientes historias para el sprint.

Uno de los objetivos de scrum es aumentar la productividad: no lo hará si está disparando cada sprint.

Para resolver esto, planifique más historias de las que ha tenido. Solo comprométete con tu velocidad anterior, pero si terminas esas historias comienza a trabajar en las adicionales. Si completa más, aumente su velocidad para el próximo sprint. Siempre planifique un poco más de lo que se comprometerá, o al menos tenga algunas historias alineadas, por si acaso.

Esta es una de las razones por las que nos cambiamos a Kanban. Todos los beneficios de scrum sin tener que seguir interrumpiendo el proyecto.

Me gusta la respuesta de Todd de tomarse el día libre, sin embargo, diría que intente hacer una planificación de sprint y una retrospectiva por la mañana y establezca el desafío de hacerlo a tiempo para el almuerzo y luego tomar un largo almuerzo en equipo. En el almuerzo, fomente la discusión sobre el sprint para que obtenga una retrospectiva informal de forma gratuita.

Si no puede dar la tarde libre (y quiero decir que irse a casa temprano por la tarde no establecer sus propios objetivos por la tarde libre), aborde la deuda técnica, ya que es lo único que deprime a un desarrollador más que cualquier otra cosa (fuente : mi opinión) tener que evitar la deuda técnica cuando saben exactamente cómo abordarla y facilitarles la vida.

Personalmente, considero que las retrospectivas realmente no valen la pena, por lo general hay algunos temas recurrentes comunes (historias de usuarios pobres, mala estimación, etc.) y simplemente los acepta como áreas problemáticas y continúa. También tratamos y tratamos los problemas a medida que surgen, en lugar de esperar la retrospectiva (que teníamos tendencia a hacer en las primeras etapas de la adopción de Scrum).

Ahora, en lugar de tener una retrospectiva, cada par de desarrolladores elige un elemento sobresaliente de la cartera de pedidos retrospectiva existente y trabaja en él.

También mantenemos una acumulación de deuda técnica continua, que actúa como elementos de bonificación para sprints (si la empresa no está lista para implementar algo de su cartera de pedidos con anticipación).

Esto ya ha demostrado ser bastante positivo, ya que todos los artículos pequeños y curiosos que siguen burbujeando reciben un día de atención cada sprint.

Tenga una sesión de diseño de pizarra y comparta ideas de implementación para historias interesantes sobre el próximo sprint. Haga esto después y aparte de la sesión de planificación, donde las historias todavía eran ligeras en los detalles y juzgadas por los puntos de la historia o las estimaciones del tamaño de la camiseta. Mantenga la sesión informal y fomente la creatividad.