Metodologías

Introducción

A principios de febrero de 2021 moderé un debate abierto a todo el que quisiera participar sobre qué hemos cambiado nosotros, nuestras organizaciones y equipos, a raíz de la nueva versión de la Guía de Scrum publicada en noviembre de 2020. Lo que pasó durante ese debate me sorprendió. Apenas estuvimos diez minutos hablando sobre cambios. Las opiniones que escuché, me desconcertaron: “no ha cambiado nada”, “no hay nada disruptivo”, “para equipos experimentados no cambia nada” o “nadie hace caso a la guía y va a seguir así”. Sin embargo, sí existen cambios en la última versión de la guía que obliga a que los equipos cambien su manera de aplicar Scrum. ¿Por qué hay equipos y organizaciones que no lo están aplicando?

La guía de Scrum no es un fin, es un medio para entregar valor a clientes y usuarios de manera continua. Y los cambios que trae la última versión de la guía son una ayuda para facilitar esa entrega de valor. Por eso vale la pena probarlos.

Este artículo es una ayuda para entender los cambios y para ponerlos en marcha y sacarles el máximo partido. Este artículo también te ayuda a descubrir si Scrum no es para ti y no puede aportarte nada. Incluso en ese caso, puedes probar las ideas y técnicas que cuento en las siguientes secciones.

Para aprender los fundamentos de Scrum puedes consultar el siguiente curso Curso de Scrum: Fundamentos y buenas prácticas

Debido a su longitud, este artículo se ha dividido en dos partes.

Los cambios, de manera resumida

Los principales cambios que nos ha traído la versión de la Guía de Scrum de noviembre de 2020 son:

• Desaparece terminología específica de software, para que sea más sencillo utilizarla en otros ámbitos.
• Ya no hay equipo de desarrollo dentro de equipo Scrum. Ahora desarrolladores, Scrum Master y Product Owner forman el equipo Scrum.
• Se incorpora el término Self-Managing (auto-gestionado) en lugar de Self-Organizing (auto-organizado).
• Se incorpora el término “Accountabilities” en lugar de roles “Roles”. Por ejemplo, ya no existe el rol de Product Owner, sino un conjunto de elementos de los que un Product Owner es responsable.
• Se elimina el ejemplo de las 3 preguntas del Daily Scrum que tantas veces y tan mal habían sido mal interpretadas.
• Desaparecen el término “meetings” o reuniones. Ahora, sprint plannig, sprint review, etc. son eventos.
• Desaparece la referencia a celebrar reuniones justo después del “Daily Scrum”.
• Ya no se menciona explícitamente que el Sprint Review sea liderado por el Product Owner.
• Desaparece el Timebox del 10% de la capacidad del equipo para el refinamiento de backlogs de cara a futuros sprints.
• Aparece un nuevo elemento a tener en cuenta, el “Product goal”, que describe un estado futuro del proyecto que sirve como objetivo para los planes del equipo Scrum.
• El evento sprint planning ahora consta de 3 partes en vez de 2. Este evento comienza con: “Why is this Sprint valuable?”
• Presenta tres “commitments” (compromisos) para el equipo Scrum: el product goal, el Sprint goal y la definición de hecho (definition of done).

La versión de 2020 de la Guía de Scrum sólo mantiene el 19,6% del texto de la versión de 2017, todo lo demás se ha escrito de una manera diferente, menos prescriptiva y más clara. Ahora la guía tiene 13 páginas, en lugar de las 19 de la anterior versión.

Algunas de las partes que se han reescrito en más profundidad son todo lo referente al trabajo de Scrum Master y a las retrospectivas. Aunque era algo que ya se había aclarado hace tiempo, ya se indica con claridad que un equipo puede entregar más de un incremento durante el sprint. El término servant-leader, utilizado para definir el trabajo de Scrum Master, se ha cambiado a “true leader who serves”. También desaparece el ejemplo de las tres preguntas o del daily Scrum, aunque puedes seguir usándolas si te funciona. Ahora el Product Owner, el Scrum Master y los developers son parte del mismo equipo, y la guía nos aclara que también participan en la definición de “Definition of Done”, uno de los tres commitments o compromisos que menciona la nueva guía y que vamos a ver con más detalle en este artículo.

Con estos cambios, la guía de 2020 es menos prescriptiva, es decir, te dice menos cosas que debes hacer, pero también es más difícil de poner en marcha, porque tienes que adaptar lo que indica la guía con tu manera de trabajar y no tienes ningún ejemplo para empezar a probar. Por eso hemos escrito este artículo, para darte una ayuda.

Parecen mucho, pero estos cambios son más para seguir profundizando y mejorado lo que ya había en la guía. Quien ya trabaja con Scrum de manera sólida puede incorporar estos cambios fácilmente. Quiénes están empezando con Scrum, o quieren probarlo, encontrarán en estos cambios más ayuda y coherencia para aplicarlo.

Voy a volver a insistir en la necesidad de cambiar. Imagina que usas Scrum y todo te va bien ¿Tienes que cambiar? Sí, rotundo. Y si usas Scrum y no te va bien, con más motivo tienes que cambiar. No existe el Scrum bien ni el Scrum mal. O trabajas siguiendo Scrum o trabajas de una manera que no es Scrum. La propia guía te lo indica: “While implementing only parts of Scrum is possible, the result is not Scrum”.

Si eliges trabajar con Scrum es necesario estar alienado con la guía, por lo que es imprescindible introducir los nuevos cambios. Hay que cambiar con cabeza. A casi nadie le pagan por cumplir al dedillo con la guía de Scrum y tampoco hay utilidad en hacerlo. A la mayoría nos pagan, y la utilidad está, en que nuestros clientes y usuarios reciban valor, por ejemplo, mediante software funcionando. Por eso este artículo te va a ayudar con técnicas, prácticas y algún ejemplo.

He elegido los tres cambios que considero que tienen mayor impacto para verlos con más detalle y darte ideas para aplicarlos. Antes de nada, empieza probando lo que ya conoces. Una técnica o herramienta que no sea la más adecuada, pero con la que tienes experiencia, puede ser mucho mejor, que una herramienta adecuada pero que sea nueva. Scrum es transparencia, inspección y adaptación por lo que no tienes que preocuparte de elegir la mejor opción, solo una que funcione, el propio Scrum ya te empujará a mejorar.

Objetivos (goals) y compromisos (commitments) de Scrum

Los tres commitments de la nueva guía de Scrum son: product goal, sprint goal y definition of done (definición de hecho). De los tres, el product goal aparece por primera vez en la nueva versión de la guía por lo que lo veremos con más detalle más adelante. Los otros dos ya aparecían en versiones anteriores de la guía, aunque no se usaba el término “commitment” para hablar de ellos.

Scrum lleva con nosotros algo más de dos décadas En este tiempo, hemos visto errores y anti-patrones recurrentes al aplicarlo que disminuyen sus beneficios y hacen más difícil el trabajo. Los commitments nos ayuda a corregir uno de estos anti-patrones. Vamos a verlo.

En Scrum, un equipo de desarrollo nunca se compromete a implementar todos los ítems (por ejemplo, historias de usuario) de un sprint. Ni tampoco a cumplir con las estimaciones que hicieron en el sprint planning (en el caso de que aún sigas trabajando con estimaciones). Si, por ejemplo, se obliga al equipo a implementar todos y cada uno de los ítems seleccionados en el sprint planning, entonces no se está aplicando Scrum.

Un equipo, puede implementar todos los ítems, puede implementar menos o puede implementar más, porque su compromiso nunca es con unos ítems concretos, o con una cantidad de ítems, sino con cumplir el sprint goal con la máxima excelencia (y por eso el sprint goal es importante).

Este malentendido ha convertido a Scrum en una herramienta de presión de equipos por parte de managers para trabajar como factorías de funcionalidades, en las cuáles se metían historias de usuario por un lado y salía código fuente por el otro lado. Scrum no tiene nada que ver con esto y, por desgracia, no nos salva de los malos managers.

Scrum no te ayuda si lo que quieres hacer es implementar ítems, o requisitos a toda máquina. Al contrario, aplicar Scrum en este escenario es ponerte palos en tus ruedas. La mayoría de empresas que veo que aplican mal Scrum (incumpliendo la guía, sus principios, etc.) es por esto, porque lo usan para lo que no sirve. Gastan tiempo y dinero en implantar Scrum y luego gastan más tiempo y dinero en romperlo para hacer lo que ellos querían. Poco inteligente, ¿no crees? Volveremos a hablar sobre esto en las conclusiones.

Vamos ahora con el último de los commitments, el definition of done (definición de hecho) o DoD. La definición y papel del DoD no ha cambiado en la última versión de la guía, por lo que si ya lo usabas bien, no es necesario cambiar nada. La nueva versión sí remarca que es necesario cumplir el DoD para considerar que tenemos un incremento de producto y el incremento de producto es lo que tenemos al final de un sprint.

Por esto, es muy importante definir un buen DoD y, en mi opinión, el mejor DoD es el que te evita sorpresas. Es decir, que si algo está terminado, funcione y funcione bien, que si hay que seguir desarrollando, podamos hacerlo sin tener que dedicar semanas a arreglar lo que ya existe.

No existe una técnica específica para definir un DoD. Como es compartido por todo el equipo, y principalmente por los desarrolladores, cualquier técnica de trabajo en grupo es un buen punto de inicio para definir un DoD. Además, al ser el contenido del DoD de carácter técnico, toda la experiencia que el equipo tenga es muy valiosa, por ejemplo, para valorar si se incluye Test-Driven Development, revisiones de código, cobertura de pruebas, pruebas del sistema, métricas de calidad de código, etc. Para aplicar bien Scrum es necesario muy buenos conocimientos técnicos como los que se ven en Curso de Scrum técnico

Para terminar con los commitments, te insisto en que son obligatorios, tanto tenerlos como cumplirlos. Y estos son los únicos compromisos. Ten mucho cuidado si piensas pedir más compromisos además de estos. También existen proyecto en los que es imposible establecer compromisos, por ejemplo, un proyecto cuyo principal objetivo sea entregar una lista de requisitos definidos de antemano en un plazo límite de tiempo. Si no puedes usar el mecanismo de los compromisos, es probable que Scrum no te aporte nada. Aunque puedes encontrar ideas interesantes en Scrum (y en este artículo), yo no te recomendaría gastar energías intentando meter Scrum con calzador, por lo que hemos hablado antes de los palos en las ruedas.

El nuevo product goal

¿Estás haciendo Scrum? ¿Tienes un product goal? Si la respuesta a la segunda pregunta es no, entonces no estás haciendo Scrum. Vamos a ver cómo podemos empezar a trabajar con el product goal, una de las novedades de la última versión de la guía de Scrum.

El product goal define un futuro estado del producto el cuál sirve como objetivo para que todo el equipo trabaje sprint tras sprint para conseguirlo, o acercarse a él lo máximo posible. El product goal no es inamovible. La propia guía indica que se puede ajustar para aprovechar nuevas oportunidades y, yo, personalmente, sospecharía mucho de organizaciones que no hubieran ajustado su product goal a lo largo de varios meses de desarrollo.

No es obligatorio, pero sí muy conveniente, que el product goal sirva de puente para unir los objetivos estratégicos de la organización con el desarrollo de producto. Por ejemplo, y de manera muy simplificada, si tu organización tiene como objetivo crecer un 20% en los próximos tres años, tu product goal puede explicar qué aporta tu producto para conseguir ese objetivo estratégico.

La guía no detalla cuando establecer el product goal, pero como es la referencia para todos los sprints, lo ideal es tenerlo lo antes posible. La guía sí indica que el product goal es desarrollado por el product owner, aunque yo recomiendo que tenga en cuenta lo máximo posible al equipo que va a trabajar para avanzar hacia ese objetivo sprint a sprint. Además, ahora el product backlog debe ser una declaración de intenciones de cómo se va a intentar conseguir (o cómo vamos a acercarnos) al product goal.

Podemos definir product goals de diversas maneras, teniendo en cuenta que nuestra definición debe ayudarnos a preparar los sprints y además, a conocer hasta qué punto estamos cumpliendo el producto goal. Vamos a ver algunas técnicas para definir un product goal.

El product goal es una visión estratégica, es decir, a largo plazo, por lo que técnicas para definir una visión pueden ser de utilidad. Existen varias herramientas para definir una visión, por ejemplo: The Product Canvas, Project Canvas, los talleres Lift-Off de Diana Larsen, o la dinámica de equipos propuesta por Google reWork.

También podemos definir visiones mediante pitches (o discursos breves). Además, técnicas de pitches te facilitan el comunicar el product backlog al resto del equipo e interesados. Por ejemplo, las plantillas más comunes de un elevator pitch ya te indican a quién va dirigido el producto y cuáles son sus puntos fuertes que hay que potenciar.

Si tu organización ya trabaja con KPI (Key Product Indicator), u OKR (Object Key Results), puedes seguir aplicándolos para definir el product goal. Además, también puedes utilizar otras estrategias relacionadas con métricas como la técnica de North Star Metric, o tomar como referencia la Pirate Metric (o métrica AARRR).

También podemos definir un product goal como una respuesta o explicación de cómo el producto que estamos desarrollando va a afectar a muestras métricas de negocio, o KRA (Key Result Areas), como Current Value, Time to Market o Ability to Innovate. También podemos conectarlo con objetivos de negocio a través de Feature Injection, definiendo un product goal que recoja objetivos de negocio (llamados en esta técnica “features”).

Como el product goal es la base para determinar los sprint goals, también son de utilidad las técnicas que te permiten relacionar objetivos a largo y a medio / corto plazo. Por ejemplo, el reciente The Goal Cube (de Jurgen Apello, el creador de Management 3.0), que relaciona Why, What y How, y que cómo veremos más adelante, son las tres fases de un sprint planning. Otras técnicas similares son, por ejemplo, la técnica de Impact Maping que define y relaciona el why, who, what y how de un producto. Esto lo volveremos a ver más adelante en la sección del caso práctico.

Para productos más innovadores, en los que haya elevada incertidumbre y no se pueda apostar por un product goal y un product backlog concreto, puedes utilizar herramientas de experimentación y prototipado, como pueden ser Design Thinking o Sprint Design. Con estas herramientas se pueden realizar uno o varios experimentos, en un plazo de semanas, para encontrar un prototipo validado por usuarios que sirva como base para definir tu product goal.

En proyectos con menos incertidumbre, también puedes utilizar técnicas de lanzamiento de proyectos, como por ejemplo Innovation Games, Agile Inception o su variante Lean Inception, para definir un product goal y un primer conjunto de artefactos con los que comenzar el trabajo.

Las técnicas anteriores tienen la ventaja de que te permite definir goals SMART, es decir, que puedes medirlos y saber en un plazo de tiempo de meses si el desarrollo de producto está acercándote o no a tus objetivos. Puedes encontrar más información de técnicas y prácticas para los goals en Curso de Scrum avanzado.

Más adelante tienes un ejemplo práctico dónde te muestro mi product goal del producto en el que estoy trabajando en el momento de escribir este artículo.

Hasta aquí la primera parte del artículo. En la segunda parte, seguiremos analizando los cambios principales y proponiendo ideas para aplicarlos. También veremos un ejemplo práctico a la hora de trabajar con product goal y la nueva estructura para el evento sprint planning.