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

¿Cuál es la diferencia entre conocimiento explícito y tácito?

Realmente lo que ocurrió es que un alumno me preguntó en un curso presencial: ¿Qué es el conocimiento tácito? Sonreí por dentro con cierta ironía porque el hombre acababa de realizar su certificación PMP, e imaginé que la certificación en Scrum estaba haciendo tambalear sus esquemas. He de admitir que este alumno se interesó mucho por Scrum, y que sus comparativas con PMBOK siempre resultaron en una síntesis que sumaba.

El conocimiento puede tener dos naturalezas:

• Explícito: contenido en los procesos y la tecnología
• Tácito: contenido en las personas

Reglas de Scrum como conocimiento explícito, cortesía de Juan Palacio

El conocimiento explícito es aquel conocimiento que se puede escribir, codificar y almacenar en algún tipo de medio y tiene la característica de poder ser transmitido inmediatamente a otros, tanto personas como sistemas. Los procesos y la tecnología empleada en un proyecto se basan en conocimiento explícito, la calidad de sus resultados se encuentra en ese conocimiento explícito. Un ejemplo de ello son las reglas del marco de trabajo de Scrum, el resultado de la implementación del Scrum reside en la correcta aplicación de sus reglas, en definitiva el conocimiento explicitado en la figura del post.

El conocimiento tácito consta comúnmente de hábitos y aspectos culturales que difícilmente reconocemos en nosotros mismos, o en palabras de los autores Nonaka & Takeuchi (1995) un conocimiento "informal, personal o social, difícil de expresar de forma sistematizada - poco visible y difícil de compartir por los medios tradicionales - que poseen los actores del contexto donde se desarrolla cualquier actividad humana, incluso dentro de las organizaciones".

Uno de los aforismos famosos de Polanyi respecto al conocimiento tácito es: "Conocemos más de lo que podemos decir". Por ejemplo, los que trabajamos en proyectos de TI en ocasiones nos hemos visto enfrentados a una incidencia que no sabemos por dónde cogerla. Entonces uno de los miembros experimentados del equipo utiliza expresiones como "esto es como aquello que...", "esto me suena a la función de...", "mirar allí..." y efectivamente, ese conocimiento difuso que procede de la experiencia con el proyecto nos lleva a la solución de la incidencia. Otro ejemplo de conocimiento tácito es cuando vemos por primera vez un piso candidato de compra o alquiler, entramos en el piso y gracias a nuestro conocimiento tácito e inteligencia emocional sabremos en 2-3 minutos si nos vale o no vale. Hacer este mismo análisis con un proceso explícito en base a nuestra inteligencia racional costaría entre ¡¡¡2 y 4 horas o más!!!

En Agilidad la producción se basa en personas donde el conocimiento o "know-how" responsable de la calidad del resultado se encuentra en mayor medida en el "saber hacer" tácito de las personas que lo construyen. Las personas adquirimos conocimiento tácito automáticamente al compartir experiencias, con la comunicación directa, con documentos, con manuales y con tradiciones, añadiendo así continuamente conocimiento novedoso a la base colectiva de la organización.

¿Cómo resuelve Scrum la frustración de un desarrollador cuando le viene una enésima modificación de su tarea?

Si preguntamos a los programadores qué es lo que más les fastidia y más malestar les produce, su contestación suele ser que cuando les hacen modificar una y otra vez el mismo código o transacción. 

Desesperado ante un cambio, gracias Pedro por la escenificación :-)

En equipos tradicionales, sin valores ágiles adquiridos, los desarrolladores suelen no ver más allá de la parte del desarrollo que les atañe directamente, y son varios los sentimientos de rechazo que puede producirles un enésimo cambio:

• Una asociación automática con que les viene "otro marrón que no es mío" que supondrá un esfuerzo por su parte y que asociará directamente a correr, a estrés y a hacer horas extra
• Un sentimiento de crítica hacia su trabajo, contrario al reconocimiento que todos necesitamos
• Enfado hacia el usuario, analista o jefe de proyecto que según su percepción no sabe lo que necesita, produciéndose exclamaciones como "Que hagan bien su trabajo, y antes de marearme que definan bien..."
• Desmotivación por sentirse anclado a la misma pierda y no ver avance

Una de las consecuencias más caras de la desmotivación puede ser una degradación paulatina del código, la incurrencia en deuda técnica y por ende, de una calidad mediocre del producto.

Como expone el Manifiesto Ágil "valoramos la respuesta ante el cambio sobre seguir un plan", Scrum abraza el cambio y por tanto, situaciones de enésimos cambios sobre un mismo objeto forman parte de la naturaleza de los proyectos ágiles. Entendido esto, tanto por el equipo como por todos los demás interesados, la mentalidad con la que el desarrollador se enfrenta a estos cambios es muy distinta. El cambio no le rompe nada, el cambio forma parte de su día a día y tiene la vía de incorporación del cambio resuelta:

• La tarea al estar dentro de un sprint intocable, con un inicio y un final, hará que el programador haya cerrado mentalmente el cambio en curso antes de iniciar un posible cambio posterior en otro sprint
• No hay solapamientos. Nuevos cambios, nuevos sprints, un espacio propio y acotado para cada cambio. Al entrar en un sprint el nuevo cambio este es reconocido y aceptado por todos, tanto equipo como interesados
• Gracias a la comunicación y transparencia propia de Scrum, el programador tiene visión del producto y así está preparado para entender el porqué del cambio. Tiene empatía hacia el cliente y es capaz de ver y entender la necesidad del cambio, y de que se ha producido por un cambio sufrido en el negocio/mercado que se le ha contando y comprende
• No tiene sensación de hacer un esfuerzo extra, cada cambio viene a través la pila de producto y entra en la pila de sprint con el tiempo necesario para realizarlo
• No tiene sensación de trabajo mal hecho, si su tarea ha estado bien hecha ha sido reconocida en la reunión de revisión de sprint correspondiente
• El sentimiento es de avance continuo, si no es por su tarea inmediata percibe el avance en adaptación del producto a las variaciones del negocio

La motivación hace que el desarrollador se sienta parte del proyecto y viva el producto, y de esta forma busque automáticamente la mejora continua en el código.

La motivación intrínseca que propicia Scrum va mas allá de la satisfacción del trabajo técnico bien hecho, esta surge del trabajo en conjunto bien hecho, sentir el orgullo de como la herramienta en que se ha participado resuelve realmente el trabajo diario a usuarios y clientes.

¿Pueden tomar los miembros del equipo el rol de Scrum Master de forma rotativa?

En uno de mis cursos tuve una conversación muy interesante con una de mis alumnas en cuya empresa habían implantado Scrum. Al inicio de la implantación decidieron que cada uno de los miembros del equipo pasaría por el rol de Scrum Master con la idea de que se enfrentara como Scrum Master a todas situaciones que este vive, y así todo el equipo adquiriera mayor conocimiento práctico y experiencia en Scrum. La idea fue que todo el mundo estuviera durante un sprint en la piel de quién garantiza y vela por las reglas de Scrum, además de desarrollar la gestión que conlleva el rol.

Vivir las actividades de un Scrum Master

Recordemos que un Scrum Master es un rol que se encarga de facilitar la comprensión de Scrum, de acompañar a los equipos y velar que estas se apliquen, de garantizar que estas no se rompan, además de facilitar la resolución de impedimentos al equipo. Tiene un perfil de coach para poder acompañar al equipo y a cada miembro en su camino hacia la autonomía, la autoorganización y la adopción de los valores ágiles como son la transparencia y el compromiso.

La experiencia fue muy positiva para aquellos perfiles de personas abiertas e interesadas por lo que les rodea, para ellos fue motivante y les llenó de entusiasmo. Los perfiles más introvertidos se limitaron a ejecutar las acciones derivadas de las reglas de Scrum de forma mecánica, para ellos fue una experiencia menos enriquecedora y prácticamente nada motivante.

La respuesta a la pregunta del post es un "si" para aquellos que tengan un perfil afín, generalmente de tipo T, y un "no" para aquellos en que su área de intereses cae fuera de las tareas de un Scrum Master. Recordemos que en un equipo puede haber sitio para todo tipo de perfiles, puede haber un perfil poco entusiasta que resuelve echen lo que le que echen, y otro perfil exultante que siempre esté metido en todo lo novedoso y en todo lo que sea un reto. La combinación de esos dos perfiles tan diferentes puede hacer del equipo un equipo ganador.

Quiero resaltar que un Scrum Master externo al equipo generalmente es una mejor solución, cuando el proyecto tiene problemas el Scrum Master y a la vez miembro de equipo puede tener un conflicto al tener que decidir si ir en favor del proyecto o de Scrum.

Este post lo dedico a Antonio y a Jordi, dos personas tan distintas y tan complementarias que formaron parte de un Dream Team en el que pensé mientras escribía estas líneas.