¿Sprints cortos o Sprints largos? ¿Cuál es mejor?

Hace poco tuve la oportunidad de participar como consultor en un espacio en donde su buscaba definir la mejor forma (desde el punto de vista “metodológico” -Palabras del cliente), para abordar un proyecto cuya complejidad era evidente y que además contará con ciertas particularidades propias del negocio, que hacen que fuese indispensable determinar la mejor forma de abordar el proyecto.

Como siempre, cae a este tipo de espacio la pregunta: ¿lo abordamos con agile o con waterfall? (en un futuro post abordaré esta pregunta), sin duda mi querido amigo lector ya entenderás el porqué de la invitación que me realizaron a participar de dicho espacio.

Luego de determinar que efectivamente seria bajo agile que seria abordado el proyecto, llega a la mesa una nueva pregunta con la que me he topado en diferentes espacios con diferentes tipos de perfiles organizacionales y es ¿Cuál es el tamaño correcto o idóneo del Sprint para obtener mejores resultados?, de la respuesta que di a esa consulta nació este post, por lo que comparto un poco contigo mi querido amigo lector lo respondido.

Para empezar mi respuesta tome como referencia uno de los principios del manifiesto ágil que dice: “Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible”. Esto está completamente en línea con el Mindset agile y particularmente con Scrum (En el proyecto en mención, cabe mencionar que existirán varios equipos y que no todos trabajaran bajo scrum). Después de todo, El Mindset agile y el framework Scrum, nos invita a trabajar bajo iteraciones que demoran entre una semana y un mes. Y la idea es que al final de cada iteración, se entregue un incremento de producto “Terminado”.

Para muchos, estas iteraciones no son lo suficientemente cortas. Modern Agile, por ejemplo, dice que un par de semanas no es suficiente. Manifiesta que se debe «entregar valor continuamente». Entonces vino sobre la mesa la siguiente pregunta: ¿Cómo encaja esto, con el objetivo del proyecto y la forma de trabajo con la que lo abordaremos?

Para continuar mi argumentación y así llegar a la respuesta deseada, pase entonces a explicar porque utilizamos marcos de trabajo agiles, para resolver problemas adaptativos complejos, explicaba como por ejemplo Scrum es » Un marco de trabajo por el cual las personas pueden acometer problemas complejos adaptativos, a la vez que entregar productos del máximo valor posible productiva y creativamente» (tome como base la definición oficial de la guía de scrum).

Hice énfasis, en dos palabras claves que son: Complejo y adaptativo. Dado que, en un entorno complejo (como el que se debe abordar en este tipo de proyectos), debe poder adaptarse a nuevas ideas. Y lo mejor es poder adaptarse tan pronto como sea posible. A veces, el feedback, se puede dar en pequeños complementos para el producto. Esto permitirá tener ciclos cortos de retroalimentación o feedback, por parte del cliente. Por lo que, particularmente en Scrum esto resultaría en tener Sprints cortos.

Ahora, también plantee que veo un riesgo en este enfoque. Al centrarse en la entrega de pequeños incrementos, existe la posibilidad de que no se considere la imagen general. Es decir que los equipos (participantes del proyecto), terminanen cayendo en el problema de convertirse en una fábrica de características (centrarse en una entrega rápida en lugar de un resultado valioso – Este problema ya lo toue antes en un anterior post).

Les explicaba que, los ciclos de retroalimentación cortos requieren dedicación y enfoque, extrayendo lecciones del incremento y adaptándose cada vez. Por lo que los invite a Imaginarse el hecho de tener que hacer esto todos los días. Es un trabajo duro respondieron.

Continúe manifestándoles que también hay entornos de productos en los que se necesita más tiempo para entenderlo y comprenderlo lo suficiente como para tomar decisiones informadas. Por lo tanto, en este tipo de entornos no se logra el éxito, dividiendo los elementos en pedazos más pequeños, porque no habrá nada significativo para cortar en algún momento. Contrariamente a la creencia popular, no hay nada de malo en tener grandes porciones de trabajo. Siempre que los elementos sean lo más simples posible (aquí les hice referencia a otro principio del manifiesto ágil, “el arte de maximizar el trabajo no realizado”. Por lo que conclui esta primera parte con una frase popular que dice: «En entornos complejos, lo que sucederá es desconocido».

Les indique además que, hay otra perspectiva a considerar y es que de tener Sprints más cortos significaría más revisiones de Sprint, lo que significa a su vez, más oportunidades para inspeccionar y adaptarse junto con las partes interesadas.

Como conclusión les manifesté que, por el tipo y objetivo del proyecto, tenían motivos suficientes, para necesitar feedback de los usuarios lo más rápido posible. Sin embargo, lo que realmente es posible depende del entorno del producto. Algunos entornos permiten dar pequeños pasos y recibir feedback casi continuamente. Otros entornos tienen características diferentes que requieren más excavación y experimentación para crear un incremento.

Entonces, como conclusión, explicaba que, para determinar el tamaño idóneo del sprint requerido para cada proyecto, se debe verificar las características del entorno del producto, del proyecto y del equipo. Por lo tanto, no hay una respuesta única que sirva como “bala de plata”, para todo tipo de proyecto. Esta es la razón por la cual Scrum (por ejemplo), da la bienvenida a los experimentos al probar algo, inspeccionar cuál es el impacto y luego adaptarse en función de nuevas ideas.

Por lo cual mi recomendación fue que no basaran su decisión final del tamaño del sprint en suposiciones. Como, por ejemplo, Sprints más cortos siempre son mejores. Les indicaba que lo mejor era que basaran dicha decisión en lo que aprendieran de la experimentación y el análisis realizado.

Con lo cual para grata sorpresa, el día de hoy mi querido amigo lector me comentaron que decidieron hacer los dos primeros sprint del proyecto a modo de experimentación con un tiempo de 2 semanas, e iban a analizar como les iba para determinar si debían aumentar o disminuir el número de semanas del sprint, con el que iban a desarrollar el resto del proyecto.

Gracias por tu tiempo.

Pd:Te invito a dar un vistazo a mi libro recomendado del mes (Clic Aquí)

Saludos,


También te puede interesar Leer



SUSCRÍBETE A MI BLOG

Y cada vez que realice una nueva publicación, recíbela al instante.


    
Suscríbete al Blog
Y entérate cada vez que realice una nueva publicación.
Suscribirse
Te puedes dar de baja cuando lo desees!
close-link
A %d blogueros les gusta esto: