¿Por qué se actualizó La Guía de Scrum?

Esta entrada es una adapactión del artículo 2020 Scrum Guide Changes and Updates Explained escrito por el el co-creador de Scrum Jeff Sutherland junto a JJ Sutherland, Avi Schneier, y el equipo Scrum Inc.

Desde su primera publicación en 2010, La Guía de Scrum siempre ha sido un documento vivo. Se usa el empirismo para actualizar periódicamente La Guía de Scrum. Como dice la propia guía:

El empirismo afirma que el conocimiento proviene de la experiencia y de la toma de decisiones con base en lo observado.

Realmente, Scrum no ha cambiado en absoluto, la descripción simplemente mejora a medida que se recibe feedback sobre cómo la gente lo está usando. Iterando para tener un mejor resultado cada vez.

La Guía de Scrum 2020 aborda las malas interpretaciones y los malentendidos comunes que nosotros y muchos otros hemos observado a medida que el uso del framework continúa creciendo.

La Guía de Scrum 2020: Resumen de los cambios

A continuación, se encuentra un resumen de alto nivel de las actualizaciones en la guía:

Lenguaje menos prescriptivo

Con solo 13 páginas, La Guía de Scrum 2020 actualizada es incluso menos prescriptiva que antes, al tiempo que mantiene el estándar de un framework mínimamente viable. El propósito aquí es empoderar a los equipos Scrum y a las organizaciones para que utilicen la guía como fue diseñada; un libro de reglas y no un libro de tácticas. Este enfoque menos prescriptivo conduce a más innovación y adaptaciones en cómo se implementa Scrum mientras se mantiene fiel al framework.

Una guía de Scrum más clara y más universal

Scrum es más fácil cuando los Scrum Teams y organizaciones ven cómo funciona el framework para ellos, sin importar su industria, dominio, producto o función. Es por eso que La Guía de Scrum 2020 actualizada se ha hecho más accesible y comprensible para todos, más allá del negocio de la tecnología.

Los Artefactos de Scrum y sus compromisos respectivos

Cada uno de los tres Artefactos ahora tiene un “compromiso” correspondiente. Existen para aportar transparencia y enfoque frente al cual se puede medir el progreso. El compromiso para el Product Backlog es el Product Goal, el Sprint Backlog tiene el Sprint Goal y el Increment tiene la Definición de Done.

La Guía de Scrum 2020 introduce el concepto de Product Goal para proporcionar un enfoque a largo plazo para el Scrum Team. Cada Sprint debería acercar el producto al Product Goal general. Tanto el Sprint Goal como la Definición de Done estaban en Las Guías de Scrum anteriores. Ahora tienen un hogar y un propósito más claros.

Scrum Master: de ‘Servant Leader’ a ‘A Leader Who Serves’

Sin duda, este cambio tomará a muchos por sorpresa. Pero no se deje engañar, el reordenamiento de estas palabras captura mejor el propósito y las responsabilidades que siempre ha tenido el Scrum Master.

Un solo equipo enfocado en un producto

Las Guías de Scrum anteriores se referían a dos equipos, al “Development Team”, es decir, aquellos que hacían el trabajo y el “Scrum Team”, que incluía al Development Team, así como al Scrum Master y al Product Owner. Este concepto de un equipo separado dentro de otro equipo a veces ha llevado a una relación de “nosotros y ellos” entre el Product Owner y el Development Team. Ahora solo hay un equipo, el Scrum Team, enfocado en el mismo objetivo, con diferentes conjuntos de responsabilidades para el Product Owner, el Scrum Master y los Developers.

Autogestión sobre la autoorganización

Las Guías de Scrum anteriores se referían a los Development Team como autoorganizados, lo que significa que elegían quién realizaba el trabajo y cómo. Con un enfoque más en el Scrum Team, la versión 2020 enfatiza un Scrum Team autogestionado, que elige en qué trabajar, quién lo hará y cómo se hará.

Los tres temas del Sprint Planning

Además de los temas del Sprint Planning relacionados al “Qué” y “Cómo”, La Guía de Scrum 2020 introduce un nuevo tema, “Por qué”, en referencia al Sprint Goal.

Lo que no va más en La Guía de Scrum

Para mantener el estándar de un framework mínimamente viable, se han eliminado algunas cosas de La Guía de Scrum 2020. Esto, sin embargo, no significa que no tengan lugar en Scrum o no deban usarse. Al igual que Yesterday’s Weather y otros Scrum Patterns no incluidos explícitamente en La Guía de Scrum, son prácticas opcionales que pueden ayudar a generar Scrum Teams de alto rendimiento.

Estos son los conceptos principales que ya no se incluyen en La Guía de Scrum 2020 y por qué:

Las tres preguntas respondidas en el Daily Scrum:

Probablemente se las sepa de memoria; ¿Qué hice ayer que ayudó al Equipo de Desarrollo a lograr el Objetivo del Sprint? ¿Qué haré hoy para ayudar al Equipo de Desarrollo a lograr el Objetivo del Sprint? ¿Veo algún impedimento que evite que el Equipo de Desarrollo o yo logremos el Objetivo del Sprint? Aunque eficaces, estas tres preguntas eran demasiado prescriptivas y limitantes. Como dice La Guía de Scrum 2020:

El propósito de la Daily Scrum es inspeccionar el progreso hacia el Objetivo del Sprint y adaptar el Sprint Backlog según sea necesario, ajustando el trabajo planificado entrante.

Hay muchas formas de lograr ese propósito.

“Parking Lot” después de la Daily Scrum

A veces, la Daily Scrum identifica las conversaciones que deben tener lugar luego del timebox de 15 minutos del evento. La guía anterior decía que estas conversaciones, a menudo llamadas “parking lot”, tienen lugar inmediatamente después de la Daily ScrumLa Guía Scrum 2020 le permite al Scrum Team decidir cuándo tienen lugar estas importantes conversaciones.

La palabra “Roles” al momento de describir al Scrum Master, al Product Owner y los Developers

La palabra “Roles” se entendía mal en algunas situaciones. Scrum nunca se ha dedicado a crear una taxonomía de títulos. Los roles nunca tuvieron la intención de ser un título. Lo que importa es definir claramente quién es responsable de qué. Por lo tanto, La Guía de Scrum 2020 incluye este pasaje:

Todo el Scrum Team es responsable de crear un Increment valioso y útil en cada Sprint. Scrum define tres responsabilidades específicas dentro del Scrum Team: los Developers, el Product Owner y el Scrum Master

Este cambio pone el énfasis en lo que corresponde, en responsabilidades específicas. Aún puede referirse a ellos como “roles” si se desea. Pero también se hace énfasis que estos son roles con responsabilidades definidas.

Un Sprint Review dirigida solo por el Product Owner

La guía anterior le dio al Product Owner la iniciativa durante el Sprint Review. El resto del Scrum Team actuó en un papel más de apoyo. La Guía de Scrum 2020 ahora tiene a todo el Scrum Team, junto con los clientes y los stakeholders, en el centro de este Evento.

No hay un equipo dentro de otro equipo

Como se indicó anteriormente, se ha resuelto el concepto de un “Development Team” dentro del Scrum Team.

Lenguaje demasiado prescriptivo para el Sprint Retrospective

La descripción general de este Evento Scrum se ha abreviado para centrarse en lo que es realmente importante: mejoras en los procesos, y la felicidad y cohesión del equipo. Esto le da a los Scrum Teams individuales más flexibilidad en cómo abordan el Sprint Retrospective.

Timebox para el refinamiento del Backlog

La guía anterior decía que “por lo general, no se debe gastar más del 10 por ciento de la capacidad de un equipo” en refinar el Product Backlog. Eliminar el número empodera a los Scrum Teams decidir cuánto tiempo se necesita para refinar y comprender los Ítems del Product Backlog.

Leave a Reply

Your email address will not be published. Required fields are marked *