Más allá del sprint: ¿Por qué la IA está revolucionando la agilidad y poniendo el mundo empresarial de cabeza?

Más allá del sprint: ¿Por qué la IA está revolucionando la agilidad y poniendo el mundo empresarial de cabeza?

Dos fuerzas transformadoras, la transformación ágil y la inteligencia artificial, están convergiendo para crear una sinergia dinámica que está revolucionando la forma en que las empresas innovan y responden a las demandas del mercado. Al integrar prácticas ágiles con tecnología de inteligencia artificial, las empresas pueden aprovechar información en tiempo real, optimizar procesos y fomentar una cultura de aprendizaje y mejora continuos.

Aclaremos cómo estas fuerzas trabajan juntas para acelerar la innovación y la respuesta del mercado.

La convergencia de Ágil y la IA

Transformación ágil: un resumen

La transformación ágil es más que un método, es un cambio cultural. Basados en valores como la colaboración, la flexibilidad y la orientación al cliente, los enfoques ágiles permiten a los equipos trabajar en ciclos iterativos, ofrecer valor de forma continua y adaptarse rápidamente a los escenarios cambiantes. Los principales beneficios de la transformación ágil incluyen:

·       Mejora de la colaboración y comunicación en equipo

·       Ciclos de retroalimentación más rápidos y desarrollo iterativo

·       Mayor capacidad para adaptarse en función de los conocimientos del mercado

El papel de la inteligencia artificial

La IA, en forma de aprendizaje automático y procesamiento del lenguaje natural, está transformando diversos aspectos de las operaciones comerciales. Desde la automatización de tareas rutinarias hasta la generación de información detallada a partir de datos, la IA se está convirtiendo en una parte integral de los procesos de toma de decisiones. En un contexto ágil, la IA puede:

· Proporcionar análisis predictivos que informen la toma de decisiones estratégicas.

· Automatizar tareas repetitivas, habilitando a los equipos a concentrarse en el trabajo de alto valor.

· Mejorar la priorización de las historias de usuario y el orden del backlog de producto mediante información basada en datos.

· Optimizar las pruebas y el control de calidad a través de la automatización de pruebas impulsada por IA.

Integración de la IA con prácticas ágiles

Mejorar la toma de decisiones con información basada en datos

Una de las principales formas en que la IA mejora la transformación ágil es a través del poder de los datos. Los equipos ágiles dependen de la retroalimentación rápida e iterativa para informar sus ciclos de desarrollo de productos. La IA puede analizar grandes cantidades de datos (desde análisis del comportamiento de los usuarios hasta tendencias del mercado) y ofrecer información que oriente la priorización de las historias de los usuarios y el refinamiento del backlog de producto.

Ejemplo:

Un equipo de productos digitales utiliza análisis basados en IA para supervisar la interacción de los usuarios en su aplicación móvil. El sistema de IA identifica patrones en el comportamiento de los usuarios y sugiere qué funciones son las más valiosas o las que tienen un rendimiento inferior. Durante la planificación del sprint, estos conocimientos ayudan al equipo a decidir qué funciones iterar o priorizar para los próximos lanzamientos, lo que da como resultado un producto que se ajusta mejor a las necesidades de los usuarios.

Automatización de tareas repetitivas

Los métodos ágiles tradicionales enfatizan la iteración rápida y la mejora continua. Sin embargo, las tareas repetitivas, como las revisiones de código, las pruebas y la documentación, pueden ralentizar este proceso. Las herramientas de IA pueden automatizar estas tareas, lo que libera a los miembros del equipo para que se concentren en la creatividad y la planificación estratégica.

Ejemplo:

En un entorno de desarrollo de software, una herramienta de prueba impulsada por IA genera y ejecuta automáticamente casos de prueba durante cada sprint. Esto no solo acelera la fase de prueba, sino que también garantiza que cada iteración sea sólida y libre de regresiones. Como resultado, el ciclo de desarrollo se vuelve más eficiente y el equipo puede implementar software de calidad a un ritmo más rápido.

Optimización del mapeo y priorización de historias de usuario

El mapeo de historias de usuario es una piedra angular del desarrollo ágil, ya que proporciona una representación visual del recorrido del producto y ayuda a los equipos a priorizar el trabajo en función del valor para el cliente. La integración de la IA en este proceso puede mejorar la priorización mediante el análisis de datos históricos, retroalimentación de los clientes y tendencias del mercado.

Ejemplo:

Considere una plataforma de comercio electrónico que utiliza una herramienta de mapeo de historias de usuario mejorada con IA. La herramienta procesa las reseñas de los clientes, los datos de compra y los patrones de navegación para destacar qué características son las más importantes para los usuarios. Sugiere ajustes al backlog de producto, lo que garantiza que las características más impactantes se desarrollen primero. Esto conduce a una estrategia de desarrollo de productos más enfocada y eficaz.

Retroalimentación en tiempo real y aprendizaje continuo

Los equipos ágiles evolucionan gracias a los ciclos cortos de retroalimentación. Las prácticas ágiles cotidianas fomentan las retrospectivas periódicas para reflexionar sobre lo que funcionó y lo que no. La IA puede mejorar estas prácticas al proporcionar retroalimentación en tiempo real, lo que permite a los equipos realizar ajustes durante el sprint en lugar de esperar hasta el final.

Ejemplo:

Un equipo de marketing que ejecuta varias campañas digitales utiliza una plataforma de análisis basada en inteligencia artificial para supervisar el rendimiento de las campañas en tiempo real. La plataforma utiliza algoritmos de aprendizaje automático para detectar tendencias y predecir resultados, lo que permite al equipo ajustar las estrategias sobre la marcha. Esta agilidad garantiza que las iniciativas de marketing sigan siendo eficaces incluso cuando las condiciones del mercado cambien.

Analogía cotidiana: el GPS inteligente para su recorrido empresarial

Imagina que estás de viaje por carretera con un mapa de papel tradicional en la mano. El mapa te da una idea general de la ruta, pero si hay un obstáculo inesperado, un atasco o un desvío, tienes que parar y volver a leer el mapa manualmente, lo que suele provocar retrasos. Ahora, piensa en un sistema GPS moderno que no solo te proporcione la mejor ruta, sino que también se ajuste en tiempo real en función de los datos de tráfico, las condiciones de la carretera y tus hábitos de conducción. Este GPS aprende continuamente de tu viaje y te ofrece sugerencias para evitar retrasos y llegar a tu destino de forma más eficiente.

En esta analogía:

· El mapa de papel representa las prácticas ágiles tradicionales. Si bien proporciona un marco sólido para el desarrollo iterativo y la flexibilidad, carece de capacidades de ajuste dinámico en tiempo real.

· Smart GPS encarna la integración de la IA en las prácticas ágiles. Complementa los principios ágiles con datos en tiempo real y análisis predictivos, lo que garantiza que su proyecto se mantenga en el camino óptimo a pesar de los desafíos imprevistos.

Así como un GPS inteligente ayuda a navegar por rutas complejas con facilidad, las prácticas ágiles mejoradas con IA ayudan a los equipos a navegar por las complejidades de los panoramas modernos de las organizaciones, garantizando cambios más rápidos y una toma de decisiones más informada.

Mejores prácticas para integrar IA y Ágil

1. Comience con poco y aumente gradualmente

Hay cosas que no cambian. Comience con proyectos piloto para probar la integración de herramientas de IA en marcos ágiles. Identifique un proceso o problema específico en el que la IA pueda agregar valor (como la priorización de tareas pendientes o las pruebas automatizadas) y expanda gradualmente su uso en todos los equipos y proyectos.

2. Fomente una cultura de experimentación

Tanto la transformación ágil como la integración de la IA requieren una cultura que fomente la experimentación y el aprendizaje. Incentive a los equipos a probar nuevas herramientas de IA, compartir conocimientos e iterar procesos. Este enfoque no solo mejora la eficiencia, sino que también fomenta la innovación y la adaptabilidad.

3. Invierta en formación y mejora de las competencias

Para aprovechar al máximo las capacidades de la IA, los equipos deben comprender cómo trabajar con estas herramientas de manera eficaz. Invierta en programas de capacitación que mejoren las habilidades digitales y analíticas de los miembros del equipo, asegurándose de que se sientan cómodos y sean competentes en el uso de tecnologías de IA junto con metodologías ágiles.

4. Asegúrese de estar alineado con los objetivos del negocio

La integración de la IA siempre debe estar alineada con los objetivos estratégicos de su organización. Utilice marcos como Objetivos y resultados clave (OKR) para garantizar que las iniciativas ágiles mejoradas con IA contribuyan directamente a los resultados del negocio, ya sea acelerando el tiempo de salida al mercado, mejorando la satisfacción del cliente o aumentando la eficiencia operativa, como siempre, cuidando a sus colaboradores y su entorno.

5. Mantenga la transparencia y la colaboración

Las herramientas de IA generan enormes cantidades de datos y conocimientos. Para maximizar su impacto, fomente un entorno de transparencia en el que este conocimiento se comparta abiertamente con todos los miembros del equipo. La toma de decisiones colaborativa garantizará que todo el equipo comprenda y confíe en las recomendaciones de la IA.

El camino por delante

Es una hipótesis, pero algunos estamos yendo ya en esa dirección: la fusión de métodos ágiles e inteligencia artificial no es una tendencia pasajera, sino un cambio fundamental en la forma en que las organizaciones abordan la innovación y la capacidad de respuesta al mercado. En Experimentum ya lo estamos haciendo. A medida que las empresas sigan avanzando en su transformación digital, aquellas que integren con éxito estos enfoques estarán mejor posicionadas para responder a la dinámica del mercado, innovar rápidamente y mantener una ventaja de la que puedan sacar provecho.

Únete a la conversación

¿Cómo aprovecha su organización la IA en sus prácticas ágiles? ¿Qué desafíos o éxitos ha experimentado? Comparta sus opiniones y únase a la discusión en los comentarios a continuación.

illegitimus non-interruptus

Imagen de Christine Schmidt en Pixabay

Dentro de lo más común en los escenarios de alta incertidumbre, ambigüedad y volatilidad en los que trabajamos están las interrupciones a nuestro trabajo diario. Mal manejadas, estas obstrucciones se pueden convertir en un gran dolor de cabeza para la persona, para el equipo y para la organización y, por consiguiente, para el cliente final.

Entre otras consecuencias no menos graves, tenemos la pérdida de foco en lo que hacemos, con la consiguiente parálisis o alejamiento del objetivo del sprint. Además, el estrés ocasionado por las intermisiones puede llegar a ser contraproducente para la salud del producto, pero, más crítico aún, para la salud de las personas.

Algunas investigaciones [1] muestran que la multitarea ocasionada, entre otras cosas, por las interrupciones frecuentes en el trabajo, te hace estúpido y lento, al tiempo que aumenta el estrés y acelera el envejecimiento. Adicionalmente, la multitarea puede reducir la velocidad o el ritmo de un equipo tanto como a nada.

Fui desarrollador de software durante diecisiete años y sé bien que la multitarea siempre ha sido una parte inherente del desarrollo de software y la experimenté como la principal fuente de interrupciones debido al cambio continuo de tareas en los equipos de desarrollo de software.

Este trabajo implicaba para mí una combinación de tareas analíticas y creativas, y requería de una carga significativa en mi “memoria de trabajo” y en la toma de decisiones. Esto imponía una carga cognitiva que me hacía perder el enfoque y la concentración mientras trabajaba, lo que afectaba mi productividad. Perentorio.

Los invito a visitar este enlace, donde podrán ver de manera gráfica y cómica a la vez, por qué no deberías interrumpir a un programador cuando está haciendo su tarea:

https://heeris.id.au/2013/this-is-why-you-shouldnt-interrupt-a-programmer/

Pero estas dificultades no son propias solo del desarrollo de software. Como mencioné antes, todo trabajo bajo escenarios VUCA/BANI está supeditado a tener tales aprietos. ¿Entonces, qué hacer con estas interrupciones si son inherentes a nuestro trabajo?

Si estamos usando Scrum, las demandas de distintas áreas, combinadas con la interferencia de la gerencia, pueden causar una disfunción crónica en el equipo, fallas repetidas en sprints, incumplimiento en fechas de lanzamiento e incluso fallas en la empresa. Muchas veces un equipo Scrum sirve a muchos interesados, quienes compiten por la atención del equipo.

Patrones Scrum

En Scrum hemos aprendido a usar patrones, estos son modelos de comportamiento que nos ayudan a solucionar problemas comunes. Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno, y luego describe el núcleo de la solución a ese problema, de tal manera que puedes usar esta solución un millón de veces, sin hacerlo dos veces de la misma manera. O algo así nos enseñó Christopher Alexander en su libro A Pattern Language. Alexander es conocido como el “padre de los patrones”. Para conocer un poco más sobre esto puedes ver mi presentación en:

https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/

Un patrón nos ayuda a explorar:

·       El problema, su naturaleza, la causa raíz. El problema detrás del problema.

·       Las fuerzas que interactúan que afectan el problema (que lo hacen difícil), incomprensible a veces.

·       La solución. Y por qué funciona esta solución. En qué condiciones funciona. Y

·       El contexto resultante de aplicarlo en un escenario de la vida real.

illegitimus non-interruptus

A veces también llamado el patrón del búfer de interrupción (Interrupt Buffer). Es un hecho, cambiar las prioridades o los problemas en el campo a menudo interrumpe el trabajo de los equipos Scrum durante un sprint.

En general, un equipo Scrum es un equipo o recurso comunitario que satisface las necesidades de muchas partes interesadas. Además, es un recurso crítico para crear nuevos productos y mantener productos existentes [2]. A menudo, la propiedad deficiente del producto permite que las prioridades en competencia de una empresa lleguen a un equipo Scrum. Por estas y muchas otras razones, un equipo Scrum siempre está expuesto a interrupciones que obstaculizan la producción.

Figura 2: principales tipos de interrupción a un equipo

Dada esa situación, lo que hacemos, siguiendo los lineamientos de este patrón es asignar explícitamente tiempo para las interrupciones y no permitimos más trabajo del que cabe dentro de la asignación. Ahora bien, si el trabajo excede la asignación (se desborda el búfer), podemos tomar la decisión de abortar el Sprint. Si el búfer se excede, es posible que tengamos un problema mayúsculo, uno cuya solución seguramente necesite del uso de otros patrones o de cambios en la estrategia actual de trabajo. Una estrategia inicial que se aplica en estos casos es cancelar o abortar el sprint.

Veamos esta solución con un poco más de detalle…

1.    Lo primero es tener una idea aproximada de cuanto esfuerzo o tiempo necesitamos asignar al búfer. O sea, decidir el tamaño del búfer de interrupción en el sprint backlog. Una revisión tipo “Clima de ayer” nos puede dar una idea. Es decir, revisar qué tanto esfuerzo han requerido las interrupciones en el sprint anterior o quizás un promedio de los últimos tres sprints.

En la figura a continuación vemos, como ejemplo, que el búfer de interrupción se ha movido alrededor de los 7 puntos, tanto en el sprint anterior, como en los tres últimos. De hecho, la gráfica muestra un comportamiento similar en los últimos 7 sprints, pero esto es apenas una casualidad. Quizás se trate de un equipo con una alta sinergia y que tiene un histórico bastante bien conocido. Sin embargo, no es tan bueno considerar lo que ha pasado durante tiempos más extensos, más allá de dos o tres sprints, ya que las condiciones del equipo y del trabajo pueden haber cambiado de manera considerable.

Figura 3: gráfico de la velocidad del equipo en los últimos sprints. Incluye búfer de interrupción.

Entonces, aunque la velocidad del equipo, según la gráfica histórica, es de alrededor de 27 puntos (usando también el promedio de los tres últimos sprints), el equipo solo se comprometerá con 20 puntos de historia y considerará un tamaño de búfer de 7 puntos.

2.    ¿Y entonces qué hacemos cuando se presenta una interrupción? Respuesta: todas las solicitudes no triviales deben pasar por el Product Owner para su clasificación. Es importante esto de lo “no trivial”. No se trata de que el Product Owner “apruebe” todas las actividades no planeadas para el sprint. Pero sí las que sabemos que pueden impactar en negativo el recorrido hacia el objetivo del sprint.

Figura 4: comportamiento del búfer de interrupción en el sprint backlog.

3.    De manera natural vamos “midiendo” y evaluando el “llenado” del búfer de interrupción. Es una actividad que debe inyectarse al ADN del equipo, para que se haya sin mayores atribulaciones. Cuando el búfer se “llene” y comience a desbordarse, es decir, el Product Owner o el equipo pone un punto de más de los indicados en el búfer, el Scrum Team debe o debería abortar el Sprint, no sin antes, hacer el análisis de causa en una retrospectiva.

Lo que hemos comprobado es que esta estrategia ayudará al equipo a volver a planificar durante el Sprint para aumentar las posibilidades de entregar el Incremento completo del producto. Ya por lineamiento de Scrum habíamos aprendido que, durante el sprint, “el alcance se puede aclarar y renegociar con el Product Owner a medida que se aprende más”.

Recomendaciones

En la práctica, el búfer de interrupción puede ser un porcentaje de tiempo. Por ejemplo, el 7 % del tiempo del sprint, el 10 %, el 14 %, etcétera.

¿Cuánto tiempo? ¿Cuál es el tamaño ideal del búfer de interrupción? Esa es una cuestión cuya respuesta debe encontrar el equipo. Para considerar: el objetivo de todo equipo Scrum es entregar valor (un incremento de valor) al final de cada sprint.  Entonces, el foco del equipo debe estar en este aspecto: la entrega de valor. Pero, incluso más importante, son las tareas o actividades “kaizen”, sí, esas de mejoramiento, a las que también hay que dedicarles tiempo y esfuerzo y con una prioridad máxima.

En general, debería ser el Dueño del Producto quien equilibre el tamaño del búfer para no descompensar la satisfacción del cliente en el corto plazo y mucho menos disminuir la generación de ingresos para la organización. El objetivo de todo Product Owner virtuoso es mantener con el equipo un tamaño de búfer tal que no se impacte en negativo la entrega de valor.

Y no, las tareas de mejora continua (kaizen) no son consideradas como “de interrupción”. De hecho, estas actividades deben planificadas como las de mayor prioridad dentro de un sprint. De lo contrario, ¿cómo aseguramos que el equipo mejore en el mediano y largo plazo? ¿Cómo aseguramos que en el futuro las cosas se hagan mejor y haya tiempo para innovar o ser más disruptivos? (Ver en la imagen donde están estas tareas en el Sprint Backlog).

Lo ideal es que el búfer de interrupción tienda a no estar lleno, lo que permitirá que el equipo termine temprano y avance desde el trabajo atrasado o trabaje para eliminar los impedimentos. Y esto es primordial porque los equipos que terminan temprano aceleran más rápido. Este es otro patrón Scrum cuya información, por ahora, puedes revisar en:

https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/

Finalmente, si el equipo usa el patrón el Clima de Ayer para dimensionar el búfer de interrupción, como lo expliqué en el paso 1, entonces el búfer casi nunca se llena y podemos empezar a pensar en reducir gradualmente su tamaño, lo que hará desaparecer el problema de interrupción. Aunque en la práctica, quizás nunca llegue a cero. Es lo que he experimentado.

Algunas referencias

[1] Darren Rowley and Manfred Lange. “Forming to Performing: The Evolution of an Agile Team.” In Proceedings of Agile 2007, Washington, D.C., 2007, pp. 408-414.

[2] Ver definición de Producto en la guía de Scrum.

 

Para conocer más de patrones Scrum, puedes ver esta presentación y video: https://luchosalazar.com/2020/05/21/patrones-scrum-un-enfoque-adaptativo/

En particular, para saber más del patrón Illegitimus non interruptus, puedes mirar esta otra presentación:

https://luchosalazar.com/2020/06/17/patrones-scrum-un-enfoque-adaptativo-parte-2/

El libro de los patrones Scrum, A Scrum Book, de Coplien, Sutherland y otros.

Ritmo sostenido, cadencia y el ciclo lunar

Imagen de Gerd Altmann en Pixabay

Hablaba con mi amiga Claudia Toscano sobre el por qué la duración de los Sprints debería ser siempre lo mismo, el por qué no era buena idea estar cambiando de duración a las iteraciones en Scrum y lo primero que se me ocurrió es que una de las razones principales es el ritmo, precisamente ese ritmo sostenido del que hablamos ya desde el manifiesto ágil, que nos permite conocer con más precisión (o menos imprecisión) la capacidad real del equipo.

Me refería a ese principio del Manifiesto que dice:

“Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida”.

Decíamos que ese ritmo constante tiene otros beneficios también, entre ellos mayor productividad, elimina el estar pensando precisamente eso de "este sprint de cuánto tiempo será". Esas conversaciones que son desperdicio y restan productividad desde el sprint anterior en donde las personas están sugiriendo que "el próximo sprint sea de 10 días o de 5", "qué tal si lo hacemos de 15", evita esos diálogos que generan estrés, agregan confusión a un contexto que quizás ya tiene mucha incertidumbre. En general, se reduce la complejidad, esa complejidad inherente a tener que tomar ese tipo de decisiones cada vez que va a empezar un nuevo sprint, aun desde el anterior.

Hay menos inseguridad. Hay menos gasto de energía y se genera menos estrés. Además, con el tiempo, los eventos internos del Sprint son más efectivos porque la gente ya conoce su  ritmo y eso es muy importante en la Planificación, porque el equipo ya tiene una proyección de lo que puede hacer en un Sprint. Hemos notado que al mantener un ritmo y vigilarlo continuamente ayuda a mejorar la eficiencia de las personas en el trabajo, reduce los riesgos inherentes al trabajo del conocimiento y al producto o servicio, disminuye el desperdicio que se pueda generar, sobre todo si mantenemos los elementos del backlog (historias de usuario) pequeños, y contribuye significativamente a la mejora continua.

Algo que nos pasaba con nuestra forma de trabajar anterior, en Cascada, era que lenta y casi imperceptiblemente empezábamos a caer en lo que podríamos llamar "vórtice de procrastinación". Uno en el que rápidamente estábamos perdiendo contacto con los clientes o consumidores, con los interesados, pero incluso más grave aún, con los propios compañeros del equipo. No sabíamos cuando íbamos a terminar algo, a pesar de los planes “detallados” a que éramos sometidos de manera dictatorial y el fin de una actividad pasaba de horas o días a semanas y rápidamente a meses… ¡un día a la vez!

¡Eso definitivamente no tenía nada de divertido!

¿Por qué? Porque somos seres rítmicos por naturaleza. Seguimos ciclos de manera casi ritual, por ejemplo, estamos despiertos y dormimos más o menos a las mismas horas, siempre. El ritmo nos ayuda a relajarnos, a calmar el estrés, nos permite determinar bloques de tiempos para actividades específicas y todo ello nos posibilita adaptarnos mejor a las circunstancias, porque podemos predecir o proyectar lo que podemos hacer y cómo hacerlo sin estrés, de manera más o menos divertida.

El Sprint en Scrum y el ciclo lunar

Imagen de Syaibatul Hamdi en Pixabay

El Sprint es el corazón de Scrum y en Scrum todo ocurre en el marco de un Sprint. El objetivo en el Sprint es crear un incremento de producto “Terminado”, utilizable y potencialmente desplegable en un ambiente donde al menos un grupo de usuarios o consumidores pueda “jugar” con él. De la guía también aprendimos que “es más conveniente si la duración de los Sprints es consistente a lo largo del esfuerzo de desarrollo”. Ya hemos establecido ampliamente el porqué es necesaria es invariabilidad.

Una de las duraciones más ampliamente usadas por los equipos en todo el mundo es 2 semanas para sus Sprints, según indica The 2015 State of Scrum Report de la Scrum Alliance. Más sobre este reporte en:

https://www.scrumalliance.org/ScrumRedesignDEVSite/media/scrumalliancemedia/files%20and%20pdfs/state%20of%20scrum/scrum-alliance-state-of-scrum-2015.pdf

Pero también es importante definir Sprints cuyo inicio y fin concuerden con los ciclos lunares. Esto se les hace más natural a las personas porque nos adaptamos mejor a esas cadencias que son habituales para nosotros. Por eso siempre estamos buscando iniciar Sprints un lunes y terminarlos un viernes. Sin embargo, en países como Colombia donde las festividades fueron modificadas de manera artificiosa hace ya varias décadas, hay que adaptar esos ciclos para acomodar tales eventos y otras pausas habituales en las culturas locales. Por ejemplo, dado que en Colombia hay muchos lunes festivos, podría ser interesante experimentar iniciando los Sprints un martes y hacerlos de nueve días en vez de diez. En el caso de que durante ese ciclo de dos semanas no haya días festivos, el décimo día se puede usar para trabajar en la mejora del equipo o en apoyo a otros equipos y áreas de la organización, o simplemente en socialización al interior de la empresa. También son útiles estos días para realizar hackatones u otras actividades que fomenten la innovación.

De esta manera, los equipos establecen una cadencia acostumbrada y fijan expectativas con base en las fechas de finalización de los Sprints. El equipo puede sincronizarse con otros equipos para entregar incrementos de producto en el que estén trabajando en conjunto o para tener un mejor manejo de las dependencias entre ellos. Esto reduce los conflictos entre esos equipos y las personas nos sentimos más a gusto y cómodas trabajando con el horizonte de los ciclos naturales a los nos que hemos habituado desde niños. Esto mejora la motivación del equipo y afianza los valores y la visión establecidos.

Conclusión

Tener este tipo de hábitos, como Sprints de duración fija, reuniones diarias a la misma hora y en el mismo lugar, y conocer con anticipación las fechas de otros eventos como la Planificación, la Revisión o la Retrospectiva, permite que los miembros del equipo se enfoquen en sus tareas principales y hagan lo que mejor saben hacer, que es manejar la incertidumbre, los cambios y la ambigüedad inherente al tipo de tareas que hacemos diariamente, es decir, esa otra cara variable del trabajo.

Referencias

Para saber más sobre patrones Scrum puedes consultar el libro:

A Scrum Book: The Spirit of the Game, de Sutherland , Coplien , den Hollander y otros.

El último día del sprint

Imagen tomada de Pixabay

"Comenzar fuerte es bueno. Terminar fuerte es épico". [Robin Sharma]

Desde siempre he visto como los equipos de desarrollo de producto, especialmente los de desarrollo de software, emprenden los más titánicos proyectos con unas ganas inconmensurables, una fuerza interior, personal y grupal, que parece infinita y una pasión energizante que enciende los motores de la creación, el trabajo en equipo y los deseos de triunfar.

Nada muy distinto a lo que ocurre hoy en cada iteración de cualquier iniciativa o esfuerzo de desarrollo: el primer día los equipos planifican su propósito de vida para las siguientes jornadas y hasta son capaces de hacer un pronóstico de cómo alcanzarán la meta del sprint que comienza. Y diariamente acuden a la cita de la colaboración y la creación de valor con la mejor sonrisa y disposición.

O así es… ¡hasta que se acerca el fin de la iteración!

Un sprint es un bloque de tiempo breve en el que hay que mantener el foco y el esfuerzo regulado para terminarlo como lo empezamos. Con brío y pundonor. Pero eso no está ocurriendo con muchos equipos. En mis continuos ejercicios de acompañamiento y consultoría me sigo encontrando las historias de nunca acabar:

• Es que no hicimos retrospectiva para terminar las historias de usuario
• Programadores escribiendo programas minutos antes de la revisión con los interesados. ¿Y las pruebas?
• Vamos a aplazar la revisión. Mañana hacemos la planificación del próximo sprint, luego la retrospectiva. Pasado mañana hacemos la revisión de este sprint que termina.
• Solicitemos un aplazamiento del paso a producción para el próximo sprint.
• Pidamos una extensión del sprint. Necesitamos dos o tres días más para terminar lo prometido.
• Y la lista continúa.

Entre otras cosas, es a lo que se refieren Jeff y Ken cuando dicen que Scrum es “difícil de llegar a dominar”. Pero no se trata solo de Scrum. Es esa falta de disciplina que tenemos para hacer que las cosas terminen, ese apego a lo que es y no queremos dejar ir, inherente a todo ser humano. Es esa facilidad para conjugar el verbo empezar pero a la vez esa dificultad para conjugar la voz finalizar.

El último día del Sprint comienza el primer día del Sprint

Imagen tomada de Pixabay

Hagamos un plan hasta el penúltimo día del sprint, sea cual fuere su duración. Sí, con historias de usuario más pequeñas es posible. Y sí, todavía pueden ser entre 6 y 10 historias de usuario.

Recordemos en la planificación que la revisión y la retrospectiva requieren de preparación. No es algo que ocurre solo porque llegó la hora de hacerse o porque el marco de trabajo lo exige. Nunca veo esas tareas de preparación en el backlog del sprint. Y no, no son historias de usuario. Son actividades que bien pueden realizar el Scrum Master, pero también el Dueño de Producto o cualquier otro miembro del equipo, aunque preferiblemente uno de los dos primeros.

En cada reunión diaria, examinemos efectivamente cómo vamos hacia el cumplimiento de la meta del sprint y qué estamos haciendo específicamente para preparar esa gran fiesta que es la revisión del incremento con los interesados, no solo con el Dueño de Producto. Y, ni más faltaba, vayamos pensando qué clase de retrospectiva queremos hacer. Y sí, quince minutos es suficiente para ello. Durante la preparación de estos eventos finales también surgen impedimentos que hay que resolver con prontitud.

Recordemos, si no aseguramos la calidad del producto, no está terminado. Siempre pongamos de manifiesto que solo revisaremos lo que verdaderamente está terminado. Y no, casi terminado no es terminado.

El Scrum Master bien puede crear una campaña de expectativa hacia el exterior del equipo, dirigida a los interesados, sobre la próxima revisión, el siguiente gran hito. Y también hacia el interior del equipo: la siguiente gran oportunidad de inspección y adaptación, la retrospectiva. Sin que esto quiera decir que los demás eventos no son oportunidades de evaluación y ajuste, en el sentido de mejora continua.

Promovamos el descanso placentero y el sueño profundo, incluso la relajación y la meditación, la noche antes del día final del sprint. Descansemos, estemos con nuestras familias o amigos, salgamos a cenar, a disfrutar de una caminata a la luz de la luna con quien mejor nos sintamos o simplemente reposemos al ritmo que nuestro corazón dicte. Preparémonos así para la gestación de un día de buenas noticias con el resto del ecosistema organizacional.

Participemos de los preparativos, una revisión interna previa del producto no está demás. Lleguemos antes que todos los demás y recibamos a los invitados a la revisión, si los hay, con una gran sonrisa, con sendos mensajes de bienvenida, con una bebida. Y no, no es hora de licor.

[De la revisión propiamente dicha hemos hablado en variadas ocasiones así que no voy a entrar detalles sobre lo que debe o debería ocurrir durante la misma]*.

Aunque esto es del ámbito de la reunión misma, no dejemos de solicitar y recibir con la mente bien abierta toda la retroalimentación que nos brinden los asistentes. Ese será el motor que nos permita hacerlo mejor la siguiente vez. Y finalicemos con los agradecimientos respectivos, los aplausos, los abrazos, ¿por qué no? Después de todo, estamos todos en el desafío de deleitar a los consumidores finales de nuestro producto.

Finalmente, hagamos una pausa, tomemos un café y vamos a la retrospectiva. Esa cita íntima y necesaria en cada iteración. [Tampoco me extenderé mucho en este apartado]**

Al final del día, piensa que mañana seguirás mejorando. Es todo lo que necesitas para triunfar.

Apostilla:

No solo el último día, sino todos los días de tu vida, tiende la cama antes de salir. Si al final tienes un mal día o muchos malos días, siempre te recibirá una cama limpia y tendida. ¡Es la clave para cambiar el mundo!

-----

* Por ejemplo, además de lo que dice la guía de Scrum, mi gran amigo Jorge Abad ha publicado, entre otros, los siguientes artículos sobre el tema de la revisión del sprint:

[AgendaScrum] Pasos para Realizar el Review o Revisión

Tipde Scrum: La calificación del Product Owner al finalizar el Sprint

Buenasy Malas Prácticas en el Review / Demo de Scrum

Lacara del santo hace el milagro. Efectividad del Planning y Review

Los invito a que los lean. Encontrarán consejos muy útiles cuando de preparar y realizar este evento del que les he hablado se trata.

** Por ejemplo, pueden leer mis artículos:

De Retrospectivas y de Ratones

Directiva Primaria de las Retrospectivas

Dueño de Producto, usted ha sido invitado a la Retrospectiva

Aquí mismo en este Gazafatonario.

Sobre el Backlog de Producto, el Refinamiento del Producto y el Rol del Dueño de Producto

La Guía de Scrum define el Refinamiento del Backlog de Producto como:

“El refinamiento de la Lista de Producto es el acto de añadir detalle, estimaciones y orden a los elementos de la Lista de Producto. Se trata de un proceso continuo en el cual el Dueño de Producto y el Equipo de Desarrollo colaboran acerca de los detalles de los elementos de la Lista de Producto. Durante el refinamiento de la Lista de Producto, se examinan y revisan sus elementos. El Equipo Scrum decide cómo y cuándo se hace el refinamiento. Este usualmente consume no más del 10% de la capacidad del Equipo de Desarrollo. Sin embargo, los elementos de la Lista de Producto pueden actualizarse en cualquier momento por el Dueño de Producto o a criterio suyo”.

Pero ¿qué hay detrás de escena? ¿Cómo luce un buen refinamiento de producto? Hablemos un poco sobre eso.

Sobre el Producto

Primero, me gustaría decir algunas palabras sobre backlogs y cómo logramos que estos sean grandiosos:

Actualmente sabemos que

“La Lista de Producto es una lista ordenada de todo lo que podría ser necesario en el producto y es la única fuente de requisitos para cualquier cambio a realizarse en el producto. El Dueño de Producto es el responsable de la Lista de Producto, incluyendo su contenido, disponibilidad y ordenación”.

Aunque no es un concepto complicado, la noción de backlog de producto (o como se llama en español, la Lista de Producto), no siempre la entendemos completamente.

Roman Pichler y Mike Cohn dicen que un backlog de producto apropiado debería ser DEEP:

Detallado apropiadamente. Los elementos del backlog de producto difieren en su nivel de detalle. Los que se desarrollarán en los próximos sprints deben haber sido lo suficientemente entendidos hasta el punto de que puedan ser completados por el equipo en cada uno de esos sprints. De otro lado, aquellos elementos que no serán construidos durante un tiempo deberían describirse con menos detalles.

Emergente. El backlog de producto es una entidad viva que cambia constantemente y evoluciona a medida que el producto está siendo desarrollado o mantenido. A medida que el Dueño de Producto y el equipo aprenden más acerca del producto y de su entorno, por ejemplo, del mercado y de sus usuarios, adicionan nuevos elementos, eliminan otros y ajustan otros. Emergente es un atributo el cual no solo esperamos que este atributo esté presente en cada backlog, sino que es un indicativo de un backlog de producto sólido y efectivo.

Estimado. Cada elemento del backlog de producto tiene un estimado que corresponde al esfuerzo requerido para desarrollar ese elemento. El Dueño de Producto usa muchas veces este número, entre otras cualidades, para determinar la prioridad del elemento en el backlog de producto.

Priorizado. ¡Ni más faltaba! Todos los elementos el backlog de producto están priorizados (ordenados). Los elementos de mayor valor deben estar en la parte superior y los de menos valor en el fondo. El ordenamiento del backlog de producto determina el orden de entrega de sus elementos. Esta es una de las muchas formas en que un Dueño de Producto maximiza el esfuerzo del equipo y el valor entregado al negocio.

Por experiencia también sé que un buen backlog de producto es:

• Transparente. Es visible a todos aquellos involucrados en el diseño y desarrollo del producto y a todos los interesados en el producto.
• Relevante. Los nuevos cambios que se observan mientras se desarrolla el producto se reflejan en el backlog de producto, refinando sus elementos de manera adecuada.

Una vez que hemos entendido estas premisas, estamos preparados para jugar el juego del refinamiento del producto.

Sobre el Refinamiento

El refinamiento establece un entendimiento común entre el Dueño de Producto y los miembros del equipo acerca de los elementos priorizados y su funcionalidad y los desafíos técnicos. También crea más transparencia entre los miembros del equipo Scrum.

Aunque no hay una sola forma de definir el refinamiento del Backlog de Producto genéricamente en Scrum, - no hay ninguna fórmula que garantice el éxito cuando de afinar el backlog se trata – en la práctica hacemos refinamiento cuando enfrentamos:

• Un backlog de producto muy grande
• Un elemento de backlog grande
• La adición de nuevos elementos al backlog de producto

También, cuando eliminamos elementos existentes del backlog de producto lo estamos refinando.

Cualquier elemento del backlog de producto debería refinarse cuando y a medida que conocemos información adicional sobre él.

Deberíamos dar prioridad al refinamiento de elementos del backlog de producto que se van a desarrollar en el siguiente Sprint.

El refinamiento del backlog de producto es o debería ser un proceso continuo conducido por el Dueño de Producto. Este se reúne con los interesados y usuarios para recolectar cualquier información necesaria para el refinamiento. Pero también planea y lleva a cabo reuniones con el equipo para que sus miembros conozcan los elementos nuevos/modificados en el backlog. El Dueño de Producto también debería conducir estas sesiones de refinamiento del backlog de producto.

Para saber más de Refinamiento del Producto puedes leer mi artículo sobre Purga Ágil del Producto.

Sobre el Dueño de Producto

Esta es la razón por la cual, solo a través de una buena sinergia entre el equipo y el dueño de producto, que ellos pueden construir un producto útil y fantástico. Un gran desafío para el dueño de producto es gestionar el flujo de los múltiples requisitos que llegan desde los distintos interesados y lograr que haya consenso entre todos (interesados, usuarios, equipo de desarrollo) sobre los requisitos que proporcionen el mayor valor al negocio.

El resultado de una sesión de refinamiento de producto es un entendimiento común de los elementos del backlog de producto que pueden desarrollarse en el siguiente sprint. ¡Por lo menos!

Un Dueño de Producto extraordinario sabe que si un producto debe ser competitivo en el mercado, entonces este debe cumplir con todos sus atributos requeridos que se hayan definido (las características imprescindibles), pero también con sus atributos de desempeño (las características importantes o que sería bueno que tuviera) y sus atributos interesantes (esas características que tienen valor para el negocio y que sería bueno que el producto tuviera).

Por cosas como esta es que ejercer el rol de Dueño de Producto eficientemente no solamente es vital para desarrollar productos fructíferos con Scrum. También es un proceso de aprendizaje para los individuos que ejecutan el rol y para la organización.

Desde este punto de vista, el rol del Dueño de Producto significa lograr un balance entre el tira y el afloje del desarrollo del producto. No es una tarea simple de llevar a cabo. Construir el producto correcto en el momento correcto es un asunto de mayor interés para el éxito de todo Dueño de Producto. Es lo que se conoce como el “Dilema del Dueño de Producto”.

Cuando un producto exhibe una historia bien construida que es coherente, se convierte en un producto no ordinario. Cuando las partes de este producto no ordinario interactúan, generan resonancia, una mejora de la potencia que hace que un producto sea más grande y más eficaz de lo que la suma de sus partes podría predecir. Esta resonancia incita a respuestas de sus usuarios. Por lo general, son reacciones que hacen que la gente experimente un producto como algo extraordinario, útil y valioso.

Scrum, junto con otro conjunto de prácticas y técnicas ágiles, nos proporciona el marco de trabajo necesario para construir tales productos de valor con las características correctas.

¡Y para eso es que están los Dueños de Producto!

Así que, ¿qué estás haciendo tú para crear esta sinergia y construir productos sorprendentes? Déjamelo saber en la sección de comentarios abajo.

Nota:

Publiqué este artículo en Pulse el 1 de junio de 2017, originalmente en inglés:

On Product Backlog, Backlog Refinement and the Product Owner Role

Para saber más sobre el rol del Dueño de Producto puedes leer mi artículo Guía Supernumeraria para un Dueño de Producto Virtuoso.