Scrum Guide 2020

Scrum Guide 2020

El 18 de noviembre de 2020, Ken Schwaber y Jeff Sutherland lanzaron una versión actualizada de la Guía de Scrum. En este post compartiremos lo más relevante de lo que necesitas saber sobre la Guía Scrum 2020.

En primer lugar, Scrum sigue siendo Scrum.

De eso ya puedes estar tranquilo, por si tenías incertidumbre o preocupación sobre algún cambio drástico que cambiara las reglas del juego de Scrum.

Lo importante de Scrum es que es un marco de trabajo y los equipos Scrum necesitan definir sus procesos, prácticas y herramientas dentro de ese marco. No pretende convertirse en una metodología definitiva o un manual definitivo para abordar sus iniciativas complejas. 

La Guía Scrum no se actualiza con frecuencia (la última actualización fue en Noviembre del 2017). Y cuando se actualiza, Scrum no cambia fundamentalmente. La Guía de Scrum se actualiza para brindar más claridad y abordar los malentendidos comunes .

El cambio más significativo en la Guía Scrum 2020 es la introducción al Product Goal (Objetivo del producto)
El cambio más significativo porque es la adición de algo nuevo (lo que no sucede a menudo en Scrum). Esta es la única novedad introducida en la Guía Scrum 2020.

El Product Goal es parte del Product Backlog. Es un compromiso que ayuda a habilitar el enfoque y una mayor transparencia. Puede pensar que la relación entre el objetivo del producto y la lista de trabajos pendientes del producto es similar a la relación entre el objetivo del Sprint y el trabajo pendiente del Sprint. Tanto el Product Goal como el Sprint Goal ayudan a crear un enfoque y brindan una mayor transparencia hacia el progreso. Simplemente operan en diferentes horizontes de tiempo.

Hay Scrum Teams que han estado utilizando el concepto de objetivos a mediano y largo plazo como parte de sus estrategias de gestión de Product Backlog. Desglosar las cosas en pequeño es esencial cuando tienes grandes iniciativas que abordar. También le ayuda a crear una alineación entre la estrategia y los objetivos de negocio de la organización y la dirección de su producto.

Entonces, aunque esto es nuevo, no se considera revolucionario o disruptivo, sin embargo creo que aportará mucho valor convertirlo en una parte explícita de Scrum.

La forma en que un equipo Scrum usa un objetivo de producto en la práctica depende de ellos decidir, y es algo con lo que probablemente necesitarán experimentar con el tiempo para ver qué funciona mejor para ellos para habilitar los beneficios.

Otro cambio clave en la Guía Scrum 2020 es el cambio de ``Equipo de desarrollo`` a ``Desarrolladores``.
Esta actualización de terminología no debería afectar la implementación real de Scrum y cómo un Equipo Scrum trabaja en conjunto si ya está practicando Scrum Profesional como siempre se pretendió.

Como lo comentamos al principio de este post, Scrum sigue siendo Scrum. Las intenciones originales de los roles de Scrum y cómo funcionan juntos son las mismas. Este cambio ayuda a reducir la confusión y aborda los antipatrones.

Tener un equipo dentro de un equipo era un poco confuso. Cambiar el rol de “Equipo de desarrollo” a “Desarrolladores” ayuda a simplificar.

¿Los Desarrolladores todavía hacen el trabajo de crear un Incremento de valor que cumpla con la Definición de Hecho? ¡Absolutamente!

En relación con este cambio, existe la intención de elevar o poner mayor énfasis en el Scrum Team como una unidad cohesiva con un propósito compartido. De la Guía Scrum 2020, “Todo el equipo Scrum es responsable de crear un Incremento valioso y útil en cada Sprint”. Si bien todavía existen responsabilidades explícitas para el Product Owner, el Scrum Master y los desarrolladores, los tres roles deben trabajar juntos de manera efectiva para tener éxito con Scrum.

Tenemos éxito como equipo y fracasamos como equipo.

Una vez más, esto no es nada nuevo. Siempre ha sido la intención. Pero este cambio de redacción ayuda a abordar las malas interpretaciones y los antipatrones en la forma en que las organizaciones implementan Scrum.

Lo mejor de la Guía Scrum 2020 es que es más clara y concisa de leer.

Una gran parte de la actualización es una mejor organización y claridad en cómo se lee la Guía Scrum. Por ejemplo, siempre ha sido cierto que Sprint Planning aborda el por qué, el qué y el cómo. La reorganización y racionalización lo deja más claro ahora.

Además, se han eliminado las cosas que uno podría considerar prácticas o detalles de implementación. Aquí hay un par de ejemplos:

  • Las tres preguntas del Daily Scrum.
  • Enumerar las actividades que forman parte de Sprint Review.

¿El cambio de terminología de “autoorganización” a “autogestión” significa algo?

Realmente no, si ha estado usando Scrum bien. Estos términos se usan de manera bastante intercambiable en el idioma inglés. Si bien puede profundizar en teorías más complejas sobre estos términos, las actualizaciones de la Guía Scrum no se realizaron en función de una teoría o modelo específico.

El cambio de terminología ayuda a desafiar a las personas a pensar más profundamente y tratar de eliminar algunas malas interpretaciones comunes. Por ejemplo, si existen demasiadas restricciones en la capacidad del Scrum Team para gestionar su trabajo y ofrecer soluciones de alto valor, entonces debemos abordar eso. No solo vivimos con límites que son demasiado restrictivos en Scrum Teams y decimos que está bien porque todavía pueden autoorganizarse. En cambio, trabajamos activamente para eliminar los impedimentos que frenan a los Scrum Teams. Se trata de encontrar el equilibrio adecuado a lo largo del tiempo.

¿Por qué el término “potencialmente liberable” ya no se usa para describir el Incremento?

Esto tiene mucho que ver con hacer que Scrum sea más accesible y más fácil de entender para los equipos que no son de software. Scrum se ha utilizado durante décadas mucho más allá del software y “potencialmente liberable” puede resultar confuso. También es valido indicar “valor utilizable” para describir un Incremento cuando sean equipos que no son de software para definir su producto y crear una Definición de Hecho.

¿Todavía querríamos ser “potencialmente liberables” en cada Sprint si somos un equipo de software?

Probablemente. Supongo que desea una transparencia significativa para el progreso y la calidad. Supongo que quiere gestionar el riesgo.

Pero dado que el contexto de cada persona es diferente (incluso cuando hay software involucrado), el cambio de redacción ayuda a que este concepto sea más accesible y comprensible.

¿Ya no tenemos que planificar al menos una mejora de la Retrospectiva de Sprint anterior en nuestro Backlog de Sprint?

La Guía de Scrum ya no establece esto como una regla. Puede haber ocasiones en las que un equipo Scrum decida no planificar ninguna mejora procesable en un Sprint. La intención detrás de este cambio es dejar de prescribir esta práctica y, en cambio, dejar que el Equipo Scrum decida.

Sin embargo, recuerde que la inspección sin adaptación no tiene sentido.

Si su equipo Scrum no está implementando mejoras, deberían preguntarse por qué no. Es probable que haya algunos problemas subyacentes que abordar. Quizás sus Retrospectivas de Sprint estén apenas rascando la superficie y la gente no esté dispuesta a tener conversaciones difíciles. Tal vez no tenga suficiente transparencia en su proceso para ver oportunidades de mejora. Quizás haya presión para seguir entregando más cosas.

¿Por qué hay compromisos formales para cada artefacto? ¿Significa esto que algo cambia?

El Sprint Goal y la definición de Done siempre han estado en la Scrum Guide. Los cambios realizados son simplemente para reorganizarlos y darles un “hogar” claro con su artefacto asociado. A veces solía haber confusión acerca de que un Sprint Goal y la Definición de Terminado son artefactos separados, y no, no son artefactos separados porque son los aspectos de un artefacto que ayudan a permitir la transparencia adecuada.

El mayor cambio, como se menciono anteriormente es la adición del objetivo del producto (Product Goal) que es parte del Backlog del producto. Entonces, los 3 artefactos tienen un compromiso claro. Ahora es racionalizado y coherente y ayuda a poner énfasis en la importancia de la transparencia para una inspección y adaptación efectivas.

Conclusión

Scrum sigue siendo Scrum

Puedes usar Scrum bien o puedes usar Scrum mal. Creo que la actualización de la Guía Scrum 2020 ayudará a las personas a aplicar Scrum de manera más efectiva en su contexto.

Scrum guide

La Guía Scrum es intencionalmente incompleta.

La guía sigue diciéndote que tienes que hacer más no cómo hacerlo. El como hacerlo son estrategias muy variadas que puedes encontrar en cursos, en otras comunidades de aprendizaje, en libros, en el internet, investigando, aprendiendo de otros, en nuestra sección ¿Qué es Scrum?, por nuestro canal Telegram, etc.

Leave your Comment

Únete a nuestro canal telegram Scrum y DevOps Profesional

Próximos eventos