Los 4 cambios claves en la guía Scrum 2020

Una reflexión sobre cuatro cambios clave en la Guía Scrum 2020, por qué se hicieron y por qué es tan importante.

¿Estás emocionado con la nueva Guía Scrum? Ciertamente lo estamos, aunque solo sea porque cada versión deja más claro de qué se trata realmente Scrum , que también es nuestra misión.

El framework de Scrum, en sí mismo, también está sujeto al empirismo, como lo demuestra la nueva versión de la Guía de Scrum que se publicó el 18 de noviembre. Sus creadores: Ken Schwaber y Jeff Sutherland, utilizan cada incremento para mejorar cómo se describe el framwork de Scrum y qué equipos y las organizaciones deberían centrarse. Como administradores de Scrum.org, ha sido un placer seguir las discusiones previas a este lanzamiento y contribuir con nuestros comentarios.

1. Los equipos Scrum se comprometen con un solo objetivo de producto

Scrum no tiene sentido sin un enfoque en resultados valiosos. Este siempre ha sido el caso. Al mismo tiempo, muchas organizaciones y equipos continúan abordando Scrum desde una perspectiva mecánica que solo se limita al departamento de TI. Prestan más atención a los roles, los eventos y los artefactos que al propósito general del marco Scrum para ofrecer resultados valiosos. Se presta más atención al vehículo de Scrum que a donde se supone que debe llevarte.

“Se presta más atención al vehículo de Scrum que a donde se supone que debe llevarte”.

Es por eso que los objetivos claros y singulares son tan importantes. Los objetivos dan significado y propósito al trabajo de los equipos Scrum. Las metas también brindan enfoque y actúan como piedra de toque en la que basar las decisiones. Esto ya estaba claro en la forma en que Scrum Guide trata los Sprint Goals. Cuando los Equipos Scrum no tienen un solo objetivo para su Sprint actual, el objetivo implícitamente se convierte en “completar todo el trabajo en el Sprint Backlog”. La Guía Scrum nunca pretendió que el Sprint Backlog fuera una selección estática de elementos que, una vez seleccionados durante la Planificación del Sprint, nunca pueden cambiar durante el Sprint. De lo contrario; en trabajos complejos y en entornos complejos, es probable que el alcance de lo que se debe hacer en un Sprint cambie día a día a medida que surgen conocimientos, se descubren problemas y se detectan descuidos. Y sin un objetivo claro y singular para un Sprint, ¿cómo pueden los Equipos Scrum decidir qué es importante y qué no? Sin un objetivo singular, el trabajo complejo será ad-hoc y muy estresante.

Es por eso que la nueva Guía Scrum pone un énfasis aún mayor en objetivos claros y singulares que capturan lo que es valioso sobre el trabajo. Si bien ya incluía un solo “Objetivo de Sprint”, ahora (formalmente) agrega a eso un único “Objetivo de Producto” con el que el Equipo Scrum se compromete.

Para centrarse en lo que va en el Product Backlog y en qué orden, el Equipo Scrum se compromete con un objetivo de producto único, de alto nivel y a largo plazo llamado “Product Goal”. Solo puede haber un “objetivo de producto” a la vez, independientemente de cuántos equipos Scrum trabajen en un producto. Si ese objetivo se logra o se abandona, se formula uno nuevo. Depende de los equipos Scrum y sus partes interesadas descubrir la mejor manera de capturar un objetivo de producto de tal manera que les brinde un enfoque singular en lo que es valioso e importante del trabajo. Obviamente, es probable que el objetivo del producto evolucione a medida que los equipos trabajen para lograrlo; no se pretende que sea un objetivo estático.

Creo que esta es una excelente adición a la Guía Scrum y ayuda a distinguir a los grandes equipos Scrum y los propietarios de productos excelentes, que tienden a trabajar con objetivos claros, de sus contrapartes más mecánicas. También es muy probable que muchos equipos Scrum tengan problemas con este requisito. En muchas organizaciones y entornos, no se comprende el valor de los objetivos compartidos y singulares y su influencia en el enfoque, la moral y el valor. Al enfatizar los objetivos (Sprint Goals y Product Goals) aún más como un requisito, y no como algo bueno, la Guía Scrum puede hacer visibles aún más impedimentos organizacionales.

2. De los roles a las responsabilidades

A lo largo de los años, los roles del marco de Scrum se convirtieron lentamente en títulos de trabajo comunes. Una simple búsqueda en LinkedIn produce cientos de miles de personas con “Scrum Master” o “Product Owner” como su puesto de trabajo. Esta es una victoria en un sentido y una pérdida en otro sentido.

Una observación común, y una que también hacemos, es que el enfoque en los títulos de trabajo a menudo distrae de sus responsabilidades según lo previsto en la Guía Scrum. Muchos Scrum Masters llenan toda su semana con la facilitación de eventos Scrum para sus diversos Equipos Scrum y nada más. Muchos Product Owners completan su semana traduciendo los pedidos de sus partes interesadas en requisitos, sin ningún mandato para tomar decisiones sobre el producto o su estrategia. La dolorosa realidad es que, en realidad, no son Scrum Masters ni Product Owners. Simplemente fingen serlo, por elección propia, porque no conocen nada mejor o porque su organización no les permite hacerlo.

La nueva Guía de Scrum intenta corregir esto refiriéndose a “Responsabilidades” en lugar de “Roles”. Esto enfatiza aún más que el marco de Scrum no es una colección de títulos de trabajo, sino una colección de responsabilidades para desarrollar un producto de manera empírica. No importa si su puesto de trabajo formal es “Scrum Master”, “Project Manager”, “Desarrollador” o “Clown profesional” – si respeta las responsabilidades del Scrum Master, entonces eso es lo que es para el marco de Scrum .

“Esto enfatiza aún más que el marco de Scrum no es una colección de títulos de trabajo, sino una colección de responsabilidades para desarrollar un producto de manera empírica”.

Creo que este es un buen cambio y que enfatiza en qué es lo que los Scrum Masters, Product Owners y Developers deberían dedicar su tiempo. Quizás también nos permite detener las discusiones sobre si un Scrum Master puede o no ser un Desarrollador, o si un Project Manager puede actuar como Product Owner.

3. Tres compromisos para defender el empirismo

La perspectiva mecánica de Scrum que describí anteriormente también resulta en una falta de compromiso. Debido a que se enfoca solo en la mecánica de Scrum (sus roles, eventos y artefactos) y no se preocupa por objetivos claros y singulares, pierde la forma más poderosa de crear cohesión y autonomía dentro y entre equipos que operan en entornos complejos. . Por su propia naturaleza, el trabajo complejo es profundamente impredecible. A pesar de que muchas organizaciones con inclinaciones mecánicas todavía intentan hacerlo, no se puede simplemente entregar a los equipos una lista detallada de especificaciones y esperar un resultado exitoso. Este estilo de gestión de comando y control limita la creatividad, la pericia y la experiencia a las del gerente que decide qué debe hacer quién.

El marco Scrum, en todas sus iteraciones, siempre se ha tratado de permitir que las personas que hacen el trabajo tomen el control de ese trabajo. Esto amplía la creatividad, la pericia y la experiencia potenciales a todos los que están haciendo el trabajo. Este nivel de autonomía requiere, naturalmente, un estilo de gestión completamente diferente. Una forma de crear cohesión en estos entornos de alta autonomía es a través de objetivos claros y singulares que den dirección sin dictar el trabajo en detalle, eso depende de la experiencia de los profesionales.

“El marco de Scrum, en todas sus iteraciones, siempre se ha tratado de permitir que las personas que hacen el trabajo tomen el control de ese trabajo”.

La nueva Guía de Scrum establece tres objetivos, tres compromisos con esos objetivos y tres formas de defender el empirismo, explícito:

1. El equipo Scrum acuerda un solo objetivo de Sprint al comienzo de cada Sprint para guiar el trabajo y las decisiones que deberán tomar durante el Sprint. Las personas que hacen este trabajo, los Desarrolladores, se comprometen a trabajar juntos hacia este objetivo. El trabajo que se necesita para esto se actualiza continuamente y se hace transparente en el Sprint Backlog.
2. El equipo Scrum acuerda un único objetivo de producto para guiar el trabajo y las decisiones que deberán tomar durante el desarrollo de un producto. Este trabajo que es necesario para esto y las decisiones que se toman para actualizarlo se hacen transparentes continuamente en el Product Backlog.
3. El Equipo Scrum acuerda una Definición de Terminado que describe las pautas de calidad a las que se adhieren para entregar Incrementos de alta calidad a sus partes interesadas. Los Desarrolladores se comprometen con estas pautas y las hacen transparentes a través de los Incrementos realizados que entregan.

4. Más breve e incluso menos prescriptivo …

El marco de Scrum es solo eso, un marco. Es necesariamente incompleto porque posiblemente no puede dar cuenta de todos los contextos, todos los entornos y todas las eventualidades donde se utiliza. Esto encaja perfectamente con el trabajo complejo para el que está diseñado; aquí, también, los profesionales tienen la autonomía para completar los detalles según lo que les funcione mejor. En cierto sentido, el marco de Scrum solo establece las metas para un enfoque empírico y confía en la experiencia y la creatividad de los jugadores para decidir cómo jugar mejor el juego.

“El marco de Scrum solo establece las metas para un enfoque empírico y confía en la experiencia y la creatividad de los jugadores para decidir cómo jugar mejor el juego”.

Si echas un vistazo a las versiones anteriores de la Guía de Scrum, es fácil notar cómo la Guía de Scrum se ha vuelto cada vez menos prescriptiva a lo largo de los años. Las versiones anteriores recomendaban prácticas específicas, como gráficos de quemado, preguntas específicas para hacer durante el Daily Scrum y la práctica de permitir que los Scrum Masters faciliten el Daily Scrum. Hemos aprendido que estas prácticas no siempre son útiles. Por lo tanto, la Guía Scrum actualizada continúa la tendencia de ser menos prescriptiva. Ya no se mencionan las tres preguntas durante un Scrum diario, ya no hay un requisito sobre la cantidad de mejoras de una Retrospectiva de Sprint que deberían terminar en un Backlog de Sprint y el lenguaje general se ha suavizado para crear más espacio para soluciones locales.

Los cambios enfatizan que Scrum se ve diferente dependiendo de dónde se use. Lo que funciona para los equipos de software, puede no funcionar bien para los equipos que utilizan Scrum para la investigación científica o el cambio organizacional. ¡Y eso es genial! Una desventaja potencial que vemos de esta abstracción cada vez mayor de situaciones específicas es que una lectura de la Guía de Scrum por sí sola no responderá a todas esas preguntas prácticas. Y aunque estamos totalmente de acuerdo en que no debería ser así, es necesario que nosotros, como comunidad de practicantes de Scrum, demos un paso para apoyar y ayudar a nuestros compañeros a encontrar lo que les funcione mejor. Y que difundimos Liberating Structures por todas partes como una forma de ayudar a los equipos a explorar, inventar e identificar lo que funciona para ellos.

Otros cambios

Además de los cuatro cambios más importantes que abordamos, y lo que revelan sobre lo que importa sobre Scrum, también hay otros cambios que vale la pena mencionar:

• En lugar de “equipos Scrum autoorganizados”, la Guía Scrum ahora usa “equipos Scrum autogestionados” para capturar el alto grado de autonomía que los equipos necesitan para trabajar de manera efectiva en entornos complejos. Casualmente, esta es la misma sugerencia que hacemos en nuestro libro, Zombie Scrum Survival Guide , cuando analizamos cómo la autoorganización y la autogestión son cosas diferentes, y la Guía Scrum debería haber usado “autogestión” en su lugar.
• La Guía Scrum ahora hace explícito que los Equipos Scrum pueden entregar uno o más Incrementos durante un Sprint. En un Sprint, se crea un Incremento en el momento en que se completa un elemento del Product Backlog. Si es posible y lo desea el Product Owner, cada Incremento puede ser entregado a las partes interesadas antes del final del Sprint.
• La Guía Scrum reemplazó el término “Equipo de desarrollo” por, simplemente, “Desarrolladores”. Esto elimina la idea de que haya “otro” equipo dentro del Scrum Team. Para la Guía Scrum, todos los miembros del Equipo Scrum que contribuyen a lograr el Objetivo de Sprint se consideran “Desarrolladores”, independientemente de sus cargos y habilidades. Esto enfatiza aún más que Scrum se trata de las responsabilidades, y no de títulos o roles de trabajo.
• La Guía Scrum ahora enfatiza que el primer paso de Sprint Planning es hablar sobre por qué el Sprint es valioso (para las partes interesadas) en primer lugar. Cuando el propósito es claro, se realiza la selección del trabajo para hacerlo posible, seguido de una descomposición del trabajo durante los primeros días. Esto enfatiza aún más que Scrum se trata de resultados valiosos.
• La Guía de Scrum ya no usa la palabra “reunión” junto con los Eventos de Scrum. Aunque los diversos eventos de Scrum pueden tomar la forma de reuniones formales, puede realizarlas como mejor le convenga. En muchos casos, una reunión tradicional en la que una docena de personas se sientan alrededor de una mesa de conferencias no es probablemente la mejor manera de hacerlo.
• El uso de “Liderazgo de servicio” en la Guía Scrum se ha abandonado en favor de solo “Liderazgo”. El razonamiento aquí es que el “Liderazgo de servicio” es una práctica particular que utilizan los Scrum Masters para apoyar a sus equipos y organizaciones. Si bien entendemos el razonamiento, no estamos completamente de acuerdo con este cambio si somos honestos. No estamos de acuerdo en que el “Liderazgo de servicio” sea simplemente una práctica. En cambio, es una filosofía sobre el liderazgo que se basa profundamente en poner a otros en una posición en la que puedan liderar. Nos preocupa que el “liderazgo” se interprete con demasiada facilidad en términos de las perspectivas tradicionales sobre el liderazgo: dirigir, decir a los demás qué hacer y mandar y controlar.

“Scrum sigue siendo Scrum” fue un mensaje recurrente dentro de Scrum.org. En todo caso, los cambios en la Guía de Scrum están diseñados para dejar más claro qué es importante sobre Scrum y qué no. Si bien puede ser tentador participar en debates profundos (casi teológicos) sobre palabras y frases individuales en la Guía de Scrum, es bueno recordarnos el propósito del marco de Scrum. Existe para ayudar a personas y equipos a resolver problemas complejos. Y debido a que esos problemas y sus soluciones tienden a ser altamente impredecibles, hacen bien en trabajar en pequeños pasos incrementales hacia una meta clara y valiosa, usando cada incremento para verificar si todavía se están moviendo en la dirección correcta. Eso es todo, de verdad. Y la nueva Guía Scrum trae eso a casa incluso mejor que las iteraciones anteriores.

Sin embargo, a pesar de todos sus cambios, una nueva Guía Scrum no resolverá mágicamente todas esas implementaciones defectuosas. Un desafío importante sigue siendo que muchas personas nunca se molestan en leer la Guía de Scrum o hacen un esfuerzo por comprender su propósito. A partir de ahí, es fácil descender a Zombie Scrum. Entonces, esta nueva Guía de Scrum nos presenta, como comunidad, un desafío encantador para encontrar formas novedosas y creativas de difundir el mensaje a aquellos que no lo buscarían por su cuenta. ¡Trabajemos juntos para llevar este mensaje a nuestros gerentes, clientes y partes interesadas!