¿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.

¿Sprint -1?

La mayor parte de mi trabajo consiste en ejercer de coach ágil y acompañar a empresas en su camino hacia la Agilidad. Las empresas que acompaño hasta el momento son de ámbito español, y todas ellas tienen en común que la mayoría de personas y equipos de TI son subcontratados para un proyecto concreto a empresas especializadas que conocemos como consultoras de TI. No siempre la empresa cliente hace una fase previa de incepción ágil para poner contexto al proyecto y personas y obtener una pila de producto inicial. 

Recientemente se incorporó un nuevo equipo al que acompaño en su trayectoria en Scrum, es un equipo con experiencia en Agilidad y que me ha sorprendido con un tablero para la "Iteración previa (-1)" o "Sprint -1" con el que intenta suplir la carencia de una fase de incepción prévia.

El objetivo de este sprint es aterrizar en casa del cliente, conocer el entorno físico en que estará el equipo y en especial conocer la visión del producto e identificar y abrir canales de comunicación con los interesados.

Tablero Sprint -1 o iteración previa
gracias Alberto :-)

En el tablero se pueden identificar 5 zonas:

1. En base al documento de requisitos (DDR o DRU), sin haber tenido aún conversación con el usuario de negocio, y como resultado de un User Story Mapping previo se identifican temas o características (papeles blancos) y se hace un ejercicio de desglose en epics (post-its verdes) y de planificación de release (post-its amarillos). Esto sin duda prepara al equipo para hablar el mismo idioma que la gente de negocio.
2. Pila de riesgos identificados: cuando se aterriza en casa de un cliente nuevo cualquier duda es un riesgo que ha de tener su gestión, mitigación o resolución. Esta pila disminuirá rápidamente en cuanto el equipo conozca al cliente, y una vez aterrizados, aparecerán nuevos riesgos que se añadirán a la pila. Recordemos que Scrum trae todos los riesgos al principio del proyecto y mostrarlos para gestionarlos desde el momento cero es una excelente idea, casi una necesidad.
3. Zona para identificar a todos los interesados en el proyecto. Esta zona a su vez está dividida en cuatro: usuarios de negocio, equipo técnico, propietarios y externos. Por cada interesado hay un post-it, resulta muy elocuente el post-it de color verde que representa al Propietario del Producto, figura central desde el punto de vista del equipo.
4. La hoja de ruta en la que se identifican, sin precisar fechas pero si por semanas y meses, las etapas del proyecto, dando así una idea clara de cómo se pretende construir el producto.
5. Y por supuesto la parte Kanban con su flujo de trabajo para hacer seguimiento diario de las tareas del sprint -1, tareas como: conocer el entorno de desarrollo (framework que es propietario del cliente), hacer el primer User Story Mapping, hacer una simulación para levantar riesgos técnicos y de conocimiento...

Este tablero me parece interesantísimo para ocasiones en que todo sea la primera vez, quizá en el caso de equipos consolidados y con continuidad el sprint -1 no sea necesario pero seguro que también aporta, ya que todo tablero es comunicación pura entre personas. Mi sugerencia sería trasladar la zona 5 a un tablero Kanban propio para los sprints y mantener este tablero como complementario durante todo el proyecto. En él todas las zonas seguirían vivas hasta el final dando una idea muy clara del avance del proyecto a un alto nivel, de como se reducen los riesgos y de como varían quienes interactúan como interesados.

¿Cómo gestionar un bug que se ha detectado en la fase de pruebas con Scrum?

Miembro del equipo de soporte atendiendo

En caso de detección de un bug dentro del mismo sprint, simplemente se resuelve directamente en el mismo sprint. Con este post quiero tratar el caso de bugs detectados en una fase de pruebas posterior al sprint en donde se escribió el código. En este caso lo que dice Scrum es que el bug simplemente se debe de incorporar en la pila de producto para que se resuelva en un sprint futuro. Estuve de co-trainer en un curso con Mike Beedle y en él tratamos su visión de cómo tratar los bugs.

En mis cursos cuando hablo de Scrum y Kanban suelo explicar que Scrum está concebido para el desarrollo productos, y Kanban es una buena herramienta para la fase de mantenimiento y soporte posterior.

La situación ideal es cuando el propio equipo que desarrolló el producto es el que hace el mantenimiento y el que resuelve las incidencias, de esta forma nos beneficiamos de la naturaleza humana y la propiedad colectiva, del orgullo que siente el equipo constructor como "padre" del producto. Si el equipo de mantenimiento es otro, lo que puede ocurrir, y no de forma infrecuente, es que arreglen un bug y generen tres más, y, a la vez, el equipo original deje de sentirse propietario porque otros han modificado el código.

Lo primero que hay que hacer cuando entra un bug es identificar su criticidad, si es un bug no crítico sencillamente hay que recoger información y añadirlo a pila de producto. En caso de bug crítico hay que tomar medidas dentro del sprint actual, desde hacer un intercambio en la pila de producto de una historia de usuario de tamaño semejante por el bug, hasta interrumpir o incluso cancelar el sprint. Bugs críticos se han resolver con urgencia y para ello la mejor receta es aplicar el sentido común. Imaginemos que la base de datos de producción se está corrompiendo, ese es un caso realmente crítico que no puede esperar al sprint siguiente y en el que deberíamos de dejar de hacer lo que estemos haciendo, resolver el problema con los medios necesarios y una vez resuelto regularizar la situación con respecto a Scrum.

Carril bugs sprint anterior - un bug que tiene un bug :-P

Uno de los equipos que acompaño ha incluido un carril para bugs, tienen reservado el 10% de su tiempo para la resolución de bugs y admiten bugs mientras no superen este 10%. Cuando superan el 10% difieren los bugs menos críticos al sprint siguiente, y cuando no llegan al 10% lo que hacen a final de sprint son tareas de refactorización, tareas de mantenimiento como actualización de versiones de ecplise u otros, documentan cosas que tienen pendientes... Abajo podemos ver su tablero a final de sprint, podemos ver los bugs en forma de post-its pequeños.

Tablero scrumboard con un carril para bugs

¿Qué es y como funciona el World Café?

Asistí a un meetup de Madriagil que trató sobre la puesta en práctica de la técnica ágil World Café, dinámica que quiero exponer en este post. Mi experiencia fue excelente, en 2 horas 16 expertos plasmaron sus conocimientos sobre alrededor de 4 temas relacionados con Agilidad de una forma rápida y muy eficaz.

Se trata de una técnica con un formato simple, eficaz y flexible que hace posible el diálogo entre personas en grupos grandes, de manera que emerge conocimiento sobre varios temas en poco tiempo. La dinámica funciona con grupos de hasta 40 personas que interactúan en equipos de 4, lo que redunda en que se pueden tratar tantos temas como el total de personas divididas por 4.

Como ejemplo imaginémonos que somos una unidad de negocio integrada por 20 personas y que pretendemos buscar mejoras a implementar. La dinámica World Café dará como primer resultado las 5 mejores mejoras seleccionadas de todas las mejoras posibles según ese grupo de 20 personas, y el conocimiento unificado sobre cada una de esas mejoras a partir del conocimiento individual.

Cafe Etiquette - The World Cafe

Describiré la dinámica para un grupo de 20 personas según el ejemplo anterior.

Marco: Crear un ambiente con modelo de un café, de ahí el nombre World Café: 5 mesas preparadas con 4 sillas cada una, cubiertas con un mantel (a cuadros por ejemplo), una hoja de papel de flip-board, rotuladores de colores, y algún refresco, agua y quizá unas galletas...

Bienvenida y Presentación: El anfitrión comienza con una cálida bienvenida y una introducción explicando el funcionamiento la dinámica de de World Café, estableciendo el contexto, poniendo a los participantes en antecedentes del propósito deseado de la sesión y compartiendo la "Cafe Etiquette" con las directrices.

Valoración de las preguntas - Cortesía de Marcos

Establecimiento de las preguntas:

• Con los participantes de pie alrededor de una mesa con post-its se les da 5 minutos para que cada uno escriba de 0 a 5 enunciados de mejora a tratar en forma de pregunta
• Se forma una cola y las preguntas se pegan en una pared/pizarra/tablero y cada cual tiene 10 segundos para hacer una pequeña introducción a sus preguntas
• Se valoran las preguntas, 5 minutos para que cada participante ponga un palito en las dos preguntas que más le interesan
• Se extraen las 5 preguntas con más palitos

Rondas:

• Se buscan 5 voluntarios facilitadores (hosters) a los que se les asigna una pregunta y se sienta cada uno en una mesa
• Se forman equipos de 3 personas que forman un equipo y se sientan con un hoster en la mesa y mantienen 20 minutos de conversación
• En la primera ronda se define los conceptos de la pregunta y luego se entra en debate y se busca repuesta
• Pasados los 20 minutos los equipos rotan de mesa y se inician otros 20 minutos de conversación
• En las rondas sucesivas el hoster expone la definición, se entra debate y se enriquece la respuesta
• Cuando todos los 5 equipos hayan pasado por las 5 mesas finalizan las rondas

Mesa para las rondas - cortesía de Antonio

Cosecha: esta trata de compartir puntos de vista, conocimiento obtenido u otros resultados de las conversaciones con el resto del grupo

• Se pegan las hojas flip-board en una pared/pizarra/tablero y cada hoster tiene 2 minutos para exponer los resultados de su pregunta
• También se invita a los participantes que lo deseen a compartir su experiencia durante 1 minuto
• Se hace un pequeña retrospectiva sobre qué se puede mejorar para otras sesiones
• Opcional pero muy recomendable: se sigue debatiendo en el bar con unas cervezas :-)

Para quién quiera profundizar en la técnica le recomiendo la página The World Cafe.