Decálogo de mis errores con Scrum

¿Quién no ha transformado una empresa o varias ya? ¿Quién no ha cambiado el rumbo de miles de equipos? Sinceramente, yo no… Leí este artículo de Jerónimo Palacios & Associates me he animado a escribir los errores que cometía aplicando Scrum.

Con retrospectiva a mí me ha servido muchísimo para entender dos cosas: no hay que parar de aprender y hay que cuestionárselo todo. Cada vez que he tenido que contarle a alguien mi experiencia siempre digo lo mismo “entré en Paradigma Digital sin saber Scrum y un tiempo después me di cuenta de que no sabía… vi la luz y traté de enseñar a mi entorno para que cambiáramos”. Es curioso que ponen cara de “que mal se está vendiendo” y me hacen la siguiente pregunta “¿Qué hacías mal?”

Personalmente me considero una persona en fase de aprendizaje y lo “mejor” no es que me haya equivocado, es que me voy a seguir equivocando. Toca aprender cada día más, leer mucho, observar más y escuchar lo que otros hacen, opinan o han vivido.

Voy a contar los aspectos de Scrum que entendía mal y cómo me enseñaron en mi camino de aprendizaje.

1. No había leído la guía Scrum

La guía Scrum es la base de Scrum. No es muy larga, o sí, según como se mire, y te explica las reglas de Scrum. Tengamos en cuenta que un Scrum Master debe ser la persona que personifique Scrum, que ayude a implantarlo, que enseñe cómo funciona el framework, además de resolver impedimentos o hacer coaching con el equipo. Durante un curso de Jerónimo Palacios él comentó que había visto Scrum Master con 7 años de experiencia que no se habían leído la guía, en ese momento pensé “pero si no me la he leído…”.

Esto me enseñó a saber elegir bien mis fuentes de aprendizaje. Ya me había leído algunos libros, post e incluso había acudido a charlas pero no había ido a la fuente de mi profesión. Desde entonces he sido muy cuidadoso con las fuentes que he elegido para aprender.

El siguiente paso que dí con respecto a la guía era entenderla. Es una guía “corta” pero tiene una gran fuerza detrás de cada frase y saber entender qué motiva cada práctica y cada elemento es esencial para poder ayudar a un equipo.

2. No hablaba de valor

Siempre hablamos de que el Product Owner maximiza el valor entregado y de que el Development Team se encarga de la entrega de valor en forma de incremento. Lo curioso era que la palabra “valor” no estaba en mi vocabulario. Para mí el Product Owner era solo el experto del negocio que priorizaba.

A raíz de una formación donde la palabra “valor” no paraba de aparecer me di cuenta de que Scrum no es para hacer algo grande a trocitos, es para crear trocitos que generen el máximo valor posible, maximizar la cantidad de trabajo no hecho. Descubrir esto me cambió la perspectiva del uso de Scrum, y permite tener más argumentos para tratar con un cliente que dude. “Scrum no es hacer lo de siempre a trocitos, es generar un valor real e incremental para tu compañia ¿Quieres conocerlo?”.

3. Inspección, Adaptación & Transparencia

Scrum está basado en el empirismo cuyos pilares son Inspección&Adaptación acompañados de Transparencia. La Inspección&Adaptación es la manera de poder reaccionar a entornos complejos, contra lo que Scrum es más efectivo.

Para mí los eventos de Scrum eran reuniones donde se hacían cosas y no momentos donde se inspecciona para aprender y adaptas para reaccionar y poder tomar un mejor camino. No son 3 palabras sueltas, representan una cultura, una manera de enfrentarnos a los problemas complejos.

4. No existía Sprint Goal

Al aplicar Scrum en los equipos, siempre hablaba de que el Development Team fijaba unos puntos comprometidos para un Sprint y de que eso era inamovible. Al final se convertía en poco realista a pesar de que solo fueran dos semanas de desarrollo porque hay incertidumbre y los cambios aparecen.

El concepto de Sprint Goal me cuadraba más con la realidad. Damos una guía al equipo sobre el motivo por el que se hace el Sprint que viene a continuación y además nos ayuda a protegernos de cambios que no estén alineados con el mismo.

El Sprint Goal me parece uno de los conceptos más relevantes porque está alineado con el valor “foco” que promueve Scrum, aquí podéis ampliar sobre ello. 

5. No se admiten cambios durante el Sprint

Este es una de las cosas que más mitificadas tenía en la cabeza. Durante el Sprint el equipo se compromete con un conjunto de puntos, horas o historias y el Product Owner no podía introducir cambios. ¡Nada más lejos de la realidad!

Precisamente el software es complejo, los cambios aparecerán y se pueden abordar. Eso sí, relacionado con el anterior, el Sprint Goal nos permite decidir si un cambio tiene o no sentido. Si el cambio ayuda a conseguir el goal ¡Adelante!, pero si sigue una línea diferente lo podremos descartar.

6. La Daily tenía que ser de pie

Este error quizás no sea el más grave, pero sí el más curioso, común y extendido. Como Scrum Master mantuve una discusión con una compañera porque ella decía que quería estar sentada y yo era muy tozudo con que había que estar de pie. Hacerla de pié no era lo más grave, era mi visión del evento. Para mí era casi un pequeño reporte entre miembros del equipo ¡Nada más lejos de la realidad!.

Ahora con tiempo he visto que la Daily Scrum busca sobre todo estudiar el incremento, el Sprint Goal, es una inspección y adaptación de nuestro Sprint Backlog. Desde fuera parece que la Daily Scrum es similar, sin embargo, el contenido ha cambiado muchísimo. Los equipos en los que he visto que lo han interiorizado cambian su manera de hacerla. Aprenden a tomar decisiones de cara al objetivo que se han marcado.

7. La review era una demo

Cuando había que explicar que era la Sprint Review siempre decía “Es una demo donde el Development Team le va a explicar al Product Owner y a quién invite cómo está el proyecto”.  

Con una visión proyecto donde hacemos algo grande a trocitos tenía sentido, tratábamos de estudiar los últimos trocitos y cómo íbamos. Pero Scrum no va de esto, Scrum es entrega de valor y el objetivo de una Sprint Review es analizar dicho valor.

Labores como revisar el mercado estaban fueran y es una de las partes más relevantes de Scrum, es donde se comprueba si de verdad haces Scrum.  

8. Scrum Master interviene mucho para quitar impedimentos

Que un Scrum Master elimina impedimentos es algo que leemos en cualquier guía o artículo de Scrum. Y es verdad, un Scrum Master ayuda al Scrum Team a eliminar, el problema es cómo lo hace. Cuando explicaba Scrum parecía que el Scrum Master era el chic@ de los recados, encargándose de absolutamente todo.

Un buen Scrum Master deja espacio para que los equipos descubran cómo ser mejores, como aprender y trata de que sean ellos los que se enfrenten a sus impedimentos. Los impedimentos que realmente debe ayudar a eliminar son los organizacionales. Acompañar a la organización para dar pasos en la implantación de Scrum que ayuden al equipo a poder hacerlo y con ello entregar más valor.

9. El Product Owner iba a la retrospectiva si se le invitaba

Al Product Owner siempre se le ve como una figura diferente, es el raro, a veces el propio cliente y por eso parece que no participa de Scrum. Cuando empecé facilitando retrospectivas pensaba que el Product Owner podía o no ir en función de lo que decidiera el resto del equipo.

Sin embargo, Jerónimo me lo recordó “¿Para quien es el evento?”, ¡Es para todos!. Pues por eso el Product Owner debe estar.

10. Darle más importancia a Scrum que a las personas

Este fallo quizás sea el más especial. No es que no le diera la importancia que tiene a las personas, el problema viene porque al tener poca experiencia me centraba mucho en las reglas.

Quizás ahora, con más experiencia y habiendo convivido con muchos equipos, cuando explico Scrum puedo poner más ejemplos de cómo el no cumplir una parte afecta a las personas.

Y tú… ¿Qué errores cometías? ¿Cómo has aprendido de ellos?