Metodologías

Continúanos con la segunda parte del artículo. Vamos a seguir desmenuzando los cambios principales de la Guía de Scrum de noviembre de 2020, proponiendo maneras para implementarlos y viendo un caso práctico real.

La diferencia entre self-organised y self-managed

¿Es este un simple cambio de palabras o hay algo más detrás? Vamos a verlo.

La principal diferencia entre auto-organización (self-organization) y auto-gestión (self-management) es la libertad del equipo. Como la propia Guía de Scrum dice, un equipo auto-organizado tiene libertad para decir cómo convertir un ítem en un incremento del producto. Un equipo auto-organizado, además tiene libertad para decidir qué es lo más importante en un momento determinado para poner el foco en ello.

Te pongo un ejemplo y un contraejemplo. Supongamos, de manera muy simplificada, un sprint goal definido como “obtener entre 100 y 1000 usuarios nuevos mediante recomendaciones de usuarios ya existentes”. Tenemos ítems en el product backlog como: “publicar anuncios en las cuentas de redes sociales de los usuarios”, “ofrecer un desciendo a un usuario que traiga a un amigo”, etc.

Un equipo “self-organised” tomaría el ítem “ofrecer un descuento a un usuario que traiga un amigo” y buscaría la mejor manera de implementarlo, por ejemplo, a través de enlaces personalizados que reciban en un correo ya preparado para que lo puedan reenviar a sus amistades, definiendo las interfaces de usuario que considere más adecuadas, etc.

Un equipo “self-managed”, además de lo anterior, podría hablar entre ellos y descubrir que el mecanismo que más les ha hecho a ellos entrar en sistemas por recomendación de otras amistades ha sido las conversaciones con sus amistades. Por ese motivo deciden trabajar en un ítem que no estaba en el product backlog para que los usuarios puedan ver en qué les ha ayudado usar la aplicación, para que tengan cosas que contar en redes sociales a sus amistades.

Un equipo ni “self-organised” ni “self-managed”, podría recibir unos prototipos de pantalla de alta fidelidad que tendría que implementar tal y cómo están definidos.

Si un equipo ya es auto-organizado (pero de verdad), el cambio a auto-gestionado suele ser sencillo y orgánico. En cambio, la auto-organización o auto-gestión desde cero es difícil de conseguir. Se necesita el apoyo de la organización a varios niveles, y una gestión de todos los elementos de Scrum: eventos, product backlog, goals, etc. encaminadas a ello.

El problema principal que yo veo es que, a pesar de la popularidad de Scrum, muy pocos equipos realmente funcionan de manera auto-organizada. Sin embargo, Scrum necesita crear equipos “self-managed” o no es Scrum. Pocos managers y organizaciones he conocido que confíen en sus equipos lo suficiente para dejarles que, al menos, se auto-organicen. Tampoco podemos afirmar de manera general que auto-organización es mejor que auto-gestión o mejor que no tener ninguna. Pero si tu organización funciona bien, y quiere seguir funcionando con equipos no “self-organized” entonces Scrum no es para tu organización.

Crear equipos auto-gestionados desde cero es un trabajo de largo recorrido. No lo vamos a solucionar aplicando ninguna técnica, ni las anteriores ni otras, aunque técnicas de cambio continuo, como Lean Change Management ayudan.

Como conclusión, no pidas proactividad, no pidas un compromiso con el sprint goal, no le pidas a tu equipo que decidan ellos cómo hacer las cosas, si no estás ofreciendo auténtica auto-organización a cambio, porque no funciona. Sería como pedirle a un corredor que gane una carrera cuando le has atado los pies.

Por qué este sprint importa (o planning WWH)

WWH son las siglas de Why (por qué), What (qué) y How (cómo), que son las tres preguntas que respondemos en cada una de las tres fases del sprint planning. En la primera, nos planteamos por qué o para qué hacemos el sprint, es decir, qué valor aporta el incremento de producto que estamos planificando. La respuesta a esta pregunta es el sprint goal. En la segunda, planteamos qué hemos de hacer para conseguir dicho objetivo. Los más habitual es acudir al product backlog y elegir el conjunto de ítems que más pude hacer cumplir el sprint goal. En la tercera y última, es dónde los desarrolladores hablan del trabajo necesario para convertir esos ítems en un incremento del producto que funcione y construyen su sprint backlog.

Recuerda que el commitment o compromiso de todo el equipo con el sprint es con el sprint goal, no con los ítems seleccionados para el sprint ni con el sprint backlog. El equipo se compromete a trabajar en el sprint goal por encima de implementar los ítems seleccionados. Es más práctico definir sprint goals (y cualquier objetivo / “goal”) que no sean binarios. Si tu sprint goal es binario, podría pasar que el equipo haya realizado el 99.9% del trabajo y no hayas conseguido alcanzar el sprint goal. Cuanto más flexible y gradual sea el sprint, más podrás aprovechar los resultados. Veremos esto con más detalle un poco más adelante en el caso práctico. Vamos a ver ahora algunas ideas para definir sprint goals.

El sprint goal es un objetivo a corto plazo, solo dura el tiempo que dure el sprint, por lo que puedes utilizar cualquiera de las técnicas que hemos mencionado para el product goal que encajen en este corto periodo de tiempo. Por ejemplo, la métrica pirata probablemente no sea útil ya que necesita información durante un período de tiempo más largo de lo que dura un sprint, al igual que OKRs.

El sprint goal se puede ver como acotar el alcance durante un sprint, por lo que cualquier técnica de alcance, por ejemplo establecer una visión común para las dos, tres o cuatro semanas, puede ayudarnos. También podemos definir esta visión utilizando dinámicas de grupo como los 9 por qué u otras “Liberating Structures”.

También son útiles técnicas que relacionan las preguntas WWH, y que ya hemos mencionado al hablar del product goal, como impact maping,

Por último, también podemos tener en nuestra caja de herramientas técnicas para visualizar cuál es la parte más relevante del product backlog, por ejemplo, un backlog con estructura piramidal o, si utilizamos story mapping, hacer diferentes líneas para indicar las releases o versiones del producto, sin olvidar tener siempre claro qué queremos conseguir implementado ese conjunto de ítems.

Un caso práctico

Para entender mejor el product goal, la nueva estructura del sprint planning y el compromiso, te voy a contar un caso real en el que participo.

En este mismo blog hemos hablado de qué factores hacen eficaces a un equipo de desarrollo Factores básicos para conseguir equipos efectivos. Como parte de ese trabajo, yo y otros compañeros del mismo grupo de investigación de la Universidad de Sevilla estamos desarrollando una aplicación web llamada Team Radar, para encuestar a equipos y calcular el valor de estos factores. Nuestra misión es no solo conocer el nivel de efectividad de un equipo, sino poder definir actividades para aumentar su eficacia, conocer cómo afectan estas acciones a la eficacia y valorar el impacto de eventos externos, como altas, bajas, teletrabajo, etc. en el equipo.

Para alcanzar nuestra misión, necesitamos convencer a managers y equipos de que empiecen a usar Team Radar y continúen usándola de amanera periódica, por ejemplo, una vez al mes.

Actualmente, nuestro grupo de investigación cuenta con 6 equipos candidatos a usar Team Radar y, entre todos ellos, suman 22 personas. Algunos de los equipos son muy pequeños, 2 personas y un manager, y otro llegan hasta las 5 personas.

Con estos datos anteriores, hemos aplicado una técnica llamada Impact Mapping para crear un mapa mental que muestre el why (por qué), who (quién), what (qué) y how (cómo) de la aplicación Team Radar.

El product goal que hemos definido es: tener 88 encuestas en Team Radar en el plazo de 6 meses (con una media de referencia de 11 encuestas por mes). En otras palabras, queremos conseguir que los 6 equipos candidatos no solo se animen a utilizar Team Radar, sino que repitan varias veces en un plazo de 6 meses. Después, nos plantearemos si la herramienta está madura y aporta el suficiente valor para abrirla a que la pueda usar quien quiera.

Nuestro product goal es SMART (Specific, Measurable, Assignable/ Achievable, Realistic, Time-related). Podemos medir si lo hemos conseguido o no, con el número y la media de encuestas. Es alcanzable y realista porque, con 22 personas, el máximo número de encuestas que podemos conseguir es de 22 cada mes y 132 a los 6 meses (nuestro objetivo es 88 encuestas, es decir dos tercios). Está acotado en el tiempo ya que nos lo planteamos a 6 meses. Además, no es un objetivo binario. Podemos no conseguirlo, pero, por ejemplo, haber recogido 80 encuestas con lo que probablemente consideraríamos que ha sido un éxito.

Para lograr nuestro product goal, desarrollamos Team Radar mediante sprints y cada sprint tiene su objetivo o sprint goal. Como parte de nuestro impact mapping hemos definidos entre 3 y 5 objetivos para nuestros sprint, y los revisamos y actualizamos periódicamente.

Vamos a ver ahora cómo planteamos el sprint planning. Recuerda que este evento se divide en tres partes: Why o por qué este sprint aporta valor, What o qué vamos a hacer y How, o cómo vamos a hacerla.

En la parte Why de nuestro sprint planning traemos los goals que tenemos en el impact mapping (lo que tenemos que hacer (o what) para conseguir nuestro objetivo (o why)). Algunos ejemplos de posibles sprint goals son:

• Ofrecer más información en los resultados de las encuestas.
• Facilitar el uso a quién no lo ha utilizado nunca.

Nuestros sprint goals están expresados de manera que indiquen que un grupo de usuarios pueden realizar algo con la aplicación. Los revisamos e intentamos identificar cuál es el que más puede acercarnos en ese momento a nuestro product goal. Por ejemplo, ¿mejoramos los informes? ¿ampliamos las encuestas? ¿Hacemos que la aplicación sea más sencilla de usar? Si aún nadie trabaja con la herramienta puede que lo que nosotros pensamos que más acerque a nuestro product goal sea hacer que Team Radar sea lo más sencillo de usar posible, pero si ya hay equipos que han realizado las encuestas un mes, podemos pensar que lo que más puede acercarnos a nuestro product goal es mejorar los informes para que se va la evolución del equipo mes a mes.

En este caso nuestros sprint goals no son objetivos SMART, no son medibles ni específicos, aunque sí acotados en el tiempo. Nuestros sprint goal son apuestas, o una hipótesis que nos lleva a desarrollar un incremento del producto para ver si nos acercamos al product goal. Hasta pasadas unas semanas no tenemos información que lo confirme o no. Por esto, para medir el sprint goal, medimos el product goal, si ha mejorado, ese sprint nos ha aportado valor.

Una vez que tenemos el Why, pasamos a la parte What y vemos qué vamos a hacer en el sprint. Repasamos los ítems de la parte How del impact mapping que, en nuestro caso funciona de product backlog. Dejamos la puerta abierta a añadir nuevos ítems que encajen en el sprint goal. Algunos ejemplos de ítems son:

• Implementar un test que permita analizar en mayor detalle la seguridad sicológica.
• Exportar los datos de las evaluaciones a formato Excel.
• El manager puede incluir información sobre lo que ha pasado desde la encuesta anterior.

Como ves, no usamos historias de usuario, ni ningún otro tipo de formalismo.

Como hemos visto a lo largo de este artículo, nuestro compromiso es con el sprint goal, no con los ítems del sprint. Por ejemplo, si nuestro sprint goal es: “Los participantes tendrán información sobre cómo ha evolucionado el equipo a partir de las encuestas de varios meses”, lo que esperamos al final es tener un incremento de producto que permita hacer lo anterior de la mejor manera que los desarrolladores hayan sido capaces de idear durante ese sprint. No nos importa si han hecho un ítem, diez o cien, tampoco nos importa si han hecho los ítems que hemos seleccionado en el sprint, o han descubierto ítems más prometedores y han trabajado en ellos. En otras palabras, el número concreto de ítems implementados en un sprint no es relevante para nosotros. Si vemos que podemos hacer 5 y al final hemos hecho 3, no habría ningún problema. Ya se verá con el tiempo si esos 3 ítems nos acercan o no al product goal y tomaremos decisiones en el futuro en base a eso. Si el experimento falla, y los resultados del sprint goal no nos acercan a nuestro product goal, lo que hemos hecho no nos ha servido, por lo que nos aporta valor no centrarnos en el número de ítems. Entendemos que esta manera de trabajar encaja con un equipo self-management y es cómo podemos obtener el máximo valor.

La última parte del sprint goal es el How, o cómo estará hecho el trabajo de este sprint. En esta última parte nos centramos en hablar de cómo se van a implementar los ítems, principalmente para ver si tenemos la capacidad de hacerlos o si necesitamos formación o hacer una demo técnica con alguna librería o similar. Esta parte del sprint planning también nos sirve para hacer una estimación muy poco detallada para comprobar si pensamos que hay tiempo durante el sprint para realizar los suficientes ítems (sea cuál sea ese número) para que lleguemos a cumplido el objetivo del sprint. Si no, con los ítems que pensamos que podremos hacer, ajustamos el sprint goal para que tenga un alcance más pequeño. En otras palabras, fijamos el tiempo y encajamos ahí lo que pensamos que podremos hacer, en lugar del aplicar el famoso anti-patrón de gestión de proyectos consistente en fijar el alcance y dedicar todas las horas extra necesarias para cumplirlo.

Los ítems seleccionados en la última parte del sprint, el How, no son un commitment o compromiso, porque los desarrolladores tienen total libertad para implementar los ítems de una manera diferente a lo que se ha hablado en el sprint planning, si así lo deciden los desarrolladores.

Esta manera de trabajar nos funciona. Puede que Team Radar tenga éxito o no, pero con esta manera de trabajar minimizamos el desperdicio (código que luego no sirve para nada porque nadie usa esa funcionalidad) y nos centramos en buscar qué podemos poner en la aplicación para que nuestros equipos vean valor en usar Team Radar. Scrum te permite trabajar de muchas otras maneras diferentes por lo que no tienes que seguir este ejemplo al pie de la letra.

Conclusiones

En este artículo hemos visto que la versión de noviembre de 2020 de la Guía de Scrum incorpora cambios que hay que aplicar si queremos seguir estando alineados con Scrum. Si ahora tu Scrum es igual que varios meses atrás, algo haces mal porque el núcleo de Scrum es transparencia, inspección y adaptación, para mejorar constantemente la manera de trabajar. Los cambios en la guía apoyan estos pilares.

En este artículo también hemos mencionado varias técnicas y prácticas que te facilitan estos cambios. Scrum es muy flexible y como hemos visto, se puede poner en marcha con enfoques y técnicas diferentes para que puedas adaptarlo a tu realidad. Aprovecha esa flexibilidad y adapta Scrum a tu organización, no tu organización a Scrum.

Hemos insistido a lo largo de este artículo en que, para aplicar Scrum, y ver si te funciona o no, hay que aplicar todo lo que viene en la guía, incluidos los nuevos cambios. No es fácil y la mayoría de equipos y organizaciones son lo consiguen, pero quedarse a medias es la manera más sencilla y rápida de que Scrum no te funcione. Si lo aplicas, adaptando todo lo que dice la guía, Scrum podrá o no funcionarte, pero si no, Scrum seguro que no te funcionará, y la culpa será tuya, no de Scrum.

Si no quieres o no puedes hacer todo lo que indica al guía de Scrum, incluyendo los cambios de la última versión que hemos repasado, es que Scrum no es para ti. No tiene sentido forzar a seguir Scrum, por ejemplo, cuando:

• No puedes establecer los commitments, por ejemplo, porque nos e pueda identificar un único product goal o sprint backlog, o porque los compromisos cambien con mucha rapidez.
• El product backlog esté definido de antemano y está recogido en el contrato.
• Tu sprint goal es siempre: implementar el siguiente paquete de funcionalidad (porque nos lo pide el cliente).
• No puedes tener equipos “self-managed”, ni siquiera “self-organized”, de los de verdad.
• Realmente, tu problema no es complejo.

Scrum no es una herramienta para todo el mundo o para cualquier proyecto. Si a ti no te aporta valor no tiene sentido forzarte a utilizarla. Además, puedes aplicar los elementos de Scrum que te aporten valor de manera individual. Por ejemplo, trabajar en sprints o tener un DoD, y utilizar los mecanismos de transparencia, inspección y adaptación del propio Scrum para ir mejorando esa manera de trabajar.

Este ha sido el artículo que más me ha costado escribir por la cantidad de cosas diferentes de las que podía hablar. Al final he hecho la selección que me ha parecido más interesante, que ha sido repasar los cambios principales, técnicas y prácticas para el product goal y el sprint goal, y un caso práctico basado en mi propia experiencia. Si tienes curiosidad e interés por ver otras cosas que se ha quedado en el intento, mándanos tus opiniones a mí mismo o a OpenWebinars para preparar nuevos artículos.