¡¡Scrum cumple 25 años!!

Con una nueva versión de la guía...

El 18 de Noviembre de 2020, en un evento retransmitido en directo por internet, los creadores de Scrum (Jeff Sutherland y Ken Schwaber) dieron a conocer la nueva versión de la guía. Una guía más corta que la anterior.

El 30 de agosto, el propio Ken escribió en su blog que la nueva versión iba a tener tan solo 13 páginas (por las 19 de la previa). Yo estaba asombrado de cómo era posible recortar tanto de un marco de trabajo del que apenas había donde recortar. Me habían provocado una impaciencia e incertidumbre por ver el resultado.
Aquí podéis ver el anuncio del que os hablo:  https://kenschwaber.wordpress.com/2020/08/30/scrum-guide-2020/

Una vez que la he tenido en mi mano y he podido ver los cambios, me he sorprendido gratamente por el cambio. Han mejorado algo que era muy difícil mejorar.
Vamos a ver juntos los principales cambios y los vamos a ir valorando uno a uno:

1. Se ha vuelto menos prescriptiva : Ya lo comento en las formaciones. Scrum es un marco de trabajo y dentro del marco podemos hacer lo que nos dé la gana (mientras mantengamos el espíritu del marco y la mentalidad Agile). Lo que han hecho ahora es poner el marco más fino para que tengamos más margen de maniobra. ¿Cómo? Pues suavizando las palabras prescriptivas reduciendo pasos como en el Daily Scrum o en la cancelación de Sprint lo cual nos permite tener más poder de decisión (entre otros).
     Mi opinión : Me gusta que intente alejarse del concepto de metodología. Dependiendo del nivel de madurez del equipo, el SM será el que tenga que proponer distintas pautas o formas de actuar para corregir los distintos problemas que puedan darse, pero ahora con aún más manga ancha.
2. Un equipo, un producto : Desaparece el concepto de Equipo de Desarrollo y los roles. Ahora sólo hay un equipo, el equipo Scrum, con distintas responsabilidades. Ahora el ST lo forman un SM, un PO y Desarrolladores.
   Mi opinión : No terminaba de ver qué se ganaba con el cambio hasta que oí a Jeff Sutherland explicarlo en directo. Yo partía de la base de que el objetivo de todos es el mismo y ahora eso mismo lo remarcan con mayor claridad. Según Jeff anteriormente se podía llegar a producir un "nosotros vs ellos" y aunque estamos todos en el mismo equipo, realmente había un sub-equipo, un grupo separado, una especie de "gueto" en el cual podía llegar a relajarse la responsabilidad de toma de decisiones a tan sólo una persona (el PO). Ahora sigue habiendo distintas responsabilidades pero remarcando que el objetivo de enfocarnos en lo mejor para el producto sigue siendo algo de todos. Es un matiz importante que evita malinterpretaciones y simplifica. ¡Bravo!
3. Product Goal : Aparece el concepto de Objetivo del Producto o Product Goal asociado al Product Backlog. Con esto el equipo podrá siempre poner el foco hacia un objetivo de mayor valor. Cada Sprint el producto irá acercándose a más al Product Goal .
   Mi opinión : Básicamente lo que han hecho es exportar la idea del trabajo del Sprint al producto. En el Sprint, evaluamos día a día si nuestro trabajo se acerca al objetivo del Sprint y hacemos un plan diario para favorecer que nos acerquemos. Ahora hacemos lo mismo pero también a un nivel mayor de tiempo. Sin poner ese objetivo (igual que cuando no se pone objetivo en el Sprint) se dificulta la toma de decisiones y se pierde el foco. Buen añadido.
4. Un lugar para el Sprint Goal, Definition of Done y Product Goal : En las versiones anteriores, aparecía el concepto de Objetivo del Sprint o Sprint Goal y Definición de Hecho o Definition of Done , pero no se les daba identidad. Ahora, los dos que ya existían, más el nuevo aparecen asociados con un artefacto cada uno, de forma que cada artefacto tiene un compromiso: El Product Backlog con el Product Goal, el Sprint Backlog con el Sprint Goal y el Incremento con el Definition of Done.
   Mi opinión : Aquí se está clarificando y simplificando algo que la versión anterior ya tenía. Es verdad que con el Definition of Done muchos alumnos  se preguntan  si es o no un artefacto y si no lo es, ¿por qué no? si es algo que el equipo realmente usa durante el desarrollo. Ahora aclara que cada artefacto tiene un compromiso de transparencia hacia algo y le pone nombre. Además reafirma lo que comento en las formaciones: El DoD va a nivel del PBI que es lo que finalmente va a ser el incremento.
5. Auto-gestión en lugar de auto-organización : En la versión anterior, el equipo de desarrollo se auto organiza decidiendo de forma interna quién y cómo se realiza el trabajo. Dado que el equipo de desarrollo ya no existe, ahora el equipo (el Scrum Team, el único equipo que hay) se auto gestiona, es decir, que ya no sólo decidimos quién y cómo, sino también qué trabajos se van a realizar.
     Mi opinión : Me pasó algo parecido al cambio explicado en el punto 2. No veía la importancia del cambio. Con la auto-gestión deja claro la desaparición del sub-equipo y que todos vamos hacia el mismo objetivo, así que añade a ese nivel de organización el poder de decisión del qué vamos a hacer incluyendo por supuesto a los desarrolladores.
6. Tres temas en el Sprint Planning : En la versión anterior, el Sprint Planning se dividía en dos: Qué vamos a hacer y cómo lo vamos a hacer. Ahora se añade un punto previo para que el equipo hable del por qué (o para qué) vamos a trabajar en el Sprint que comienza.
   Mi opinión : Esto es algo que ya hacían muchísimos equipos. Es muy difícil preparar un buen "qué vamos a hacer" si no sabemos el por qué (o para qué) vamos a hacerlo. Sin embargo aún hay equipos que no lo hacen (principalmente porque están ocultando un Kanban dentro de Scrum o cosas peores que no quiero nombrar). Dejar claro la necesidad de que el equipo conozca el por qué de todo es algo muy positivo y los que me conocéis sabéis de sobra que los "por qué" de todo es fundamental para poder escoger siempre una opción que se acerque más a las necesidades reales de la situación, el producto o el mercado.
7. Simplificación del lenguaje para una mayor audiencia : Se elimina contenido complejo o redundante y cualquier referencia al mundo del software, dejando claro su apuesta multi-sectorial. Con todo ello se ha reducido el contenido hasta las 13 páginas.
     Mi opinión : Vámonos un momento al mundo Lean. Uno de los conceptos de Lean es "eliminar desperdicio". Uno de los puntos del desperdicio es la "documentación superflua". Eliminando contenido complejo y redundante se han acercado más aún, no sólo esos principios de Lean a los que hago referencia, sino también al principio de "Simplicidad" del Agile Manifesto. No por tener más contenido se es mejor. Lo habitual es que sea al contrario y lo han conseguido. Además, ya han abandonado completamente el mundo del software (ejemplo claro de entornos complicados y complejos) para dar cabida a cualquier sector. Me pregunto si cuando actualicen la guía de Nexus (versión actual de 2018) eliminarán todas las referencias al software que ahí sí están usando.
8. Cambios menores: Hay algunos cambios pequeños que también son curiosos:

• Los pilares de Scrum no son útiles si no se usan los tres bien. Esto que explico durante las formaciones, ahora se menciona explícitamente en la guía. No hay Adaptación sin Inspección. No hay Inspección sin Transparencia.
• Al desaparecer el Equipo de Desarrollo, también lo hace el número de integrantes (de 3 a 9). Ahora aparece el tamaño del equipo (el único equipo que hay, el Scrum Team) y el número es de " típicamente 10 o menos ". Ya no se especifica un mínimo y el número de personas que pueden trabajar en tareas del Sprint Backlog suben de 9 a 10 (la guía vuelve a dejar claro en el Daily que tanto el SM como el PO pueden hacer tareas de desarrollo, como ya lo hacía en la versión anterior cuando decía que en el máximo de 9 se contaban al SM y al PO si éstos hacían tareas de desarrollo).
• El SM pasa de ser un "líder-sirviente" como aparecía en la versión anterior, a un "verdadero líder que sirve al equipo y a la organización". En palabras de Jeff Sutherland, se quiere evitar que el SM sea un mero secretario del equipo para dejar claro su importancia real en él. Personalmente me gustaba el concepto de líder-sirviente, pero creo que ahora deja más claro lo que realmente se espera de este un SM. Por ejemplo, en la guía ahora aparece que el SM es el que causa que los impedimentos desaparezcan mientras que en la versión anterior venía que el SM eliminaba los impedimentos. Todo esto refuerza la labor del SM en su empeño en que el equipo crezca a nivel grupal e individual.
• En la versión anterior, se mencionaba que el Daily Scrum se hace en el mismo sitio y misma hora para reducir la complejidad. Ahora se menciona explícitamente que TODOS los eventos se hacen en el mismo sitio y misma hora para reducir la complejidad.
• En la versión de 2016 de la guía había que hacer tres preguntas durante el Daily. En la de 2017 esas preguntas son un ejemplo que se puede hacer. En esta nueva versión desaparecen las preguntas para que cada daily se pueda hacer como mejor se considere dentro de la auto-gestión, siempre que se enfoque en el progreso hacia el objetivo del Sprint y provoquen un plan para su actuación.
• El Sprint Review es uno de los que más recortes tienen a nivel prescriptivo. Deja claro el para qué se hace, pero elimina pasos que había que hacer durante el mismo.

Me daba pánico pensar en los cambios que iban a hacer y que provocara una reducción en el contenido. Una vez evaluado y comprendido, me ha parecido todo un acierto, consiguiendo reduciendo el tamaño de la misma hacerlo más enfocado al objetivo de entregar valor de forma continua. La base es la misma. Scrum sigue siendo Scrum. Pero creo que han mejorado.

He ojeado también la traducción al español. No la he evaluado al completo, pero tiene mejor pinta que la anterior. Han corregido el error de traducción que había en la versión 2017, donde " desapareció " el respecto dentro la lista de valores de Scrum. Sin embargo, en una simple ojeada, he visto un error (grave, a mi parecer) porque cuando indican los cambios principales han indicado el "Development Team" como parte del Scrum Team cuando justo es una de las cosas que han desaparecido...

No os preocupéis demasiado por estos cambios. La base es la misma, la idea es la misma. Si sabéis scrum, vais a seguir sabiendo. Pero si os da miedo qué puede pasar en los exámenes, tranquilos: Hasta el 09/01/2021 todos los exámenes de scrum.org van a seguir estando basados en la guía de 2017. A partir de esa fecha la nueva guía será el foco de las preguntas.

Si queréis ver cómo fue el evento de presentación de la nueva guía, lo tenéis disponible aquí: https://www.scruminc.com/updated-scrum-guide-release/

¿Has visto ya la nueva versión? ¿Qué te ha parecido?

-------------------------------------------------------------------------------------------------------
Edito y me corrijo: Ya he leído la guía en español. Pensaba que tenía mejor pinta, pero tras verla sólo puedo seguir recomendando la original (en inglés). La traducción de la versión 2017 ya era bastante mala, pero la nueva no mejora mucho. Varios ejemplos:

• Cuando se habla del PO y de la gestión del PB, uno de los puntos menciona " Ordering Product Backlog items ", que traducido sería "Ordenar los elementos del PB". Bueno, pues la traducción viene algo tan original (e imposible de entender) como: " Pedido de artículos de trabajo pendiente del producto ". Parece que Google Translator ha tenido bastante peso aquí.
• El SM ayuda al PO entre otras cosas " Helping find techniques for effective Product Goal definition and Product Backlog management ", que traducido sería como "Ayudando a encontrar técnicas para una definición efectiva del Product Goal y la gestión del PB". Su traducción ha sido: " Ayudar a encontrar técnicas para una definición eficaz de los objetivos del producto y la gestiónde los retrasos en el producto ". ¿Retrasos? ¿De dónde sale eso?
• Los nombres de los eventos y roles son nombres propios (vienen en mayúscula siempre) y su traducción podría ser la misma, es decir, podemos hablar en español de Product Owner, Sprint Review o Sprint Backlog sin necesidad de traducirlo. Eso sí, si se traduce debería hacerse medio bien. Cada vez que se traduce el Product Backlog lo hacen como " el trabajo pendiente del producto ". La nueva versión de la guía es más ligera en la versión original, no parece que la española lo haya tenido en cuenta. Mejor no traducirlo y si lo haces deja algo tan sencillo como "pila del producto".
• El peor de todos: El ya comentado " Development Team " en la nueva versión donde ya no existe dicho grupo.