Mi primer Sprint Con Scrum by Johnny G Kalahan

En noviembre de 2019, asistí a la Conferencia Agile Spain que se celebró en Barcelona. En este tipo de conferencias, se suceden los encuentros casuales entre agilistas. En uno de esos encuentros, se me acercó Jhonny G Kalahan para conversar. Durante la charla, me regaló su libro Mi primer Sprint con Scrum, y le prometí que lo leería y lo analizaría para que le pudiera servir a otros agilistas. 

Una visión general

El libro tiene varias puntos interesantes que me gustaría resaltar. Está enfocado desde un punto de vista didáctico y desde la experiencia de un agilista que se está “pegando” con Scrum. Personalmente, valoro positivamente todos los libros que cuentan experiencias, ya que creo que es una manera eficaz para difundir conocimientos.

La parte, quizás negativa, es que hay algunos fallos con respecto a la guía Scrum. Me contaba Kalahan que debía actualizar varias partes porque el libro se había quedado desfasado. Por tanto, espero que, en cuanto haya una revisión, constituirá un magnífico material. A pesar de este desfase, es buen libro para leer después de haber comprendido bien la guía Scrum. De esta forma, podemos diferenciar las partes en las que el autor habla de su “manera de jugar” y otras, en las que se aproxima a un “Scrum de manual”. Pasemos a analizar las partes interesantes del libro. 

¿Qué es ser Ágil?

Kalahan nos traslada una definición bastante acertada sobre el desarrollo ágil: 

“Ágil no es sinónimo de rapidez o productividad. La rapidez y la alta productividad son el resultado de ser ágil”. 

Para entender esta frase, desglosa la agilidad como la capacidad de aprender y de adaptarnos; de entregas frecuentes y de comunicación constante entre todos los interesados. 

El Product Backlog es un elemento vivo

El autor nos comenta que el Product Backlog es un “objeto viviente”: dependiendo de las circunstancias (el entorno y la evolución del negocio), el Product Backlog crecerá o disminuirá. Por tanto, el Product Backlog debe reflejar todas esas necesidades que puede requerir nuestro producto. Además, nos apunta que el principal criterio a la hora de ordenar el Product Backlog debería ser el retorno de inversión (ROI), aunque siempre entendiendo las necesidades de los stakeholders. 

Sprint Planning y la incertidumbre

La visión de la Sprint Planning que tiene Kalahan es muy acertada. En esta sección, comenta que la comunicación entre Development Team y Product Owner es clave. A veces, el Dev.Team tendrá muchas dudas y necesitará clarificaciones por parte del Product Owner. Otras veces, será el Product Owner el que lanzará preguntas al equipo sobre cómo van a abordar una elemento concreto del Product Backlog. Estas conversaciones, a veces, nos llevan a darnos cuenta de que no hemos entendido bien el objetivo de una funcionalidad concreta. De esta manera, si conseguimos una buena conversación en la Planning, conseguiremos reducir la incertidumbre sobre la entrega del Sprint que acaba de comenzar. 

Reflexiones sobre las estimaciones

Respecto a la estimación, que siempre genera polémica, Kalahan hace algunas reflexiones que me gustaría destacar. Por un lado, el máximo responsable de una estimación debe ser el Development Team, son los que tienen la última palabra. Por otro lado, se recomienda que el Product Owner esté en la estimación, por si hay que clarificar algún elemento. El Scrum Master debe facilitar la sesión y tampoco participa en la estimación. 

Otra de sus reflexiones es que las estimaciones no son exactas, siempre son aproximadas. Cuando un equipo invierte demasiado tiempo en analizar un elemento concreto, y no es capaz de despejar la incertidumbre, es mejor no estimarla porque nos va a llevar a error. 

Historia de Usuario Infinita

En el libro, se nos explica una anécdota que le ocurrió con una Historia de Usuario que no se terminaba. Al parecer, en cada estimación, un desarrollador siempre sacaba la carta de infinito, aludiendo a que no sabría cuándo se acabaría. Además, esta historia acababa los Sprints sin estar terminada, e incluso sin avances. El desarrollador argumentaba que no sabría cuándo acabaría con ella, aún así, durante tres Sprints decidieron incluirla, y no consiguieron acabarla. 

Decidieron que era hora de resolver el problema, y agendaron una reunión. En la reunión, se dieron cuenta de que tenían dependencias con otras áreas que les impedía completarlas. Así que, decidieron ir a hablar con todas las áreas para estudiar el avance de las mismas, y dividieron la historia en otras más pequeñas, unas con dependencias y otras sin dependencias. De esta manera, podrían avanzar en la historia y entregar valor. De esta manera, no necesitaron más la carta de infinito y pudieron avanzar con esta funcionalidad. 

Besos para hacer la Daily Scrum

Kalahan nos narra una historia en la cual una Daily Scrum se estaba complicando demasiado hasta que su Jefe entró en la sala y viendo el “desastre” les dijo, “pero no os compliquéis, solo tenéis que responder a las tres preguntas, keep it simple, stupid”. El principio KISS trata de enseñarnos que no hagamos las cosas más complejas si no es necesario. De hecho, es uno de los principios de Agile. A pesar de que la Daily Scrum se puede hacer de muchas maneras, empezar con las tres preguntas puede ayudar a arrancar a los equipos. 

Además, el autor nos deja un buen resumen para explicar la Daily Scrum: 

“El Daily Scrum no es una reunión de seguimiento, es un espacio donde la transparencia, la inspección y la adaptación convergen diariamente para fomentar la comunicación y el compromiso de equipo. Es un espacio del equipo y para el equipo”. 

Creo que esta es la base de la Daily Scrum. A veces, vemos dos equipos hacer la Daily Scrum de manera similar, pero si entramos en las conversaciones que se generan, hay muchas diferencias. 

Panel de imprevistos: no somos perfectos

A la hora de analizar diferentes radiadores de información que podría tener un equipo, el autor nos propone disponer de un panel de imprevistos.  Este panel contiene todas las historias que aparecen a mitad de Sprint, o aquellas tareas que no pudimos analizar en la Sprint Planning porque teníamos incertidumbre. Tener este panel nos permite detectar y visualizar todo el trabajo que sobrepasa lo que pensamos que seríamos capaces de hacer en el Sprint. 

Estos imprevistos no se deben confundir con los impedimentos, para los que Jhonny Kalahan también propone que los visualicemos. 

El Scrum Master nos lleva a comer pizza

Cuando el autor analizar la Retrospectiva, nos cuenta una historia bastante increíble. Al parecer, estuvo acompañando a un equipo sustituyendo a un Scrum Master anterior. Kalahan  iba probando diferentes dinámicas para conducir la conversación y hacerla productiva. Sin embargo, el equipo se quejaba de que la retrospectiva era “poco dinámica” y que les gustaba más cómo lo hacía el Scrum Master anterior. 

Un día,decide preguntar al equipo para entender mejor qué faltaba. Resultaba que el Scrum Master anterior usaba la retrospectiva como ocio: ir a jugar al billar, a bolos, tomar cervezas o ir a comer pizza. En este apartado del libro, Kalahan hace una reflexión interesante. Según su punto de vista, el Scrum Master anterior usaba la retrospectiva para diversión, pero no para buscar la mejora contínua del equipo. Las actividades de ocio pueden hacer equipo, no obstante, se deben realizar en otro momento. La Sprint Retrospective debe servir para construir un plan de mejora que nos permita trabajar mejor. 

Conclusiones

Lo más interesante de este libro han sido las historias, las experiencias del autor. Es un libro interesante porque no se queda en la teoría, hace análisis y muy buenas reflexiones. Además, es de fácil lectura y el autor consigue que te metas en la historia. Si decidís leerlo, os animo a que le deis feedback, creo que lo acogerá de buen grado.