En Scrum, cómo manejar la contención / carga de trabajo al final del sprint

Mi equipo comenzó a usar Scrum hace unos sprints. Nuestro proyecto implica la creación de una interfaz de software con dispositivos físicos (piense en robots y sensores) y nuestra típica cartera de pedidos de productos generalmente representa agregar dispositivos de control a todo el sistema.

Dividimos la tarea cerca del ejemplo aquí . Cada característica de integración del dispositivo se divide en código, pruebas, pruebas de integración, revisión por pares, etc. Obviamente, hay una secuencia inherente a cada elemento de la Lista de Producto. Por lo general, nuestros sprints duran 2 semanas y el equipo tiene entre 4 y 6 miembros.

Nos encontramos con 2 problemas al final de los sprints:

• El primero es mantener a todos ocupados al final del sprint.
• El segundo (relacionado) es la contención en el sistema. Casi terminamos integrándonos durante los últimos días del sprint. Solo tenemos un sistema de integración, por lo que a las personas a menudo se les impide continuar trabajando en su tarea porque no pueden acceder al sistema. Como es el final del sprint, no queda mucho trabajo por hacer en el backlog del sprint. ¿En qué deberían trabajar estas personas? Recoger elementos de la parte superior de la cartera de pedidos del producto no es bien recibido por el propietario del producto, ya que los elementos actuales no se han completado. Trabajar en deuda técnica ayudará al proyecto en su conjunto, pero no ayudará a completar el sprint.

¿Existen mejores prácticas para estructurar sprints para evitar estos problemas? ¿Consejos para negociar con los propietarios de productos?

de alguna manera es bueno que seas lento al final de un sprint, eso significa que estimas bien y no te comprometes demasiado, en cuanto a mantenerte ocupado, en los equipos scrum en los que he trabajado siempre agregamos tareas de investigación para lo que viene a continuación pique.

Esto podría ser una prueba de conceptos para las cosas que están por venir, o mirar dónde re-factorizar el código existente, trabajar para obtener una mejor cobertura de prueba en su código, etc.

Debe arreglar su sistema de integración para que su equipo pueda integrar su trabajo tan pronto como se complete cada tarea, en lugar de esperar una gran explosión al final del sprint.

Recomiendo trabajar con historias de usuarios lo suficientemente cortas como para terminarlas en unos días. Terminado aquí significa código completo, probado e integrado.

Recordar que es responsabilidad de todo el equipo entregar, no miembros individuales, per se , es posible que todos los miembros de cuatro a seis trabajen en cada tarea JUNTOS: empujen a cada uno a través del proceso y avancen a la siguiente. Esto puede sonar ineficiente al principio, pero si los cuellos de botella que está viendo son tan malos, puede ser una opción válida.

Además, es posible que desee analizar la teoría de las restricciones ( The Goal de Goldratt ) y ver cómo puede analizar mejor por qué y dónde tiene estos cuellos de botella de integración.

Hemos abordado esto adoptando el enfoque Kanban.

Tenemos colas en nuestro software de seguimiento (Jira) con mínimos y máximos.

Preparamos 'según sea necesario'. Puede ser una vez a la semana, puede ser 3 veces, depende de los límites y del trabajo que se realice.

Esto lo ayudará a lograr que el propietario del producto se concentre en mantener su cola con mucho que hacer y puede reducir la microgestión de tickets individuales. Solo recuerda que, como siempre, el cambio llevará tiempo.

Todavía hacemos demostraciones cada dos semanas y lanzamos semanalmente.

Wow, si no dijeras robots, asumiría que estabas en mi equipo ahora mismo. Tenemos exactamenteEl mismo conjunto de problemas. Después de haber trabajado en numerosos proyectos ágiles con diversos grados de fidelidad al manifiesto y diversos grados de éxito, mi análisis es que nuestro problema es que los sprints son demasiado cortos. Estamos haciendo sprints de dos semanas que causan algunos problemas. Una es que terminamos siendo demasiado cautelosos en la planificación y con frecuencia terminamos con días muertos al final. El segundo es la gran revisión de la revisión, la retrospectiva y la planificación, que toma de 1 a 2 días cada dos semanas. Otro es, como usted dijo, tener que integrarse en el último minuto y con frecuencia fallar horas antes de la revisión. Mi primer y más exitoso proyecto ágil tuvo sprints de cuatro semanas, que creo que es bastante grande para los estándares de la industria, pero funcionó muy bien para nosotros.

EDITAR: recordó una cosa más del primer proyecto que fue una bendición. Siempre tuvimos una reserva de productos con prioridad total y les dimos a los desarrolladores la libertad de tomar tareas si sus tareas de sprint estaban completas y no había otras tareas de sprint disponibles.

El segundo problema es probablemente una consecuencia de tratar de arreglar el no problema # 1. Debes conseguir gente que no esté ocupada, para ayudar a sus compañeros; en lugar de trabajar en tareas que no son de sprint, que causan contención en la integración limitada.

Además, no debe integrarse al final del sprint, sino continuamente.

Estás empezando. Dé a los equipos la oportunidad de abordar este problema ellos mismos a través de su proceso retrospectivo.

En segundo lugar, el propietario de su producto debe confiar en que el equipo sepa mejor cómo organizarse y optimizarse. A cambio, el equipo confía en el PO para saber mejor lo que el cliente necesita.

Estos son desafíos muy comunes con los nuevos equipos ágiles. Es genial ver cuándo un equipo comienza a romper sus propios silos y crecer.