1- Tener mucho WIP
- Se hacen muchos trabajos a la vez durante todo el sprint.
- Al manejar el product backlog items se dividen el trabajo y solo se enfocan en pasar las cosas de sprint a sprint.
- El Sprint Goal (normalmente) es algo fijo durante el sprint. No cambia. Aporta foco.
- Sí se puede cambiar el Sprint Backlog. Se negociar con el Product Owner.
- En la daily es importante recordar el sprint goal:
- Que hice ayer que colaboró con el objetivo del sprint goal.
- Que voy a hacer hoy que colabore con el objetivo del sprint goal.
- Qué dificultades tengo que impidan lograr el objetivo del sprint goal.
- Si hay mucho WIP y no está claro el Sprint Goal, en la Sprint planning solo se asignan las tareas produciendo:
- Falta de colaboración.
- La gente no se comunica. Cuando se llega al final del sprint se nota lo que falta.
- Me hago responsable de una parte de las tareas pero nadie ve el Sprint Goal.
- Se puede tener el 99% de las tareas terminadas y aún así obtener 0 valor en el sprint.
- En Scrum el incremento es binario (blanco o negro). No hay una definición de “medio hecho”.
- Se debe debatir durante la sprint planning.
- Cuando no se tiene una definición de Done, se terminan las cosas “a medias” (“terminé pero me faltan los tests”. “Terminamos pero falta la documentación”).
- La definición de Hecho aplica a cada uno de los Product Backlog Items.
- Dividiendo la mayor número de tareas en la mayor cantidad de gente para tratar que todos estén ocupados (incluso adelantando tareas de otros sprint), todo el mundo puede estar ocupado todo el tiempo pero aun así agregar 0 valor al final de cada sprint.
- Según el Manifiesto Ágil la medida de progreso es “software funcionando”, no el número de tareas que se hayan terminado.
- El equipo es de desarrolladores, y no dispone de todos los perfiles y personas necesarias para lograr un producto terminado.
- Mini scrum dentro de un proyecto más grande no es agile:
Solución:
- Los Scrum Master deben enseñar los fundamentos de Scrum.
- Objetivo de Scrum: Entregar un incremente terminado en cada sprint.
- Objetivo de Product Owner: Hacer releases continuos para obtener feedback real de los clientes.
Recomendación:
- Que las personas entiendan Scrum.
- Charlar con el equipo de desarrollo. Identificar los problemas (de comunicación, de valor).
- Reducir el WIP: Se logra entregar mucho más rápido. Se logra más eficiencia. Es un error evaluar a las personas en vez de a los resultados (es porque no se tienen métricas de valor agile)
No te pierdas el video de Jerónimo Palacios:
