Analizamos y valoramos los cambios de la Guía Scrum

La Guía de Scrum se ha actualizado el pasado 18 de noviembre. Esta nueva versión ha traído cambios interesantes que me gustaría explorar con vosotros.

Lo primero destacable es que ya no hay 2 equipos, uno dentro de otro. Siguiendo la misma línea que definía el antiguo Equipo de Desarrollo donde no había sub-equipos y sobre todo llevando un paso más allá la filosofía de responsabilidad conjunta, ahora sólo existe el Equipo Scrum donde no hay sub-equipos. Un Equipo de Scrum está compuesto por Desarrolladores, Propietario del Producto y Scrum Master.

Derivado de este cambio pasamos de la autoorganización por parte del antiguo Equipo de Desarrollo a la autogestión por parte del Equipo Scrum. Un equipo autoorganizado decide cómo se organiza para alcanzar el objetivo que le indican que debe hacer. Sin embargo, y tal cómo dice la guía, un equipo autogestionado decide qué hace y cuando se hace además de cómo y quien lo hace. Este cambio es natural dado que es el Propietario de Producto quien decide qué cosas son la que aportan más valor, y por tanto se van a realizar, y cuando se van a hacer, en función de los objetivos que marque para cada Sprint.

También se añade una nueva responsabilidad al Scrum Master, la efectividad del equipo Scrum, incluido Propietario del Producto. En realidad, esta responsabilidad ya estaba implícita en la manera en que ayudaba al equipo entrenándoles para la autoorganización y ser un equipo multifuncional, y al servicio del Propietario del Producto. Pero ahora esta responsabilidad se hace explicita por lo que le quieren dar una relevancia especial dentro de las funciones del Scrum Master.

¿Por qué la Daily ya no tiene preguntas recomendadas? La guía de Scrum es interpretada por muchas personas y si se hace una recomendación, al menos inicialmente, se tratará de seguir dicha recomendación. Por tanto, al tener la guía una recomendación determinista de cómo llevar a cabo este evento, los equipos no buscan su propia forma de planificarse el día. Esto está en contra de la filosofía de Scrum y de la definición de un Framework donde se dice qué cosas hay que hacer y para qué, pero no el cómo. Por tanto, esto le da un poco más de coherencia a la guía.

La definición que se hace de la Retrospectiva también ha cambiado muy ligeramente, la principal diferencia es que ahora no indica que sea obligatorio que la acción acordada tenga que pasar a formar parte del Sprint Backlog, dejando a los equipos autogestionarse.

Los artefactos se ven modificados ya que ahora, cada uno de ellos tiene un compromiso a cumplir:

  1. El Producto Backlog con sus PBIs y su priorización buscan conseguir un objetivo de negocio por parte del producto.
  2. El Sprint Backlog ha de buscar cumplir con el objetivo del Sprint que necesariamente será un paso hacia el objetivo del producto.
  3. El incremento busca cumplir con la Definición de Hecho para asegurar la calidad de cada pieza del producto o servicio entregado.

Sí, ahora un producto tendrá un objetivo a cumplir, algo que consigue focalizar más el trabajo a realizar y que ya estaba incluido en otras guías como en la de Scrum Manager con la visión del Producto. Igual que focalizamos a los desarrolladores con el objetivo del Sprint ahora focalizamos al Equipo Scrum con el objetivo del Producto.

La modificación del Incremento ha supuesto un cambio posiblemente más profundo de lo que pueda parecer, cambia indirectamente la interpretación del Sprint Review permitiendo hacer más hincapié en la inspección y adaptación. En la guía de 2017 en la Sprint Review se presentan los PBI que cumplían con la Definición de Hecho y que formaban parte del único Incremento del Sprint.

Sin embargo, ahora un Sprint tendrá múltiples Incrementos. Cada PBI que cumpla con la Definición de Hecho (DoD) se convierte en un incremento y por tanto se podrá poner a disposición del usuario si el Propietario de Producto así lo considera. Por tanto, en la Sprint Review se presentarán todos los incrementos del Sprint y estos pueden estar o no usándose por los usuarios.

Este en realidad es uno de los grandes cambios que ofrece esta nueva versión de la guía donde no hay que esperar a la Sprint Review para que el incremento, como unidad, pueda ponerse en manos de lo usuarios. En la guía de 2017 no se indica que no se pueda poner en manos de los usuarios un PBI antes de la Sprint Review, sin embargo, era la interpretación habitual. Ahora está de manera más explicita que no es necesario esperar, y por tanto, podremos mejorar nuestro Time to Market.

A consecuencia de este cambio, dado que los elementos ya están aceptados por el Propietario de Producto y es posible que en manos del usuario una presentación de lo que se entrega tiene menos sentido. Esto refuerza el objetivo de la Sprint Review, donde se repasa lo que se ha hecho durante el Sprint en busca de generar una conversación que permita decidir hacia donde debe seguir el desarrollo del producto, es decir, inspeccionar y adaptar.

En conclusión, efectivamente la guía Scrum es ahora menos prescriptiva, además se centra más en el desarrollo de producto focalizándolo sobre objetivos y evita algunas interpretaciones que dilataría el Time to Market. Creo que es un buen paso hacia adelante y refleja el avance en la madurez de las compañías que ya llevan años aplicando métodos ágiles.