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

¿Cómo se mide el valor de las historias de usuario?

Con cada sprint aumenta el valor de negocio del producto

La información "valor" representa el valor de negocio que aporta una historia de usuario una vez realizada, es una información más profunda que la razón de la historia misma ya que está íntimamente ligada a la lógica de negocio. ¿Pero qué mide esa información? Podríamos decir, hablando en plata, que representa "cuánto dinero está dispuesto a pagar nuestro cliente por esa funcionalidad". Cuanto más esté dispuesto a pagar, más valor de negocio tiene. Tal como funcionan Scrum y la Agilidad entregar valor significa focalizarnos en resolver los problemas de alguien o en dar beneficios a alguien..

Adicionalmente quiero resaltar que hay historias que no tienen valor de negocio, por ejemplo una página de login, pero sin las cuales no se pueden construir las otras historias que si tienen valor. El valor de negocio es muy importante para priorizar correctamente, focaliza al equipo de desarrollo en todo momento en aquello que es prioritario construir y maximiza el valor y la satisfacción percibida por el cliente en cada sprint, pero no es lo único, hay dependencias y otros factores que pueden determinar la prioridad, es por ello por lo que valor y prioridad son dos informaciones independientes.

El valor se mide con una escala arbitraria (normalmente valores numéricos) que aporta la historia de usuario o epic al cliente o usuario. Ha de ser una escala con la que el Propietario del Producto y los usuarios de negocio se sientan cómodos, series  de números naturales del 1 al 10, del 1 al 100, del 1 a 1.000.000 o la serie de Fibonacci por ejemplo.

Billetes del Monopoly

Una forma que me parece muy estimulante y divertida es repartir billetes del Monopoly por el valor total del proyecto a cada uno de los usuarios de negocio involucrados, y que estos repartan el dinero en función del valor que le atribuyen a cada historia de usuario. Es un ejercicio que les acerca a la realidad, no les toca directamente el bolsillo pero lo simula muy bien. Finalmente el valor es la suma del los billetes de todos, opcionalmente se puede dividir el resultado por 100 o 1000 para que sea un número más manejable.

Benoît Pointet y Thomas Botton proponen en su artículo "Key Dimensions of User Stories" estimar el valor de la misma manera que el equipo estima el esfuerzo, mediante cartas de planning poker con la serie de Fibonacci. El valor, igual que el esfuerzo, es sumativo y relativo entre historias. La idea es que el Propietario del Producto y los expertos de negocio jueguen a planning poker, y de la misma manera que se crea una base de conocimiento en las reuniones del equipo, las reuniones para la estimación de valor crearán una base de conocimiento compartida para usuarios y gente de negocio.

Esta propuesta tiene dos efectos colaterales muy interesantes: trae respeto y comprensión del equipo hacia el Propietario del Producto, y, este último comprenderá más fácilmente porqué el equipo necesita en ocasiones reestimar ciertas historias de usuario.

¿Cómo evitar los post-its voladores que se desprenden de los tableros Kanban?

Post-its reforzados con celo sobre un whiteboard

Todos los que trabajamos con tableros físicos hemos sufrido la caída de algún post-it mientras poblamos el mismo en la planificación del sprint, o lo que es peor, en el momento en que hemos acabado el tablero y lo mostramos en todo su esplendor, va y se despega un post-it, y medio fastidiados medio divertidos observamos como cae burlón y suavemente y aterriza en el suelo sin más. Y luego están las caídas que nadie ve y que luego no siempre sabemos de dónde provenía... o cuando alguien ajeno al proyecto pasa cerca y con el movimiento del aire provoca alguna caída y furtivo coloca los post-its caídos rápidamente en dónde mejor le parece...

Tablero de corcho con
post-its reforzados con chinchetas

Convivimos con ello como un mal menor y a alguien se le ocurre el paliativo de hacer una foto de backup cada día antes de fin de jornada, foto que sirve para detectar al día siguiente si ha habido algún incidente en el transcurso de la noche. 

Pronto aparecen soluciones alternativas como por ejemplo utilizar celo para fijar los post-its. El resultado es una mejor fijación, pero eso hace más laborioso moverlos, hay que ir con cuidado para despegar el celo que puede doblarse y autopegarse antes de llegar al destino. Además el pegamento del celo deja rastro en el tablero whiteboard y va deteriorando la calidad del mismo.

Algunos decidimos probar con tableros de corcho y fijar los post-its con chinchetas. Es una solución, pero perdemos el potencial y la flexibilidad de los rotuladores para pintar sobre el tablero. Podemos marcar las líneas con cinta de carretero y para las etiquetas y el gráfico burndown utilizar trozos de papel fijados también con chinchetas, pero la facilidad de uso se ve muy mermada.

Post-its fijados con imanes

Volvimos al tablero whiteboard, esta vez lo buscamos magnético y fijamos los post-its con imanes. Funciona, pero siempre ocurre que hay más post-its que imanes... Además, resulta que los imanes son muy útiles para otras funciones, por ejemplo un imán rojo en un post-it puede indicar que la tarea está bloqueada. Es una solución pero perdemos otras posibilidades que harían que nuestro tablero fuera aún más funcional y ágil.

La mejor solución que hemos encontrado son los post-its super sticky. Hay varios fabricantes, nosotros hemos probado las Notas Post-it® Super Sticky de 3M de máxima adhesión. En la página del producto podemos leer entre otros beneficios:

• Permanecen pegadas más firmes y por más tiempo
• El adhesivo súper fuerte hace que permanezcan pegadas de forma aún más segura que las Notas Post-it® originales
• Las Notas Post-it® Super Sticky son súper fuertes, súper versátiles y súper llamativas

Para ilustrar lo fuerte que fijan hemos probado pegar uno a una superficie de cristal, practicarle un agujero y colgarle una tijera grande. El post-it super sticky ha soportado la tijera sin novedad durante media hora, hasta cuando dimos la prueba como ampliamente superada.

Post-its super sticky pegado en una superficie de cristal
aguantando el peso de una tijera de cocina

Michael Arrighi describe en un artículo su técnica CPT (Correct Post-it Technique) para conseguir una buena fijación. La clave está en como arrancamos el post-it del bloc, hay que hacerlo de lado, nunca de abajo a arriba. 

Como arrancar correctamente los post-its del bloc

Para determinar si los post-its son buenos y si los hemos fijado correctamente simplemente hay que quitar un post-it del tablero y fijarse como queda la parte con el adhesivo, si queda enrollada es que algo no va bien, un buen post-it bien fijado queda perfectamente plano aún quitándolo repetidas veces.

¿Cómo se realiza la planificación de sprint?

Con esta reunión, en el cuarto nivel de la planificación ágil, Scrum marca el inicio de cada sprint. En ella se planifica el trabajo a realizar en las siguientes semanas tomando como base las prioridades y necesidades de negocio, dándose respuesta a las siguientes cuestiones:

• Qué historias de usuario formarán el incremento que se entregará al finalizar el sprint
• Cuál es el trabajo necesario para realizar ese incremento previsto
• Cómo lo llevará a cabo el equipo

La reunión la conduce el responsable del funcionamiento del marco Scrum, usualmente el Scrum Master, pero en equipos maduros en Agilidad la conduce el propio equipo. Deben de asistir tanto el Propietario del Producto como el equipo al completo, y pueden asistir, sin voz ni voto, otros interesados en el proyecto, aquellos que puedan aportar información útil.

La reunión consta de dos partes, la primera responde a la pregunta: ¿Qué se entregará al terminar el sprint? y la segunda a: ¿Cómo se llevará a cabo la construcción del incremento?

Primera parte: se tratan las funcionalidades de la pila de producto

Primera parte

El Propietario del Producto presenta la pila de producto y expone los requisitos de mayor a menor prioridad y que prevé pueden caber en el sprint. Si la pila de producto ha tenido cambios significativos desde la vez anterior, explica las causas que los han ocasionado para que todo el equipo entienda el porqué del cambio. El objetivo de la reunión es que todo el equipo conozca las razones y los detalles con el nivel suficiente para comprender el trabajo a hacer en el sprint.

Tras reordenar y replantear las funcionalidades de la pila de producto, el equipo define el "objetivo del sprint" que sintetiza cuál es el valor que se le va a entregar al cliente. Ponerle nombre a las cosas nos acerca al negocio y en este caso hace que el equipo comparta la finalidad del trabajo.

Segunda parte: se estima
y se obtiene la pila de sprint

Segunda parte

Esta segunda parte debe considerarse como una reunión del equipo, por tanto deben estar presentes todos sus miembros. El equipo desglosa cada funcionalidad en tareas, y estima el tiempo para cada una de ellas para poner el corte a la pila de producto de hasta donde se comprometen a llegar y obteniendo así las tareas que forman la pila del sprint. Cada miembro habrá participado libremente en la planificación y creerá en el plan, y eso lleva a un sentimiento de compromiso. En este desglose el equipo debe de tener en cuenta los elementos de diseño y arquitectura que deberá incorporar al sistema.

Finalmente el equipo establece la estrategia para iniciar el sprint determinado las tareas para los primeros días del mismo, y luego, a modo de primera reunión diaria los miembros se las autoasignan uno a uno tomando como criterios sus conocimientos individuales, sus intereses individuales y una distribución homogénea del trabajo.

Tableros que intervienen en la planificación de sprint: 1 - la pila de producto en la que el equipo hace el corte (post-its verdes)
para llevarse al sprint, y 2 - Scrum Board dónde sobre las historias elegidas el equipo las desglosa en tareas (post-its amarillos)

Al final de la reunión se habrá determinado:

• Los elementos de la pila de producto que se van a ejecutar
• El objetivo del sprint
• Los criterios de aceptación y de hecho que cierran las historias de usuario y el sprint
• La pila del sprint con todas las tareas estimadas
• La duración del sprint y la fecha de la reunión de revisión

Como en todas las reuniones de planificación, esta también favorece la fertilización cruzada de ideas en equipo y aporta a la creación de una base de conocimiento común.

¿Qué tal iceScrum como software para ayudar a los equipos a alcanzar el éxito en sus proyectos?

He estado acompañando a tres equipos que para su gestión utilizan iceScrum, y he decir que he experimentado un software muy completo. Gestión visual a parte, el tablero no irradia información ni se ha convertido en un punto de referencia del equipo, este software realmente da solución a todas las necesidades de un desarrollo con Scrum. En la página de iceScrum podemos leer respecto a sus características:

Desglose de elementos: el producto se divide en sus características principales. Las características se dividen en pequeñas funcionalidades, las historias de usuario, que se implementan por el equipo a través de tareas.

Informes y métricas: iceScrum produce automáticamente informes ágiles como burndown, burnup, gráfico de estacionamiento, diagrama de flujo acumulado...

Pila de producto: la pila es el conjunto de historias que se preparan, refinan y se priorizan para que puedan ser planificadas y ejecutadas en los sprints por el equipo.

Roles: los permisos se otorgan de acuerdo con el papel en el equipo Scrum: Scrum Master, Propietario del Producto, miembro del equipo o interesados.

Lo que no me gusta

• En el tablero las tareas en curso están correctamente asignadas a los miembros del equipo, pero para poder mover una tarea de columna solo lo puede hacer el miembro propietario y este debe de estar logado, por tanto una gestión visual ágil para mover los post-its virtuales queda mermada de tal manera que es impracticable.

Equipo ante el tablero iceScrum en la reunión diaria

Lo que me gusta

• La pila de producto se representa en forma de post-its y permite la colorización, esto permite distinguir tipos de historias por su naturaleza, por ejemplo epics de historias de usuario e historias de usuario de historias técnicas.

Pila de producto y burnup

• El tablero de Scrum efectivamente gestiona el flujo de trabajo, aunque en la práctica lo hace de manera diferida.
• La opción de definición de hecho (DoD) está contemplada a nivel de sprint, esta es, a mi entender, una de las características más importantes que hacen que funcione Scrum.
• También tiene previsto la gestión de las retrospectivas.
• Y lo que me encanta es que la línea ideal del burndown no se pueda modificar una vez iniciado el sprint. Todos los equipos se quejaron de ello... de ahí hay que sacar una lección muy importante: ¡un sprint iniciado es intocable! y, el burndown es un gráfico para que el equipo sienta el avance, no una herramienta de reporting hacia arriba.

Tablero Scrum y burndown

iceScrum es un software que se puede contratar en la nube con coste, o descargar gratuitamente en su modalidad de community license (free & open source) e instalar en un servidor web propio.