Archivo de la categoría: Scrum

SPIKES de investigación para reducir incertidumbre y estimar mejor con Scrum

En los equipos que se usa Scrum, es normal enfrentarse con integraciones con otros sistemas (PlugIns, servicios, SDKs,..)  de los cuales no se tiene suficiente conocimiento para poder estimar con precisión cuánto se va a tardar. Planificar una historia de usuario que incluya esta integración puede hacer variar el total de puntos realizados al final del Sprint, según haya sido más fácil o más difícil esa integración.

Para resolver esa incertidumbre, lo que hacen algunos equipos es añadir un SPIKE al Sprint previo a la propia historia de usuario. Un SPIKE no tiene puntos de historia asignados sino un deadline de término. Una vez resuelto el SPIKE y sabiendo cómo se hace esa integración, se puede estimar en el siguiente Sprint de manera más precisa.

Sin embargo, a esta aproximación le veo dos problemas y es la razón por la cual no suelo usarla.

  1. Al planificar un Sprint en el cual hay SPIKES sin puntos asignados, no se puede equiparar el numero de puntos del Sprint anterior (o la media de los últimos) . Ese SPIKE puede ocupar una parte significativa del propio Sprint y al final se completarán más o menos  puntos de historia según ese SPIKE acabe siendo más o menos costoso.  Por lo tanto, creando un SPIKE previo sólo estás retrasando la incertidumbre de la integración al Sprint anterior del que se desarrolla la propia historia de usuario que  usaría ese componente.
  2. Para resolver la investigación y desenmascarar todos los posibles problemas, normalmente se necesita trabajarlo tanto que su inclusión en una historia de usuario es casi directo. Por lo tanto personalmente prefiero que todo este trabajo que se ha hecho se vea reflejado en una historia de usuario, aunque sea sencilla, y permita el feedback del usuario/Product Owner al término del propio sprint sin tener que esperar uno más.

¿Qué opinas? ¿Usais SPIKES de investigación previa?

 

 

Eficacia vs Eficiencia en Scrum

Llevo tiempo dandole vueltas

Ultima mente creo que estoy dando el mensaje incorrecto sobre Agile, que no persigue la eficiencia ya que waterfall es mas eficiente. Todo esto surge de una de las lineas que vi como propuesta del Manifiesto Lean Kanban. No hay sistema teoricamente más eficiente que el waterfall. Cada fase está realizada por un equipo especialista que, sin cambio de contexto, pasa todo su trabajo de una a la fase siguiente. Sin embargo waterfall falla en cuando hay cambios a mitad de proyecto, o cuando hay alguien que no hace perfectamente su trabajo. Cosas que ocurren el 100% de los proyectos. Sin embargo, un equipo que pasa de waterfall a scrum tiene sensación de perdida de eficiencia por las siguientes razones:

  • Reworking. Cada vez que se enseña el software al cliente existe la posibilidad de que toque rehacer algo. Implica cambiar cosas que has hecho en un sprint en el sprint siguiente. También para que el software sea entregable al fin de sprint muchas veces hay que hacer trabajo extra para dejarlo listo.
  • Tener que integrar en cada sprint hace que se tenga que cambiar el contexto continuamente. Si desde el sprint 1 el equipo está peleando con integraciones, a primer momento parece no ser tan eficiente como estar solamente desarrollando. Sin embargo, esto convierte el gran problema de la integración final en una molestia desde el primer sprint.
  • Reuniones de Scrum : planning, daily, review y el refinement. A los equipos a los que se les tradicionalmente se les da una lista de tareas sin mayor explicación, les parece que son innecesarias todas estas reuniones… “Era más productivo cuando se me daba la lista de tareas”.

Sin embargo, aunque no lo parezca Scrum hace que un equipo pueda llegar a ser mucho más productivo. Como indica el titulo del libro de Jeff Sutherland, se puede llegar a entregar el doble de valor en la mitad de tiempo que con metodologías tradicionales. Aunque esto no se consigue por la metra transición a Scrum y mucho menos en el primer sprint. Lo que sí que permite es el marco para que el equipo consiga gran eficiencia. ¿Cómo?

  • Promoviendo que no se haga más de lo solicitado (“make the right think done”). No se debe escribir una sola linea de código que no tenga que ver con el objetivo de la historia de usuario y no se debe hacer una sola tarea o historia que no esté dentro del objetivo de sprint.
  • Protegiendo al equipo de las interrupciones. El equipo está expuesto a interrupciones para hacer burocracia, explicar o documentar su progreso y hacer cosas que no tienen que ver con su objetivo de sprint. El Scrum Master es responsable de proteger a los miembros del equipo.
  • Focalizando las reuniones. Cada reunión Scrum tiene su objetivo y su ventana temporal. Esto hace que las reuniones mismas sean más productivas y permite que durante el tiempo en la que el equipo no está reunido (work time) no tenga que cambiar de contexto por culpa de ellas. Hay que detectar y minimizar o eliminar las reuniones sin foco y que no aporten nada al equipo o producto.
  • Mejorando la comunicación del equipo, haciendo que estén mas coordinados y tengan menos esperas y colisiones entre ellos.
  • Acercando el feedback y testing al momento de desarrollo. Esto hace que la corrección tarde hasta 20 veces menos que si se hubiera hecho semanas después.
  • Permitiendo al equipo pensar de qué modo mejorar a si mismo. Al juntarse en las retrospectivas les permite analizar cómo eliminar los impedimentos y desperdicios (waste) para hacer más y más puntos de historia cada sprint.
  • Permitiendo hacer experimentos de mejora durante un sprint y evaluar si seguirlo o no. Un equipo puede probar algo que parece una locura durante un sprint y evaluar en la siguiente retrospectiva su resultado. De este modo es posible encontrar modos ingeniosos de mejorar la productividad sin poner en riesgo el proyecto.

La proxima vez que explique Scrum, no olvidaré en contar ambas facetas (efectividad y eficiencia). Efectivamente se prima la efectividad ante la eficiencia, pero hay que transmitir que se puede conseguir mucha más eficiencia con equipo Scrum que en equipos tradicionales.