Efecto de la nueva Guía de Scrum en XITASO

El 18 de noviembre de 2020 se publicó la nueva versión de la Guía de Scrum, que contiene cambios sustanciales respecto a las adaptaciones anteriores. Nuestro coach ágil, Baptiste Grand, nos informa sobre lo que ha cambiado y sobre el efecto que esto tiene en el trabajo diario en XITASO.

Además de suavizar y modernizar algunos conceptos y secciones, en la nueva Guía de Scrum 2020 también se han eliminado algunos términos y se han atenuado algunas de las especificaciones más estrictas. El objetivo de los cambios está claro para mí. Unas normas menos rígidas amplían el margen del equipo de Scrum para experimentar con sus propios procesos, pues ofrece más autonomía y libertad para «inspeccionar y adaptar». Se trata más bien de que el equipo de Scrum alcance un objetivo común. La nueva Guía de Scrum simplifica buena parte de la complejidad que en su origen procedía del entorno del software. De este modo, Scrum 2020 resulta aún más compatible para los equipos que no provienen del sector de desarrollo de software, como el personal de marketing, ventas o hardware.

En este artículo, abordaremos y describiremos los cambios más importantes.

Scrum 2020. Visión global de los cambios más importantes

  • Se suprime formalmente el equipo de desarrollo.
  • El objetivo del sprint se convierte en un artefacto de Scrum.
  • El objetivo del producto es un nuevo artefacto de Scrum.
  • Scrum se convierte en algo escalable.

Se suprime formalmente el equipo de desarrollo

A primera vista, la supresión del equipo de desarrollo parece un cambio fundamental. Por otro lado, este cambio debe tener el menor impacto posible. Con todo, me llevó algún tiempo comprender este punto de inflexión. ¿Por qué se ha eliminado precisamente el equipo de desarrollo, que es en realidad el corazón y el motor de Scrum? ¿Por qué se tomó esta decisión?

Algunas de las respuestas se encuentran en el Scrum que existía hasta ahora. Puse a prueba numerosos materiales, los conocimientos que había acumulado y mi experiencia, pero al final fue un compañero al que apoyé para que se convirtiera en «maestro profesional de Scrum» (Professional Scrum Master) el que me dio el impulso decisivo.

Porque todo lo que concierne al equipo de desarrollo o lo que puede decirse de este equipo puede decirse igualmente del equipo de Scrum en su conjunto: La autoorganización caracteriza a ambos. El carácter interdisciplinario también. Y lo mismo ocurre con un incremento que cumple con la definición de hecho («done»). Si se observa la siguiente cita, es posible sustituir tranquilamente el término «dev team» (equipo de desarrollo) por «scrum team» (equipo de Scrum), sin que cambie nada en el trabajo diario.

“The Development Team consists of professionals who do the work of delivering a potentially releasable Increment of ‘Done’ product at the end of each Sprint. [..] Only members of the Development Team create the Increment.”

Entonces, si podemos sustituir el término «equipo de desarrollo» por «equipo de Scrum», ¿por qué debemos disponer realmente de un equipo secundario especial solo para el desarrollo? Explicado de forma sencilla, todo lo que se necesita es un equipo de Scrum, formado de manera predeterminada por desarrolladores, un propietario del producto y un maestro de Scrum (Scrum Master).

De este modo, si solo es el término «equipo de desarrollo» el que simplemente desaparece por esta razón, puede considerarse aceptable. Pero, ¿cuál es la repercusión concreta? Por ejemplo, ¿se produce algún cambio en la pila del sprint?

¿Qué significa esto para la pila del sprint?

Simplificando un poco, hasta que se actualizó la Guía de Scrum, el equipo de desarrollo era el propietario de la pila del sprint, que formalmente solo podía ser modificada por el equipo de desarrollo. De la misma manera que la pila de producto («product backlog») es la responsabilidad del propietario del producto.

Esta división se pensó en un principio para evitar perturbaciones. Porque la planificación debía estar en las mejores manos en todas las situaciones para que el equipo de Scrum pudiera desarrollar un incremento «hecho» («done») al final del sprint.

Entonces, ¿qué ocurre ahora con la pila del sprint? ¿Quién se ocupa de la pila cuando se suprime al equipo de desarrollo como propietario? Y, si la propiedad es responsabilidad del equipo de Scrum en su conjunto, ¿cómo se aborda el posible peligro de que los propietarios del producto o los maestros de Scrum interfieran en la pila del sprint para perseguir sus propios intereses?

En este punto, resulta útil recordar que Scrum da más peso a los individuos y a sus interacciones que a los procesos y las herramientas.

“Individuals and interactions over processes and tools!”

Al fin y al cabo, la comunicación ha sido, es y seguirá siendo uno de los criterios decisivos de un equipo de Scrum que pretenda lograr el éxito y evitar perturbaciones.

El objetivo del sprint se convierte en un artefacto de Scrum.

En mi opinión, este cambio supone un avance muy positivo. La capacidad de un equipo de Scrum para organizarse, planificar y alcanzar los objetivos de su sprint es crucial. Un objetivo del sprint crea un enfoque y apoya las decisiones sobre qué hacer, o no hacer, durante un sprint.

Por lo tanto, el equipo Scrum debe preguntarse lo siguiente todos los días: ¿Podemos lograr el objetivo del sprint? En caso negativo, ¿en qué sentido debemos adaptar el plan? El equipo de Scrum no debe tener miedo de eliminar los elementos planificados de la pila de su sprint si esto sirve para llegar al objetivo del sprint. Por esta razón, los temas relativos a la planificación de Scrum se adaptaron en la nueva Guía de Scrum, el objetivo del sprint se convirtió en un artefacto de Scrum y se incluyó la siguiente pregunta: ¿Por qué es valioso este sprint?

Al convertir el objetivo del sprint en un artefacto, la importancia de entregar algo de valor se hace más evidente, por lo que los equipos de Scrum se ven obligados a especificar sus propios objetivos. Además, esto también ayuda al propietario del producto a planificar el futuro o a pensar en cuál podría ser el objetivo del siguiente sprint. O a imaginarse cómo podría ser el objetivo del sprint del próximo año.

El objetivo del producto es un nuevo artefacto de Scrum.

El siguiente logro de la Guía de Scrum 2020 es algo completamente nuevo, a saber, el enfoque en el objetivo del producto. Por un lado, la introducción de objetivos ambiciosos para el producto ayudará a crear una visión del producto y a desarrollar objetivos eficaces para el sprint. Por otro lado, en mi opinión, existe el riesgo de que muchas personas apliquen estos objetivos del producto de forma errónea, por ejemplo, para «embutir» técnicas inapropiadas de gestión de proyectos en el marco de Scrum.

En cualquier caso, la idea que subyace a la introducción de objetivos de productos es buena. Se trata de crear un nivel superior de jerarquía en la definición del producto, es decir, las características o los hitos que el equipo de Scrum quiere alcanzar en los próximos meses o años, o incluso en las próximas décadas. Así, los objetivos del producto deben ayudar a definir los objetivos del sprint que conducen a elementos únicos de la pila de producto. Con la ayuda de los objetivos de producto, es posible planificar, crear una hoja de ruta y hacer que la visión del producto sea totalmente transparente, lo que significa que uno se concentra en el «porqué».

Todos los días, un equipo de Scrum intenta ponerse de acuerdo sobre una visión (del producto), y no sobre la elección de X elementos principales de la pila de producto, donde X encaja con la velocidad del equipo.

En cambio, el equipo de Scrum debe seleccionar cuidadosamente los elementos para alcanzar el objetivo actual del producto. En concreto, los equipos utilizan «epopeyas» en herramientas como Jira. Sin embargo, allí las «epopeyas» se utilizaban con demasiada frecuencia para categorizar diversos elementos de la pila de producto y no se entendían como características esenciales que debían desarrollarse.

Por lo tanto, la inclusión de los objetivos del producto en la Guía de Scrum 2020 debe servir para ayudar a ordenar la pila de producto y a convertir las epopeyas en objetivos del producto claros y transparentes que el equipo de Scrum desea lograr.

Scrum se convierte en algo escalable.

Scrum se diseñó en su origen para ser aplicado por un equipo de Scrum. Un equipo Scrum con un producto, un propietario del producto, un maestro de Scrum, un equipo de desarrollo y un incremento.

No obstante, a medida que los proyectos y las tareas se han vuelto más complejos, ha surgido la necesidad de escalar Scrum para abordar cuestiones más complejas que un solo equipo no puede gestionar o manejar. Hoy en día, existen multitud de marcos que parten exactamente de este punto y prometen el éxito y, de hecho, funcionan más o menos bien en la práctica. A diferencia de estos marcos, Scrum no había satisfecho hasta ahora esta necesidad creciente, hasta que llegó Scrum 2020.

Cuando los equipos de Scrum se hacen demasiado grandes, deben considerar la posibilidad de reorganizarse en equipos de Scrum más cerrados, de manera cada uno de ellos se concentre en el mismo producto. Para ello, deben tener el mismo objetivo de producto, la misma pila de producto y el mismo propietario del producto.

Los cambios en la Guía de Scrum 2020 han aportado más claridad en este punto. Desde la perspectiva meramente formal, ahora es aceptable que varios equipos de Scrum trabajen en el mismo producto, siempre y cuando tengan el mismo objetivo del producto, trabajen en la misma pila de producto y tengan el mismo propietario del producto. No obstante, queda por ver cómo influirá esto en los distintos marcos de trabajo en el nivel de Scrum, pero no hay duda de que es sin duda algo emocionante. Por último, Scrum ya puede escalarse por fin sin tener que recurrir a otros marcos de trabajo.

TL; DR

La Guía de Scrum 2020 incluye algunos cambios. El equipo de desarrollo se ha suprimido formalmente, los objetivos del sprint son ahora un artefacto obligatorio de Scrum y se han incorporado los objetivos del producto.

¿Cómo afectarán estos cambios al trabajo diario? Si Scrum se utiliza en un solo equipo de Scrum, no debería cambiar mucho. Simplemente, el equipo podrá centrarse más que antes en los objetivos de su sprint. Además, es posible revisar la pila de producto para incluir objetivos claros y eficaces para el producto.

Sin embargo, para aquellos que utilizan Scrum con varios equipos de Scrum, la nueva Guía de Scrum será una ayuda definitiva. La adición de los objetivos del producto garantizará que todos los equipos se dirijan en la misma dirección y, al mismo tiempo, permitirá que cada equipo de Scrum tenga la libertad de lograr los propios objetivos de su propio sprint de forma autoorganizada. En definitiva, esta simplificación ayudará a muchos equipos de todo el mundo a realizar su propio escalado sin necesidad de utilizar marcos complicados o engorrosos.

Autores y personas de contacto

¿Tiene preguntas, ideas o comentarios sobre este tema? Póngase en contacto con nosotros.

Baptiste Grand
baptiste.grand@xitaso.com