¿Existe algún juego de simulación de Scrum que no sea relacionado con las TI?

Este es un ejercicio del curso de Scrum de

Hace poco me tocó dar un curso de Scrum a un grupo de alumnos de los que la mitad no provenían de las TI, había entre ellos algún psicólogo, un biólogo, gente de marketing... en fin, tuve que buscar y dar ejemplos provenientes de otros campos. Tuve pensar en qué tipo de simulación de Scrum realizar para hacerles vivir una construcción de algo no relacionado con informática a través de sprints y las ceremonias de Scrum.

Materiales para la simulación

Uno de los juegos más comunes es la construcción con Lego, yo mismo participé en la construcción de un pájaro de lego en mi certificación en 2011. Para el curso tenía que ser algo que se pudiera construir con materiales que tenía a disposición y fáciles de transportar: post-its, papel de rotafolios, hojas DIN-A4, rotuladores, tijeras, pegamento de barra... y recordé la simulación de Scrum para construir un resort vacacional de Carlos Peix.

Este juego dura dos horas y es para equipos a los que se explica por primera vez Scrum. Permite que hagan una simulación de creación de la pila de objetivos priorizada por releases (pila de producto) y de ejecución del propio proceso de Scrum, para que puedan comprobar los principales beneficios de Scrum, especialmente los referidos a alineamiento con las expectativas del cliente a base de inspección y adaptación.

La simulación empieza por una actividad de 15 minutos de duración, un User Story Mapping para obtener la pila de producto y luego priorizada a través de una Release Planning. Según vemos en la imagen que sigue y en la hoja de rotafolio izquierda:

• El equipo identifica su hoja de ruta, aquellos servicios genéricos que van a dar en su resort, por ejemplo restauración (representado dónde el número 1).
• Luego identifica por cada servicio las historias de usuario asociadas, en este caso lo que compondrá el resort y aquellos servicios concretos que dará, por ejemplo restaurante chino, restaurante gourmet, etc.
• En función del valor de cada historia el equipo agrupa estas por releases, las aperturas de nuevos servicios a los turistas (en la imagen de R1 a R4, la primera representada con el número 2).

Planificación de Release y scrumboard de la simulación

A partir de la planificación de release la simulación entra en la fase de construcción mediante el marco de Scrum. La simulación consta de 3 sprints reflejados en el scrumboard sobre la hoja de rotafolios de la derecha (el sprint 1 está representado con el número 3).

Primero se asignan los roles, el Propietario del Producto será el trainer y por parte de los participantes se designa el Scrum Master y el resto serán el equipo de construcción. El Scrum Master se encargará de controlar los tiempos y de velar que las reglas Scrum se apliquen correctamente.

Los pasos para cada uno de los 3 sprints son:

• Durante 5 minutos se realiza la planificación de sprint, el equipo estima las historias que pueden realizar en un sprint de 15 minutos y las trasladan a la columna de "pendiente" del scrumboard.
• Las historias del sprint se construirán durante 15 minutos, el equipo construye una por una pasándolas a "en curso" y luego a "terminado".
• Finalizado el sprint se realizará durante 5 minutos la revisión de sprint, en la que se llamará al Propietario del Producto para presentarle el incremento construido. La definición de hecho será el total de historias de usuario del sprint, se comprobará la cantidad de historias hechas y si hay historias sin terminar el equipo deberá de tenerlo en cuenta y calibrarse para el próximo sprint. El Propietario del Producto dará feedback e introducirá variabilidad en el proyecto (muestro un par de ejemplos más abajo).
• Finalmente el equipo dedicará 5 minutos para realizar una retrospectiva con objetivo de mejorar su autoorganización y los procesos de construcción.

Pila de producto de servicios del resort

Aquí muestro algunos ejemplos de feedback de Propietarios del Producto que yo utilizo:

• Zarandeo la mesa diciendo que es una zona con terremotos frecuentes y el resort tiene que estar preparado para resistir a estos. Probablemente se producirán destrozos y explico que estos son por falta de calidad y por tanto hay que mejorarla, así como crear un sistema antiterremotos y anclar edificios y/o terreno.
• Explico que observado el tipo de turistas que hasta la fecha han venido al resort, hemos visto que son adinerados y generalmente vienen con su propio yate, por tanto hay que construir un muelle para que puedan atracar en el resort.
• Un estudio de mercado ha revelado que lo que buscan los turistas es que los bungalows más lujosos incluyan una piscina particular, es de importancia máxima construir estas piscinas.
• Las compañías de cruceros han mostrado gran interés por hacer escalas de una noche, es prioritario construir un barco transbordador, su muelle y un hotel de alta capacidad para estos turistas de crucero.

A medio juego pongo a prueba si los participantes han comprendido las reglas de Scrum, me presento a medio sprint como un jefe o directivo clásico y les digo que es absolutamente prioritario construir un chiringuito o un gimnasio intentando cambiar y romper el sprint. Lo que debería de ocurrir es que el equipo lograse se diplomático, no se comprometiese y me derivara hacia el Scrum Master. Este debe de exponer argumentos de porqué no romper el sprint desde la perspectiva de Scrum, y finalmente llamar al Propietario del Producto para dar argumentos desde la perspectiva de negocio. Sólo el equipo puede cambiar un sprint, solo este y de la mano de Propietario del Producto podría proponer alguna solución, como por ejemplo un intercambio de historias. Si el equipo decide que no pueden incluirlo en este sprint hay que respetarlo, si les obligáramos a hacerlo romperíamos el sentimiento de compromiso auténtico de estos, dejaría de ser un equipo comprometido y motivado.

Aquí os muestro como quedó un resort resultante de un de los cursos de Scrum :-)

Finalmente se dedican 10 minutos a reflexionar sobre la simulación:

• Sobre el alcance variable de Scrum, sobre como el equipo ha trabajado orientado a completar objetivos prioritarios y si ha sido flexible con los cambios.
• Como las revisiones regulares del incremento han permitido conocer la velocidad del equipo y como se han alineado con las expectativas de todos.
• Como en el primer sprint han sentido el estrés al traer todos los riesgos al principio del proyecto, y de cómo este estrés ha ido menguado con cada sprint.
• Sobre como las acciones de mejora de las retrospectivas han afectado a los sprints posteriores.

Curso Scrum Manager de Estratecno de abril 2017: 3 equipos en plena simulación :-) Gracias a todos los participantes

Los resorts obtenidos en esta simulación suelen ser muy atractivos y coloridos, me llamó la atención el comentario de uno de los alumnos que exclamó ante el resort obtenido "¡Me esperaba algo más sencillo, no hubiera pensado que construiríamos algo tan bonito!". Justamente este el resultado de convivir con la incertidumbre consustancial y construir con Scrum: al principio no sabemos el producto que vamos a obtener, pero el marco garantiza que va a ser el mejor producto posible dentro del presupuesto y tiempo asignados.

Algunos resorts hechos con la simulación tienen auténticas joyas :-) Gracias a todos los alumnos que han participado con sus ideas y creatividad, que es impresionante, y una y otra vez no deja de sorprenderme

¿Hay alguna técnica de retrospectiva que permita detectar rápidamente el estado de un equipo?

No siempre logramos detectar los problemas de fondo que puedan darse en los equipos, esto ocurre sobre todo en técnicas de retrospectivas más complejas que se basan en una buena integración y confianza del equipo. Cuando hay roces entre miembros o roces con otros roles no es fácil detectar esos problemas.

Podemos utilizar la técnica del histograma de satisfacción, que es muy simple y se aplica de forma anónima. Su objetivo es mostrar en un histograma la curva de satisfacción de los miembros del equipo.

Los pasos son los siguientes:

• El facilitador o Scrum Master reparte post-its y rotuladores y pide a cada participante que anote su grado de satisfacción en relación al trabajo y/o con el equipo, según la siguiente escala:
• 2: Absolutamente satisfecho, este es la clase de equipo y de empresa de los que siempre he querido formar parte
• 1: Estoy satisfecho, a gusto con el equipo y el trabajo
• 0: Es lo que hay, hay días mejores y días peores
• -1: No estoy nada satisfecho, hay mucho que mejorar
• -2: Estoy quemado, quiero irme y de hecho estoy buscando trabajo
• Cada miembro entrega al facilitador su post-it doblado para ocultar el número escrito
• En base a todos los valores de los post-its el facilitador anota los resultados en un gráfico a modo de histograma en un tablero o un rotafolio (como los histograma al pie de la siguiente imagen):

Histograma de satisfacción: post-its con valores e histograma de dos equipos en estados opuestos

Con un vistazo al histograma sabremos si hay problemas, si los valores se distribuyen entre el 1 y el 2 estamos ante un equipo satisfecho y motivado, si se distribuyen entre -1 y 1 hay problemas que tratar y si se distribuyen entre -2 y -1 tenemos serios problemas.

A partir de ahí podemos utilizar el histograma para realizar preguntas al equipo y profundizar, las personas, cuando las cosas van mal y vemos que los demás piensan igual, nos desbloqueamos y nos es más fácil sacar las preocupaciones que tenemos dentro.

Un consejo: como facilitadores hemos de entrar a toda retrospectiva sin deseo y sin memoria.

¿Las historias de usuario son requisitos o requerimientos ágiles?

La historia de usuario, un requisito ágil

En el último curso de Historias de Usuario, Ingeniería de requisitos ágil, se abrió este debate interesantísimo en el foro que generó conocimiento, escribimos ciencia como me gusta decir, y que quiero exponer en este post.

Según la RAE, requisito es una circunstancia o condición necesaria para algo, mientras que requerimiento está más orientado a requerir o necesitar (a la falta de algo).

La diferenciación que hace generalmente la ingeniería de software es que un requisito es una condición exigida o necesaria, mientras que un requerimiento, que proviene de requerir, es la acción de solicitar algo.

Requerimiento es una necesidad planteada por un usuario (que puede o no ser solventada por medio de software), mientras que el requisito forma parte de aquellas condiciones que debe cumplir el producto para satisfacer los requerimientos (o necesidades). El requisito representa funcionalidades, características y restricciones que afectan al producto, determinan lo que este debe de cumplir y siempre hacen referencia a características observables.

Veamos un ejemplo de ambos:

• "El software tendrá que ser fácil de usar", esto sería un requerimiento, ya que no es algo observable y no supone una restricción
• "El listado de clientes se mostrará por defecto en orden alfabético", esto sería un requisito ya que establece una restricción observable

Por tanto la historia de usuario "Como administrativo quiero que el listado de clientes se muestre por defecto en orden alfabético para poder encontrar fácilmente a un cliente" está más relacionada con un requisito que con un requerimiento.

Si vamos un poco más allá podríamos ver a los dos términos como hablar de lo mismo con distintas perspectivas y profundidad. Los requerimientos se pueden ver como las necesidades funcionales que demanda el usuario a un nivel más o menos medio, y a los requisitos como la manera de detallarlos en los aspectos necesarios para poder implementar esas necesidades.

Si miramos una pila de producto nos encontramos en la parte superior, la más cercana, con historias de usuario detalladas con sus criterios de aceptación, que son claramente requisitos con sus características observables. Pero, si miramos la parte inferior, la más lejana, nos encontramos con epics y temas, elementos que podrían ser requerimientos que representen necesidades funcionales que están a nivel de demanda. Si esto lo aceptamos así, nos llevaría a la conclusión coherente de que uno o varios requisitos podrían llegar a satisfacer o cumplir un requerimiento.

Quiero dar mis agradecimientos a los participantes del debate William, Alejandro y Luís qué hicieron que este post fuera posible.

¿Cuál es la muda o desperdicio más importante que minimizan los sprints?

En la naturaleza del ser humano no está la multitarea

¡La multitarea es el peor enemigo de la productividad! Mata cosas como concentración, claridad, intensidad, creatividad, detalle, calidad, consciencia, sencillez, lucidez, relajación, agudeza, disfrute, agilidad…

La multitarea realmente no tiene que ver con hacer varias cosas a la vez, sino con la capacidad de cambiar de contexto de una actividad a otra. Las personas no somos multitarea, cuando estamos concentrados, como cuando escribimos código de programación, mantenemos una espacio mental con una estructura compleja con las razones del por qué hemos tomado cada decisión, como cada sentencia, cada variable, cada clase, cada condición, cada bucle y cada bloque de código. Si cambiamos de contexto perdemos ese espacio mental, y cuando volvemos a la actividad nos cuesta muchísimo recrear ese espacio, y ese es el desperdicio más importante en el desarrollo de software.

En el siguiente gráfico que encontramos en el libro "Quality Software Management - Vol.1 Systems Thinking" de Gerald M.Weinberg se muestra cuanto penaliza cambiar de contexto al trabajar de 1 a 5 proyectos simultáneamente.

Desperdicio (% en rojo) en función del número de proyectos simultaneados - Fuente Gerald M.Weinberg

La combinación de la naturaleza cerrada de los sprints, nadie excepto el equipo puede cambiar la pila de sprint, y, la autoorganización en que cada miembro se asigna y se focaliza en la medida de lo posible en una sola tarea, minimiza drásticamente este desperdicio. Cuando hacemos una sola tarea nos centrarnos en ella, se desata nuestra capacidad, se dispara nuestra agilidad mental y se estimula nuestro proceso creativo, en otras palabras: hacemos las cosas mejor, pensamos mejor, creamos más fácilmente y por ende encontramos las mejores soluciones.

¿Cuánta importancia hay en la finalización y cierre exitoso de los sprints?

Burn-down de un sprint exitoso

Cuando acompañas a equipos de desarrollo como coach ágil no tienes relación directa con los proyectos, por tanto no te afectan los problemas del mismo, pero si te llevas las emociones de las personas con las que al fin y al cabo tratas día a día. Este post nace de mis experiencias con un equipo que trabaja con Scrum pero que tiene que ajustarse a unos hitos pensados a modo de cascada al principio del proyecto, ideados en el momento de mayor ignorancia y por tanto cada vez más lejanos a la realidad. El resultado es que una y otra vez incluyen historias de usuario en la pila de sprint por encima de su capacidad, lo que resulta en que una y otra vez entregan incrementos incompletos.

Recordemos lo que es la reunión de revisión de sprint: se trata de una reunión informal realizada al final de cada sprint para comprobar el incremento que debería de estar finalizado (terminado, probado, operando en el entorno del cliente, hecha la documentación de usuario, documentación técnica, etc.,). Debe de asistir todo el equipo de desarrollo, el Propietario del Producto, el Scrum Master y todos los interesados receptores del producto. Los demás interesados que lo deseen también están invitados.

El Propietario del Producto repasada las definición de hecho (DOD) e identifica las funcionalidades que se pueden considerar “hechas” y las que no. Al mostrar el incremento a los interesados objetivo, el Propietario del Producto y el equipo obtienen feedback relevante para revisar la pila del producto, así como información para mejorar la visión del producto.

Scrum realmente es una gestión de entregas con la que obtenemos con cada sprint un incremento potencialmente instalable en producción, un incremento finalizado que fue guiado por los criterios de aceptación y que debe de cumplir con la definición de hecho, y eso cada pocas semanas. Eso implica que el estrés de las entregas se trae a principios de proyecto. De repente equipos que no han rodado en Scrum se encuentran con que, en vez de una fecha de entrega a largo plazo o fechas de hitos a medio plazo, tienen una fecha de entrega cada pocas semanas ¡y esa fecha es inamovible! En los proyectos con metodología tradicional todo el equipo sabe que, aunque haya fechas aparentemente inamovibles, cuando esta se acerca y no es posible realizar una entrega en condiciones, esta fecha se retrasará, o sino se entrará en una segunda fase o se hará lo necesario para tratar la desviación. Pero en Scrum no es así, el sprint tiene una cadencia de duración fija.

Veamos el síndrome del estudiante, este es un fenómeno que forma parte de la naturaleza humana por el cual las personas nos espabilamos y comenzamos a dedicarnos seriamente a una tarea cuando la fecha de entrega se acerca, y eso lo sentimos en forma de estrés. Incorporar la naturaleza humana, y no ir en contra, es una de las fortalezas de Scrum. Con los sprints con fecha de entrega cada pocas semanas se focaliza a las personas en las tareas a realizar, en entregas muy cortas que son factibles sin esfuerzos, generando así el beneficio de un tono de ritmo de trabajo sostenido.

Sonrisa para el final de semana a final
de sprint - Cortesía de Pixabay

Los problemas de motivación y compromiso aparecen cuando no se resuelve ese estrés con cada revisión de sprint, y si de forma repetida el equipo no finaliza los sprints este se suma de un sprint a otro. Scrum al poner de manifiesto todos los problemas desde el primer momento, cosas que no suelen ser otra otra cosa que problemas sistémicos, acabará por escalar el estrés a todos los niveles en forma de bola de nieve.

Mi consejo a los equipos de desarrollo en esta clara situación de ScrumBut es que no piensen en las fechas del proyecto, que se focalicen en realizar y entregar sprints bien hechos. Si de forma continuada entregan incrementos bien hechos habrán ganado la confianza del cliente y la percepción será la de un equipo que funciona, y cuando llegue el momento de alguna fecha incumplida la actitud será muy distinta.

Para los que seáis Scrum Masters animaros a que deis máxima prioridad a que los equipos finalicen los sprints, que haya criterios de aceptación escritos en la planificación de sprint y que se revisen en la revisión de sprint, y en caso de haberse cumplido por encima de un 90% haya reconocimiento explícito por parte del Propietario del Producto, por ejemplo "¡Chicos, buen trabajo!". El viernes de la revisión de sprint el equipo ha de irse de fin de semana contento, con sensación de trabajo bien hecho, y el cliente también, con sensación de avance y sintiendo que dirige el rumbo de su producto.