¿Hay algún tipo de tablero para las reuniones de retrospectiva?

Plantilla de retrospectiva, gracias pmoinformatia.com

Si los hay, como por ejemplo el que ofrece la oficina de proyectos de informática (pmoinformatia.com) en forma de plantilla de Scrum, en el que se muestran las tres columnas típicas de una retrospectiva con "qué salió bien durante la iteración", "qué no salió bien" y "cuáles son las mejoras que se pueden implementar en el próximo sprint". 

Junto con la plantilla se presenta otra plantilla que sirve para documentar el resultado de la reunión, representa sólo una forma de realizar una retrospectiva, no pretende ser restrictiva, como todo en Agilidad, es susceptible de ajustarse a las singularidades de y a lo que le sea más útil al equipo.

Cada miembro escribe sus aportaciones en post-its y los coloca en la columna correspondiente, para después hablar con total transparencia sobre ello. Con el uso del tablero los equipos suelen experimentar como ventaja su automoderación y que todos mantienen la conversación centrada en los temas planteados en el mismo.

Para que las retrospectivas funcionen es importante que haya alguna acción sobre las mejoras recopiladas, que se evidencie un resultado, pero solo sobre una de ellas. Como equipo debemos limitar el WIP y elegir un objetivo, y sólo uno, para el próximo sprint. Si incorporamos más mejoras puede ocurrir que desviemos el foco del "en qué" trabajamos al "como" trabajamos y así no cumplamos con la pila de sprint. Una vez seleccionada la mejora la implementamos, la dejamos asentar para finalmente convertirla en un hábito del equipo.

Recientemente participé en una retrospectiva liderada por una chica y me encantó su forma de apelar a la inteligencia emocional en el tablero. Pegó cuatro post-its en la pared, los de la imagen abajo a la derecha, y las aportaciones del equipo las fueron pegando alrededor de estos. Incorporó una cuarta columna para mi inusual, una de agradecimientos, y resultó que lo escrito en los post-its de esta columna hizo que el equipo se sintiera bien, con un muy buen estado de ánimo y buena disposición para el resto del día.

Post-its de encabezamiento
para un tablero más dirigido
a personas, gracias Esther :-)

La bombilla evoca a ideas, las mejoras, como ejemplos:

• Agilizar la sprint planning
• Tareas o minitareas más definidas
• Investigar la aplicación de BDD
• Lectura de las fuentes del proyecto para proponer mejoras

El ramo de flores evoca los agradecimientos, como ejemplos:

• Gracias a todos por hacer una entrega tan completa
• Raúl por su paciencia porque el pobre no le hacemos caso
• Gracias Miguel por haberme ayudado a esclarecer el conflicto que apareció en el código durante el batch
• En especial a Dani y a Juan por el esfuerzo

La carita sonriente lo que nos pone contentos, lo que salió bien, como ejemplos:

• Buena comunicación con cliente y dentro del equipo
• Nuestro apoyo mutuo en las dudas
• Ser un equipo que adoptado bien Scrum
• Por fin un entorno de pruebas automatizadas

La carita triste lo que nos pone tristes, lo que no salió bien, como ejemplos:

• No hemos llegado al 100% del sprint
• Falta de puntualidad en las daily, eso nos hace perder tiempo y las hace más largas de lo necesario
• Tener que hacer informes para la PMO que solo entorpecen mi trabajo
• No revisamos lo suficiente, se nos cuelan bugs por no probar desde la perspectiva del usuario

Las mejoras, una camino hacia el sol :-D

Finalmente el equipo vota con palitos, en nuestro caso 3 a distribuir a discreción, entre las ideas y aquello que no ha salido bien.

El post-it o los post-its con más interés o preocupación por parte del equipo, los llevamos a un área específica para tratar de buscar mejoras. El post-it que encabeza este área se identifica con una flecha que apunta al sol :-D.

Alli tratamos posibles soluciones para los top de aquello que queremos tratar, podemos aplicar técnicas como el diagrama Fishbone (Ishikawa) o los 5 Why's para encontrar causas raíz y sus soluciones, para finalmente elegir una sola mejora a aplicar para el siguiente sprint.

Retrospectiva en marcha, gracias Alberto, Francisco, Jorge, Raquel, Sandra y Miguel

¿Qué son los ScrumButs o ScrumPeros?

Hay empresas que para tomar su camino hacia la Agilidad adoptan Scrum, y otras, adaptan Scrum. Adaptar Scrum para pasar de scrum técnico, basado en reglas, a scrum avanzado y así aplicar directamente principios de gestión ágil con el conocimiento y experiencia de los equipos, y con una cultura ya ágil en la organización, trata de la madurez en Agilidad. Pero adaptar Scrum de entrada sin una cultura ágil es cosa muy distinta... mi compañero Aníbal suele decir "cómo una empresa que está lidiando a duras penas con su producto en el mercado puede pretender diseñar una metodología"... en mejor de los casos se trata de organizaciones que hacen cambios a corto plazo para dar tiempo a corregir sus deficiencias.

¿Adoptar o no ScrumButs?

ScrumButs/Peros son malas prácticas por las que los equipos no pueden sacar el máximo provecho de Scrum para resolver sus problemas y hacer realidad los beneficios del desarrollo de productos con este marco. Cada rol de Scrum, artefacto, regla, y timebox se ha diseñado para proporcionar los beneficios descritos, y abordar problemas recurrentes predecibles. Normalmente los ScrumButs implican que Scrum ha puesto de manifiesto una deficiencia que está contribuyendo al problema, pero es demasiado difícil de solucionar. Un ScrumBut conserva el problema al modificar Scrum para que la deficiencia no sea visible y no se considere como problema del equipo.

Por ejemplo, la definición de hecho (DoD) podría no incluir inicialmente regresión y pruebas de rendimiento, ya que tomaría varios meses desarrollar las pruebas automatizadas. En este caso durante los meses sin pruebas automatizadas el desarrollo estará penalizado por una deuda técnica, y esta se debe de restaurarse tan rápidamente como sea posible.

Un ScrumBut tiene la siguiente sintaxis:

(ScrumBut) (Razón) (Workaround)

Un ejemplo ScrumBut:

• Estamos haciendo Scrum, pero las retrospectivas no son eficaces, por lo que sólo las hacemos cada tres meses.

Las retrospectivas a menudo son ineficaces porque no se hace nada acerca de las cuestiones planteadas, es más probable que el equipo necesite mejores retrospectivas en vez de menos.

Otros ejemplos:

• Estamos haciendo Scrum, pero nuestros clientes e interesados están demasiado ocupados para asistir a las revisiones de sprint, por lo que dejamos de hacerlas.
• Estamos haciendo Scrum, pero no conseguimos acabar los incrementos en dos semanas, por eso ahora dejamos que nuestros sprints sean abiertos sin duración fija.
• Estamos haciendo Scrum, pero a veces nuestros gerentes nos dan tareas "especiales", por lo que no siempre tenemos tiempo para cumplir con la definición de hecho (DoD) .

¡Esto NO es Scrum!

Hay una página en la que se puede hacer un test de ScrumButs, lo interesante es que muestra la distribución en tarta de los diferentes ScrumButs aplicados con mas frecuencia.

En general los expertos en Scrum nos oponemos a los ScrumButs porque casi siempre esconden un impedimento o deficiencia que, de ser abordado y eliminado, mejoraría muchísimo las cosas. Mi consejo es preguntar en primer lugar por el porqué, a veces hay que escalar la pregunta hasta llegar a la causa raíz, y es usual llegar a respuestas como "como siempre se ha hecho así..." resultando que si se puede cambiar y por tanto hemos adoptado un ScrumBut sin necesidad. En segundo lugar mi consejo es "adoptar antes de inspeccionar y adaptar".

¿La retrospectiva no se puede incluir en la reunión de revisión de sprint?

En uno de los equipos que acompaño actualmente hacemos las dos reuniones seguidas en la misma sala, una detrás de la otra. Junto con el hecho de que al evento lo llaman "cierre de sprint", se produce cierta confusión: aunque la reunión consta para todos de dos partes, no deja de percibirse la idea de ser una única reunión.

Pero sí, puede hacerse en una sola reunión, debe de dividirse en dos partes y que todos sean conscientes de que en la primera parte, en la revisión de sprint, se analiza el "qué" se ha construido, mientras que la segunda, la retrospectiva, se centra en el "cómo" se ha construido, en el "cómo" se ha trabajado. Es positivo hacerla a continuación de la revisión de sprint porque así permite incorporar en la retrospectiva el feedback y el cumplimiento de expectativas obtenidos en la primera. Esta segunda parte, la retrospectiva, es parte central del proceso de mejora continua del marco de trabajo. 

Equipo preparando sus aportaciones para la retrospectiva

Realizar una buena retrospectiva hace participar a todo el equipo en la mejora de proceso, de forma que cada miembro se siente escuchado y que las decisiones se toman de forma consensuada. Esto redunda en un incremento de la productividad, la calidad del producto y el aprendizaje del equipo de forma sistemática, sprint a sprint. Realmente es en esta reunión dónde se marca el rumbo y se solucionan los problemas de fondo, por tanto es esencial que los equipos comprendan las naturalezas distintas de ambas reuniones.

¿Cómo ayudar a los equipos para que persistan en el cambio hacia la Agilidad?

El martes que viene me haré cargo de tres equipos que se inician en Scrum. Primero habré de formarles, darles un buen impulso, abrirles la mente y romper su resistencia al cambio. Les hablaré de lo que viene, cambio, Scrum, equipo autoorganizado... sentirán curiosidad, un 5% de su ser sentirá "¡esto mola!", el resto del 95% se revolverá y pensaran "¡esto en mi realidad es imposible!"...

Trabajaré ese 5%, se animarán y se entusiasmaran. Entonces ya estarán preparados para hablarles de un gráfico simplificado de Ray Immelman que mostraré al equipo para anticiparles como van a sentirse hasta que se consoliden con Scrum.

Proyectando la curva del entusiasmo comprenderán cómo evolucionará esta emoción y estarán más preparados para los momentos bajos. Entre el inicio y el momento de la conclusión del éxito habrá altibajos con los que lidiar. En los momentos bajos, los que tengan una mentalidad fija fallarán, y los que tengan una mentalidad de crecimiento prevalecerán.

Curva del entusiasmo

• 1- Bien, tiene buena pinta, démosle una oportunidad
• 2- Es más difícil de lo que parece
• 3- ¡Parece que funciona!
• 4- Estamos llegando al punto de no retorno, ¿de verdad queremos esto para siempre?
• 5- ¡Estamos teniendo verdaderamente éxito con esto!

Scrum es un proceso simple y como en muchos otros ámbitos que tratan de y sobre personas redunda en un comportamiento complejo. Al principio, como en todo proyecto que implica creatividad, habrá mucho entusiasmo y esperanza. En medio del proyecto tanto clientes como equipo sentirán que el éxito esta distante y es incierto. Enseñando este gráfico, tanto a Propietarios del Producto como al equipo, comprenderán que es una parte normal del proceso de aprendizaje, hay que fallar antes del éxito y que el fracaso simplemente es el esfuerzo mal dirigido (quien no hace nada nunca fracasa...). Por tanto fallar es parte del proceso y una de las ventajas de Scrum es que propicia el fallo temprano. Realmente el término correcto es aprender y mejorar, no fallar, y por tanto Scrum propicia el aprendizaje temprano y la mejora continua.

Siempre que se produzca un momento bajo es cuando hay que poner este gráfico sobre la mesa y recordar al equipo que realmente lo que está pasando es que estamos aprendiendo, mejorando y creciendo.

¿Cómo utilizar el cono de incertidumbre para evangelizar?

Una de las situaciones más complicadas que puede encontrarse un Scrum Master, o un coach ágil, es tener que explicar a un directivo o mando intermedio, que sólo ve que está contratando un proyecto del que entiende un alcance cerrado, porqué con Scrum, sin cerrar el alcance, resultaría en algo que le aportaría más beneficio. Una herramienta para hacerlo es utilizando el cono de incertidumbre.

Aplicado a la gestión de proyectos, el cono de incertidumbre describe la evolución de la medida de incertidumbre durante la realización de un proyecto. Cuando se inicia un proyecto, es poco lo que se sabe sobre el producto, el entorno, el cliente, etc. Resaltar que en un proyecto con metodología predictiva (tradicional) los requerimientos se recogen justo en ese punto, en el de mayor incertidumbre y por tanto el de mayor ignorancia. En ese punto la incertidumbre se sitúa entre un X4 y un /4 de la estimación hecha, y se va reduciendo conforme pasa el tiempo. A medida que se haga investigación, avance el desarrollo del producto, mayor será el conocimiento aprendido y la incertidumbre disminuirá proporcionalmente, llegando incluso a 0%, lo que ocurre usualmente al final del proyecto.

Cono de incertidumbre

Podemos dibujar un cono de incertidumbre, como el de la imagen, e ilustrar como sería un proyecto con metodología predictiva (tradicional). Situamos el resultado de la toma de requerimientos del analista de negocios en el punto 1 y trazamos una línea recta hasta la diana, esta representa el desarrollo del producto en base a los requerimientos del punto 1. El punto de impacto, el punto 2, muestra el producto obtenido, que está dentro de la diana, pero no en el centro. Obtendríamos un producto de relativa calidad en el que habría transacciones que no cubrirían del todo las necesidades, serian operativas pero mal resueltas, y lo que es más alarmante, una serie de transacciones fuera del cono, localizadas en el área 3, que no servirían para nada y serían puro desperdicio. En un post sobre el desperdicio que puede ahorrarse bajo Scrum se puede ver los resultados de un caso real en el que participé.

Para ilustrar como sería el proyecto bajo metodología evolutiva (métodos ágiles) podemos dibujar los sprints, las cajitas verdes con el 4, y mostrar que al finalizar cada uno de ellos por el hecho de inspeccionar y adaptar, vamos corrigiendo el avance del proyecto para llevarlo exactamente al centro de la diana. Gracias al feedback en la revisión de sprint de clientes e interesados aprendemos, a medida que avanzamos, lo que estos realmente necesitan. Con metodología predictiva (tradicional) llegamos al punto 2, que representa lo que el cliente pensaba que quería, y mediante metodología evolutiva (métodos ágiles) llegamos al punto 4, que representa lo que éste realmente necesita.

Esto también puede verbalizarse con la siguiente pregunta: ¿que es preferible, obtener un producto que cumpla con el alcance descrito al principio del proyecto, con desperdicio y calidad relativa, o un producto cuyo detalle no se conozca hasta el final pero que garantice que cubre las necesidades realmente prioritarias, lo que dé valor al cliente? Una buena definición de valor para el cliente es aquello para lo que está dispuesto a pagar, aquello que dé solución a sus problemas.

Conos de incertidumbre de los sprints,
thanks to Silvana

Añadir que con la participación del cliente este vive al finalizar cada sprint la evolución del proyecto, y tiene sensación de que se le escucha y de que realmente se le está construyendo una herramienta que cubrirá sus necesidades.

Para visualizar como Scrum minimiza los riesgos derivados de la incertidumbre podemos dibujar el cono de incertidumbre de la derecha. En este se ve que la incertidumbre "viva" sólo es la del sprint en curso. Acabado el sprint esta será 0, y volvemos a tener otro cono, muy pequeño comparado con el de un desarrollo tradicional, cuyos riesgos e incertidumbres resolveremos dentro del mismo sprint. Resaltar que a medida que vamos construyendo el producto este actúa como elemento que despeja incertidumbres y hace que los conos de incertidumbre de los sprint posteriores sean menores a medida que avancemos en el proyecto.

Este post lo dedico al Zorro Gris, alguien que aprecio mucho y espero incorporar en algún momento en uno de los equipos ágiles que lidere :-)

¿Cómo dividir epics e historias de usuario grandes?

En este post quiero exponer las 10 estrategias que Christiaan Verwijs describe en su artículo "10 useful strategies for breaking down large User Stories (and a cheatsheet)" en forma de resumen del artículo original, más una estrategia para despejar incertidumbre conocida como "break out a spike" (extraer un spike).

La experiencia muestra que cuando dividimos un epic o una historia de usuario relativamente grande en varias historias de usuario más pequeñas estamos agregado detalle, a la vez que las historias de usuario más pequeñas mejoran el flujo dentro del sprint y reducen el riesgo de fallar el mismo. Las historias de usuario grandes implican una mayor incertidumbre funcional y una mayor dificultad para ser estimadas. Dividir historias redunda en mejorar el entendimiento de las mismas, incrementar la exactitud de las estimaciones y hacer que estas sean más fáciles de priorizar.

Podemos dividir las historias de usuario de forma horizontal y vertical. Horizontal significa división según el tipo de trabajo, por tecnologías por ejemplo, típico de las metodologías tradicionales. Esta forma de dividir en horizontal genera historias que no tienen valor de negocio de forma individual, solo más bien algo como tareas o "historias técnicas" de las que solo el conjunto de todas ellas tiene valor. La división horizontal propicia el "pensar a modo de silos" en que cada miembro del equipo se focaliza solo en las de su especialidad, situación que tiende a producir cuellos de botella. La Agilidad evita este tipo de problemas con la multifuncionalidad del equipo de personas de perfil "T", todo miembro participa en mayor o menor media en los diferentes tipos de tarea. Por último las historias provenientes de divisiones horizontales no se pueden priorizar ya que no aportan ningún valor de negocio de forma individual.

Hoja de trucos de Christiaan Verwijs

A diferencia de la división horizontal, la vertical es más útil, una historia dividida en vertical genera historias que a su vez tienen valor de negocio, la funcionalidad no está dividida a lo largo de capas técnicas sino de capas funcionales. A semejanza de los incrementos resultantes de un sprint, las historias resultantes son como una porción de una tarta que incluye todas las capas técnicas necesarias.

Hay múltiples estrategias para dividir historias de usuario de forma vertical; una en caso de que la implementación de la historia sea compleja y difícil de entender y requiera una actividad exploratoria o spike previa, y las 10 que menciona Christiaan en su artículo, y que se pueden ver en la figura que muestra su hoja de trucos a la derecha, que dividen las historias de usuario en lonchas más finas completamente funcionales. Estas estrategias están pensadas para la reunión de planificación del sprint y para el refinamiento de la pila de producto y no requieren fases de análisis exhaustivas ni son costosas en tiempo.

• Estrategia 0 - Construir un spike: para adquirir el conocimiento previo necesario para entender mejor la solución y/o la necesidad asociada y así reducir la incertidumbre respecto a la implementación de la historia de usuario.
• Estrategia 1 - División por pasos de flujo de trabajo: para historias de usuario que incluyen algún tipo de flujo de trabajo, estas se pueden dividir según los pasos individuales del flujo.
• Estrategia 2 - División por reglas de negocio: historias de usuario que conllevan implícita o explícitamente reglas de negocio se pueden dividir por estas reglas. Frecuentemente los casos de test implican importantes reglas de negocio, por tanto para esta división podemos basarnos en las pruebas.
• Estrategia 3 - División por happy/unhappy flow: las funcionalidades usualmente describen un flujo en que todo va bien y otros flujos en que se tratan desviaciones, excepciones o problemas, por tanto estos flujos también son una forma de dividir historias grandes.
• Estrategia 4 - División por opciones/plataformas de entrada: en caso de productos que han de rodar en diferentes plataformas, como portátiles, tablets, móviles... pueden dividirse las historias de usuario por su plataforma de entrada.
• Estrategia 5 - División por tipos de datos o parámetros: algunas historias de usuario se pueden dividir por sus parámetros de entrada o salida, como por ejemplo las diferentes opciones de una búsqueda.
• Estrategia 6 - División por operaciones: Hay historias que involucran las típicas operaciones de alta, lectura, modificación y baja (CRUD - create, read, update & delete), operaciones que pueden ser otra forma de división.
• Estrategia 7 - División por casos/escenarios de test: a veces hay historias que son difíciles de dividir funcionalmente, en este caso puede ayudar a preguntarse cuáles van a ser los escenarios de test de la historia y dividir por estos. Los escenarios pueden ser combinación de reglas de negocio, flujos que van bien y con excepciones, plataformas de entrada, etc.
• Estrategia 8 - División por roles: para historias de usuario que cubren diferentes roles, estas se pueden dividir por las funcionalidades propias de cada rol.
• Estrategia 9 - División por optimizar ahora o más tarde: las historias de usuario pueden ser implementadas en diferentes grados de perfección y optimización de la funcionalidad descrita.
• Estrategia 10 - División por compatibilidad de navegador: las historias de usuario para aplicaciones web a menudo tienen que trabajar en una amplia variedad de navegadores, los más modernos tienden a ser más compatibles con los estándares y los más antiguos suelen necesitar de personalizaciones para que todo funcione correctamente.

Esquema con las 10 estrategias, para verlas al detalle máximo clickar encima de imagen - cortesía de Gertrudis :-)

En todas estas estrategias la división reduce la incertidumbre, nos permite desarrollar las historias resultantes importantes y dejar historias menos importantes para sprints futuros.

Os quiero invitar a leer el post Mapa mental en castellano del post de Christiaan Verwijs "10 useful strategies for breaking down large User Stories (and a cheatsheet)" de mi compañera Gertrudis, describe y da acceso al mapa mental sobre división de historias de usuario, mapa que es una excelente guía con ejemplos para la estrategia de división a aplicar.