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.