¿Quién presenta el incremento en la revisión de sprint?

Miembro del equipo presentando el incremento en la
revisión de sprint - cortesía de Pixabay

A lo largo de diferentes equipos he visto distintas configuraciones que dan distintas respuestas a esta pregunta.

Nos encontramos en la revisión de sprint donde, según el marco de Scrum, el equipo es quien enseña lo que ha realizado a lo largo de del sprint. Primero expone el objetivo del sprint para después demostrar el funcionamiento de lo que ha completado al 100%, aquello que entrega y cumple con la definición de hecho (DoD).

Usualmente se recorren una a una las historia de usuario de la pila de sprint, se explica como se abordó cada una de ellas y se demuestra el funcionamiento en un entorno que represente entrega (test, staging, preproducción...). Tratada la historia en curso se pasa a la siguiente. Pero, ¿quién se sienta ante el ordenador y demuestra el software funcionando e interlocuta con los interesados?

La respuesta es el equipo de desarrollo, y es una preferencia del equipo como hacerlo, a veces hay un voluntario, a veces se nomina un presentador de entre los miembros y a veces lo hacen de forma compartida. He visto varias configuraciones que funcionan:

• El tester hace de presentador: es una opción que funciona muy bien porque el tester habrá efectuado las pruebas a lo largo del sprint, tiene la visión del incremento fresca en su memoria, y por la naturaleza de su especialidad está mas cerca de los usuarios para los que se está construyendo el producto.
• Un líder que emerge del equipo: siempre suele haber un voluntario con habilidades sociales al que le guste mover cosas y tratar con otras personas. Suele tener más empatía y más comprensión del la solución a nivel holístico.
• Algunos miembros de forma rotatoria: es una opción que funciona cuando no es obligatoria para todos los miembros, funciona solo si rotan aquellos miembros del equipo que quieran hacerlo de forma voluntaria. Una revisión de sprint presentada por un miembro que siente que no puede hacerlo, o no quiere hacerlo, probablemente resulte en una reunión pobre que genere un feedback escaso.

En mi experiencia la mejor combinación es cuando una persona presenta y lleva la conversación con los interesados, y otra persona ejecuta la demostraciones de las funcionalidades en el ordenador. Si además intervienen otros miembros cuando sienten que tienen algo que puedan aportar tenemos la mejor de las opciones posibles

Como siempre suele ser con Scrum, para saber si tenemos una reunión exitosa basta con fijarnos en como interactúan las personas, si el campo emocional es de "buen rollo", las personas hablan como iguales, con respeto y seguras y sin miedo a equivocarse, entonces podemos estar seguros que todo está bien encarrilado.

¿Qué hacer ante una historia de usuario que no es divisible y no cabe en un sprint?

Estimando una historia de usuario grande

Es usual que equipos que se inicien en Scrum no sepan o no crean posible dividir las historias de usuario en elementos tan pequeños como para que quepan en un sprint de dos semanas. Están acostumbrados a construir funcionalidades a lo largo de semanas o meses y son escépticos ya que no ven sprints de dos semanas con 5 o 6 historias.

Existen historias de usuario que no se pueden dividir, las denominadas historias complejas que son fundamentalmente grandes, pero son excepciones muy muy raras.

Veamos un ejemplo en un diseñador de informes, un elemento que ayudó a crear Manuel, un alumno, en uno de sus proyectos. Incluía una parte visual donde el usuario componía el informe como un puzzle, y otra en donde se tomaba esa composición y se convertía en una consulta SQL para enviar a la base de datos. Según él esa historia seguramente representaría un sprint de un mes para un equipo pequeño, quizás más.

Lo que nos dice Scrum es que las historias de usuario deben de ser lo suficientemente pequeñas para caber en un sprint, por tanto hay que dividir la historia de usuario. Veamos qué podemos hacer:

Podemos dividir en historias según
el esquema de base de datos
Cortesía de Pixabay

Posiblemente el diseñador de informes se base en más de una tabla, o en unas cuantas decenas de campos. Una forma de dividir el informe podría ser: hacer en el primer sprint todo el informe completo pero que solo trabaje con la tabla principal y con los 10 campos que más valor de negocio tengan... y de sprint en sprint vamos añadiendo tablas y campos, siempre según el valor de negocio que aporten. De esa forma si en el 4 sprints por ejemplo, resultase que el usuario se ha dado cuenta que no sabía de una tabla muy importante, o se había olvidado de ella (somos humanos), o se ha creado una tabla nueva, no hay ningún problema en adaptarse e incluir lo que sea. Del mismo modo, si descubrimos tablas y campos sin valor, y esas inevitablemente se irán dejando para futuros sprints, llegará un momento en que quizá debamos de plantearnos si tiene sentido incluirlas.

Bien, resulta que no somos capaces de dividir la historia y necesitamos dos sprints, ¡la excepción confirma la regla! Hacer en el primer sprint la consulta SQL y mostrarla en la revisión de sprint. Obtendremos feedback de los usuarios y el Propietario del Producto, sobre si esos son los campos que quieren, de si la consulta devuelve la información esperada y de si es eso lo que necesitan. La clave en Scrum está en la constante inspección y adaptación, los puntos de feedback y de aprendizaje.

Si nos llevaramos historias muy grandes a los sprints gastaríamos tiempo dentro del sprint para entenderla, lo que implica incertidumbre y riesgo, las divisiones en el refinamiento y en la planificación de sprint dan un entendimiento mas profundo de la historia.

Una de las disfunciones clásicas es cuando el equipo está insistiendo en que las historias grandes de la pila de producto no se pueden dividir en más pequeñas. Como Scrum Master debemos de tratar esa disfunción, uno de los métodos eficaces es mostrarles cómo dividir una historia de un ejemplo real que sea familiar para el equipo. Una vez hecho esto, es muy difícil seguir argumentando que no es posible dividir esa historia.

Otro aspecto importante es la motivación general del equipo para dividir historias, podemos trabajar con el hecho de que los equipos se motivan al finalizar historias pequeñas y sienten el logro cada vez que lo hacen.

¿Cómo aumentar la positividad en los equipos?

El mejor equipo del mundo, lo que
quiere todo Scrum Master

Ocurre que a veces, y sobre todo en los momentos de crisis, que se desvanece el propósito del equipo, por ejemplo en caso de equipos quemados donde se ha perdido la razón de ser y puede haberse difuminado el significado profundo de las relaciones entre sus miembros.

Estoy dando los primeros pasos en coaching sistémico con la trayectoria de cursos ORSC (Coaching de Sistemas de Organización y Relaciones) de la mano de una gran coach y trainer, Judy van Zon, donde he aprendido a incrementar la positividad de los equipos mediante la técnica del mito de la relación.

No tardé mucho en probar lo aprendido, me animé y guié a uno de los equipos que acompaño como Scrum Master a través de una trayectoria para dar respuesta a la pregunta: ¿Para qué estamos juntos y hacemos lo que hacemos?

Responder a esta pregunta hace que el equipo recuerde lo que le une y recupere lo que se llama el mito de la relación.

Como guía utilicé una serie de preguntas dirigidas a cada uno de los miembros, formuladas en presencia del equipo al completo, con libertad para contestar aquellas que quisieran:

• ¿En el primer momento qué te atrajo del equipo?
• ¿Qué valoraste primero al trabajar con el equipo?
• ¿Qué recuerdos tienes de los primeros momentos?
• ¿Qué admiras y valoras de cada uno de tus compañeros?
• ¿Qué tiene de especial tu equipo?
• ¿Cuál es la misión de tu equipo?
• ¿Qué rol tiene tu equipo para el mundo?
• ¿Qué metáfora, nombre o figura definiría lo mejor de tu equipo?

Las primeras reacciones de los miembros más valientes fueron, entre sonrisas nerviosas y diablescas, "Álex, ¡más vale que esto salga bien!", "Esta la vas a pagar...", jajajaja, me di cuenta que estaba sacando al equipo fuera de su zona de confort, donde ocurren cosas sorprendentes.

Equipos positivos - cortesía de Pixabay

A medida que avanzaba con las preguntas, las sonrisas se iban reforzando y el campo emocional se iba llenando de energía :-)

Al final les pregunté por como habían vivido el ejercicio, y mencionaron cosas como:

• Está bien haber hablado de cosas que nunca hablamos
• ¡Qué buen rollo!
• Gracias Miguel por apoyarme en los momentos difíciles del último sprint
• Ricardo te agradezco mucho...

El ejercicio puso de manifiesto el afecto por los compañeros y la admiración por los demás e hizo una fuerte labor de team-building. Lo que a mi me llenó hasta la médula fue cuando uno de ellos dijo: "Álex, ¡lo haces muy bien!" :-D

¿Qué estrategias de división de historias de usuario son las principales?

Póster SPIDR con los 5 pasos - thanks Mike

En su curso "Better User Stories" Mike Cohn comparte su enfoque de 5 pasos para dividir historias de usuario de forma ágil y que él llama el método SPIDR, método que quiero presentar en este post.

Comparto con él que estas son las estrategias de división clave, que con su método vamos al grano y que se trata de un número suficientemente pequeño para que las recordemos fácilmente.

Formando parte del curso hay un póster para ayudar a la gente a recordar cada uno de los 5 enfoques SPIDR, póster que Mike ofrece a los equipos como una descarga gratuita:

To get your copy, just click here: S.P.I.D.R. Poster. Please also feel free to share the link with any colleagues you think might find it useful.

Vamos a ver lo que significan las siglas SPIDR:

Spikes: Una actividad de investigación y exploración previa para construir el conocimiento necesario para dividir una historia de usuario compleja. Una historia puede ser grande porque el equipo no entienda la funcionalidad, la tecnología que implica o porque haya varias maneras de construirla. Con las conclusiones del spike el equipo podrá tomar las decisiones adecuadas y refinar la historia convenientemente.

Paths: Cuando se trate de historias grandes porque haya varios caminos posibles para que el usuario haga algo, los diferentes caminos son una buena estrategia de división. La mejor forma de encontrar los caminos es dibujando un diagrama de flujo, por ejemplo en el caso de varias formas de pago con caminos como visa, PayPal, transferencia, etc.

Interfaces: División de la historia por diferentes interfaces que soportan la funcionalidad, como por navegador o por hardware. Ejemplos clásicos son los navegadores Chrome, Firefox, Edge... o los sistemas operativos como Windows, iOS y Android.

Data: Es posible que la historia pueda ofrecer valor en un sprint dividiéndola centrándonos en un tipo de dato. Por ejemplo si se trata de una funcionalidad de sugerencia de producto podríamos dividir la historia en función de una fecha, en invierno tratar ropa como los abrigos y en verano copas como los mojitos. :-D

Rules: Se trata de la división por diferentes reglas que ha de seguir una historia de usuario, por ejemplo reglas de negocio, estándares de industria, etc.

¿El Propietario del Producto ha de tener background técnico?

El Propietario del Producto es un rol que cubre dos áreas
de forma independiente, thanks Alexandre for the picture

El Propietario del Producto representa a negocio para asegurar que el producto esté alineado con las necesidades del cliente. Para ello actúa como interfaz entre negocio y el equipo técnico, es un rol que conecta dos áreas de forma independiente, que tradicionalmente están conectadas de forma mermada por un jefe de proyecto que usualmente organiza y forma parte del equipo técnico.

Como nos cuenta Guillermo Villarrubia Esteban en su post "Lo que un Product Owner no es" sus responsabilidades e influencias son:

• El producto es suyo
• Sabe todo de las funcionalidades
• Sabe cómo lo utilizan los usuarios
• Sabe cómo desearían usarlo los usuarios
• Decide cuáles son los requisitos del producto
• Decide indirectamente el orden de implementación
• Debe estar al corriente de cualquier matiz que pueda afectar al negocio del producto
• Es el responsable del producto frente a negocio y los usuarios

Propietario del Producto, mejor sin background técnico
Cortesía de Pixabay

Tiene mucha responsabilidad, pero sólo en el ámbito funcional, no en el ámbito técnico. Por tanto solo habría de tener background técnico si el producto fuera tecnológico.

Ha de tener un cierto sentido de lo que es la tecnología y de los problemas propios de los equipos de TI, para ayudarle a comprender a los equipos, a apoyarles, a entender las historias técnicas y así mejorar la gestión de la pila de producto. No es necesario que tenga background técnico, la medida justa la adquiere de forma automática con su participación en el marco de Scrum, donde construye base de conocimiento en común con el equipo con cada punto de feedback y aprendizaje, con cada sprint.

El rol de Propietario del Producto es un rol en el que puede reciclarse un jefe de proyecto ya que estos suelen estar muy cercanos a negocio. Como Propietario del Producto éste ha de aprender a saber estar apartado del equipo, tiene que desaprender a imponer al equipo cómo implementar las funcionalidades. Un jefe de proyecto tiene facilidades para ello ya que probablemente lleve años sin programar, y para ser un buen Propietario del Producto puede entender y estar abierto a entender que el equipo sabe más de tecnología que él, aunque su origen y su vocación primitiva haya sido técnica.

¿Cómo sería una buena dinámica para generar una visión del producto?

Primera iteración de la visión

Este es un ejercicio del curso CSPO de

Recientemente hice un co-training con Alexandre Magno en un curso para Propietarios del Producto y me gustó mucho la forma en que enseña a validar el resultado de la visión.

La visión se genera según patrón del elevator pitch de la Incepción Ágil:

FOR <cliente objetivo>

THAT <declaración de necesidad>

THE <nombre de producto> IS A <categoría del producto>

THAT <beneficio clave, razón de peso para comprar o usar>

UNLIKE <competidor/alternativa>

OUR PRODUCT <declaración diferencial>

Segunda iteración con un
mensaje refinado que se ajusta
a la visión que querían mostrar

Una vez escrita, y esto lleva su tiempo ya que se trata de alinear al equipo que genere la visión y que se genere un contexto compartido, y para ello es necesario debate y conversación, se expone a otros asistentes, interesados o idealmente representantes objetivo del producto. Estos leen la visión sin tener opción a preguntar o resolver dudas con el equipo generador de la visión, y luego cada uno de ellos cuenta una historia basada en el mensaje que le ha llegado.

Así el equipo que ha construido la visión obtiene feedback directo del mensaje que lanza su visión y puede validarla. Probablemente la validación requiera de más de una iteración, habremos obtenido un mensaje ajustado a lo que se pretende mostrar con la visión cuando las historias expliquen situaciones alineadas con el mensaje que queramos lanzar.

Resaltar que es de gran importancia que la única vía de comunicación hacia los que cuentan las historias, sea el elevator pitch de la visión. Es el medio con el que después transmitiremos la visión a los demás interesados del proyecto/producto.

Mis agradecimientos a los asistentes al curso CSPO de mayo de 2017 :-)

¿Cuándo dar por terminado un proyecto Agile?

Calendario marcado con la fecha de entrega del proyecto
Cortesía de Pixabay

David, un asistente a los cursos on-line de Scrum Manager, se dió cuenta que aplicando Scrum la pila de producto puede ir aumentando y creciendo a medida que avanza el proyecto... y eso le preocupaba, ya que el Propietario del Producto podría alargar y alargar el tema añadiendo nuevas historias de usuario y que termine convirtiéndose en un proyecto eterno!!!

Cuando pensamos en términos de proyecto pensamos en relaciones contractuales y nos puede invadir el mal sabor de boca de nuestra experiencia con proyectos clásicos, recordemos que según el CHAOS Report del Standish Group de 2011 sólo el 14% de los proyectos en cascada son exitosos.

Pero tomemos la perspectiva del producto, que es lo real, lo que hay detrás de la abstracción que llamamos proyecto. ¿Se puede saber cuando finaliza la construcción y evolución de un software? Nadie lo puede saber, va a depender del mercado y de como somos capaces de adaptarnos. Ojalá la pila de producto se alimente continuamente de funcionalidades de gran valor de negocio, eso quiere decir que el negocio que hay detrás del software está floreciendo. Y ante esta perspectiva ¿limitar la adición de funcionalidades de mucho valor a la pila no sería perder oportunidades y por ende mermar nuestra presencia en el mercado? Scrum va de la gestión de entregas de producto, no de proyectos... esa es la clave.

Pero volvamos a los proyectos, al fin y al cabo una de las grandes verdades de la vida es que los recursos son limitados y las ideas no, por tanto nuestro cliente puede estar limitado por un presupuesto, ¿Scrum podrá proporcionarle un producto por ese presupuesto a base de las mejores ideas?

Un proyecto ágil se limita por presupuesto y tiempo, pero no por alcance, porque su entrega no consiste en funcionalidades, como en un proyecto tradicional, sino en la entrega de valor. En definitiva, limita presupuesto y tiempo, saca el alcance inicial de ecuación, utiliza ese alcance inicial como un punto de partida materializandolo en la pila de producto, y haz que el equipo siempre construya lo más importante, lo que más valor aporte, y con calidad. En el camino incluye funcionalidades emergentes de mucho valor y priorizalas, y cuando llegue la fecha de entrega y se haya gastado el presupuesto, simplemente se acabó el proyecto. A esa fecha habrás obtenido el mejor producto posible para ese presupuesto y tiempo.

Un ejemplo de la vida común: contratas un proyecto a un pintor para que pinte tu salón de color rojo y tu baño de color verde. Lo que más valor tiene para ti es el salón, por tanto el pintor hace el primer sprint en el salón, y supongamos que le ha cabido la primera pared. Hacéis una revisión de sprint, y cuando ves la pared de color rojo te das cuenta de cuanto te has equivocado, que no vas a sentirte cómodo en un salón con ese color rojo!!! La opción clásica sería que el pintor te diga "acabamos la pared de color rojo, luego el baño de verde y en la fase 2 te pinto el salón de otro color"... ridículo, ¿verdad?

La siguiente opción es cuando el pintor está de acuerdo con el cambio de color pero dice que necesita que aumente el presupuesto para comprar pintura nueva y poder efectuar el retrabajo que requerirá de más tiempo. Es una opción válida.

Pero hay una opción más, el pintor pinta el salón de otro color y como el presupuesto es limitado no pinta el baño, porque resulta que el baño tiene poca importancia para ti. Esa es la solución a la pregunta del post, pon el foco en lo que realmente importa y con calidad.

Recordemos que un cliente sabe lo que quiere pero no lo que necesita. Si el Propietario del Producto es quién gestiona el presupuesto, y si su toma de decisiones la basa en el ROI de cada funcionalidad, sabrá perfectamente cuando es el momento de dar por terminado el proyecto/producto.

Aquí os dejo una reflexión:

Un producto que florece no se termina nunca,

simplemente se detiene en momentos interesantes

¿En qué consiste la reunión de revisión de sprint?

El objetivo de la reunión de revisión de sprint, a veces también conocida como demo, es ver de forma informal el incremento construido por el equipo. Se realiza al final del sprint y desde mi punto de vista debería de llamarse revisión de producto ya que en ella se evalúa el producto a través de los incrementos construidos a lo largo de los sprints.

La reunión está dirigida a los interesados, a aquellos que van a utilizar ese producto como herramienta de trabajo en su día a día, ellos son la audiencia principal y directa. Se les enseña todo aquello que tiene valor de negocio y como está alineado con el objetivo del sprint, ven hasta que punto se cumplen sus expectativas, han de sentir "¡Ey!, esto es para mi".

Revisión de sprint demostrando el incremento ante todos los interesados

En la reunión el equipo muestra el resultado final del sprint: terminado, probado y operando en el entorno del cliente, solo se puede considerar como entrega si está desplegado en un entorno propietario de los que van a utilizar el software. Resaltar que están prohibidas las presentaciones gráficas y los "powerpoints”, se trata de un baño de realidad.

Uno de los puntos más importantes de la reunión es que son un punto de aprendizaje y feedback sobre el producto, con cada uno de ellos vemos el progreso y la viabilidad del producto. Como en las demos, en cada reunión se produce la clásica "Carta a los Reyes" de usuarios e interesados, cosa que es deseable ya que se trata de mejoras que pueden aumentar el valor de negocio del producto.

Protocolo de la revisión de sprint - gracias a David Jiménez

Con el feedback obtenido el Propietario del Producto incluirá nuevos elementos en la pila de producto y tratará posibles ajustes en la visión del producto para enfocarse en posibles nuevas oportunidades del mercado.

Protocolo recomendado facilitado por el Scrum Master:

1. El equipo hace una introducción general del sprint exponiendo el objetivo del sprint y la misión del mismo.
2. El equipo presenta las historias de usuario que planificaron, las que han desarrollado, las que no y los impedimentos habidos. Es importante situar las expectativas de los interesados en la realidad al principio de la reunión.
3. El equipo demuestra el funcionamiento de las partes construidas.
4. El Propietario del Producto confirma que el incremento cubre los objetivos planificados en la planificación de sprint. Yo insito a los Propietarios del Producto que acompaño que en este punto reconozcan de forma explícita al equipo el trabajo bien hecho.
5. Se abre un turno de preguntas y sugerencias para tomar feedback de los interesados. Esta parte genera información valiosa para que el Propietario del Producto, y el equipo en general, puedan mejorar la visión del producto.
6. Se definen posibles siguientes pasos para embarcarnos con éxito en la siguiente planificación de sprint.

Al final de la reunión se pueden mostrar las historias técnicas, pero es recomendable hacerlo dirigiéndonos únicamente al público técnico como son el equipo, sistemas y arquitectura y así liberar a los demás de tener que permanecer en la reunión.