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

Últimamente he estado luchando con la misma pregunta un poco. Comenzamos con la siguiente 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 que la intención sea beneficiar a la compañía".

Ejemplos:

• pasa el día aprendiendo algo
• Gastarlo en un proyecto de tiempo de innovación
• Gastalo en ordenar esa molesta pieza de código para que nunca te refuerzas
• Tenga una buena ejecución de la aplicación con una vista a UX (que parece que nunca encontraremos tiempo para hacer lo contrario)

Lo que sea que motive al programador, dándoles 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 fuera posible el cambio de proceso, considere la posibilidad de eliminar iteraciones, liberar continuamente y simplemente seguir extrayendo historias de la acumulación. ¿Pero no mereces un poco de tiempo libre?

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

Incluso si nuestras historias de usuario casi siempre terminan al final de una iteración, al final siempre tenemos una larga lista de "cosas buenas", 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 lo más importante, 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 aprenderás, si no lo haces. Realiza tus errores y las cosas que salieron bien.

Si todos los errores están resueltos, se ha hecho una larga lista de cosas que se deben hacer mejor, junto con los puntos de acción, creo que es bueno reunir al equipo frente a una pantalla grande, y tratar de jugar un poco. El software que fue construido, junto con algunas cervezas. No es muy productivo, pero es agradable hablar sobre lo que se ha implementado y cómo funciona realmente.

Si tienes días, entonces trataría de encontrar algo nuevo que aprender, y tratar de jugar con él, tal vez sea la próxima gran cosa. Pero nuevamente, si hay días, es probable que haya una historia de usuario en la lista de tareas pendientes

Nuestras iteraciones terminan los jueves, para poder solucionar cualquier problema de última hora el viernes. Pero esos viernes (uno cada 2 semanas) coinciden con nuestros viernes de cerveza, así que intentamos tomarlo con bastante calma. Solucione algunos errores menores, pase algo de tiempo leyendo cosas (libros, StackExchange, blogs, etc.) y relájese con una cerveza al final del día. De lo contrario, no alcanzará la sensación de haber terminado o de cerrarse, y en su lugar se sentirá como un hámster girando en una rueda sin parar.

No estoy seguro de que quieras para terminar siempre exactamente a tiempo. Terminar tu trabajo un poco antes te permite pensar en historias, capacidades y características futuras. Le brinda una 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 tener trabajo transferido.

Ken Schwaber declara en su blog enlace

"Que Dios nos ayude. La gente encontró formas de relajarse en la cascada, descansar y ser creativos. Con Lean y Kanban, se eliminan esos escondites. Ahora tenemos una marcha progresiva hacia la muerte 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 se completa todo en la iteración. Pragmáticamente, estas "tareas de bonificación" son generalmente lo que se trabajaría primero en la siguiente iteración de todos modos, pero llamarlas "tareas de bonificación" funciona mucho mejor que simplemente tener más trabajo planificado y luego se puede completar.

Para otras cosas, como el tiempo de aprendizaje o innovación, simplemente permitimos que cada desarrollador dedique hasta un día a la semana a esas cosas como una cosa normal esperada. 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 utilizan 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 implementar un sistema como este, esto ha aumentado los niveles de satisfacción laboral dentro de nuestro equipo.

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

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

Para resolver esto, planea más historias de las que has sido. Comprométase solo con su velocidad anterior, pero si termina esas historias, comience a trabajar en las adicionales. Si completas más, aumenta tu velocidad para el próximo sprint. Planifica siempre un poco más de lo que te comprometerás, o al menos tendrás algunas historias programadas, por si acaso.

Esta es una de las razones por las que cambiamos a Kanban. Todos los beneficios de scrum sin tener que seguir separándose del proyecto.

Me gusta la respuesta de Todd de tomarse el día libre, sin embargo, diría que trate de hacer la planificación del sprint y la retrospectiva en la mañana y que será un desafío para terminar a tiempo para el almuerzo y luego tomar un almuerzo largo como un equipo. En el almuerzo, fomente la discusión sobre el sprint para obtener una retrospectiva informal de forma gratuita.

Si no puede, desactive la tarde (y me refiero a ir a casa temprano por la tarde, no a un conjunto de objetivos por la tarde) y luego abordar la deuda técnica, ya que es lo único que deprime a un desarrollador más que nada de lo contrario (fuente: mi opinión) tener que sortear la deuda técnica cuando saben exactamente cómo abordarla y hacer su vida más fácil.

Personalmente, encuentro que las retrospectivas no valen realmente la pena pasar el tiempo, generalmente hay algunos temas recurrentes comunes (historias de usuarios deficientes, mala estimación, etc.) y simplemente las acepta como áreas problemáticas y continúa. También intentamos y tratamos los problemas a medida que surgen, en lugar de esperar a la retrospectiva (que tuvimos la tendencia de hacer en las primeras etapas de la adopción de Scrum).

Ahora, en lugar de tener una retrospectiva, cada par de desarrolladores selecciona un elemento pendiente de la acumulación de retrospectiva existente y trabaja en él.

También mantenemos una acumulación de deuda técnica en curso, que actúa como elementos de bonificación para los sprints (si la empresa no está lista para implementar algo de su acumulación de antemano).

Esto ya ha demostrado ser bastante positivo, en el sentido de que todos los pequeños artículos molestos que simplemente siguen burbujeando reciben la atención de un día en cada carrera.

Celebre 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 por separado de la sesión de planificación, donde las historias aún eran claras sobre los detalles y se juzgaban por puntos de historia o estimaciones de tamaño de camiseta. Mantenga la sesión informal y fomente la creatividad.