¿Qué es Valor en Scrum?

El objetivo de Scrum es maximizar valor: un Product Owner se centra en que el equipo genere valor; los Developers se encargan de generar el producto para crear valor; durante la Sprint Planning, hablamos de cómo podemos generar el máximo valor en el Sprint; en la Sprint Review, miramos el valor aportado y aprendemos de él y, en la Retrospectiva, buscamos maneras más efectivas para generar más valor. 

En la guía Scrum, la palabra valor aparece más de 20 veces y, sin embargo, muchos equipos Scrum no han entendido qué significa valor. ¡Respondamos a ello!

¿Qué es valor? 

Hace unos meses, en una formación a un grupo de alumnos en un programa de la Asociación Iberoamericana de Scrum (AIBES)  se les hacía esa pregunta. Había muchas posibles respuestas: 

• Satisfacción del cliente
• Entrega de algo que satisface una necesidad, resuelve un problema o genera beneficio para un usuario
• Proporción entre producto entregado que cumple con Criterios de Aceptación
• Diferencia entre beneficio del producto, satisfacción y coste que paga el usuario. 

Tras analizar las respuestas, les presentamos  el siguiente dibujo para aclarar lo que significa valor en Scrum: 

¡Dinero! El valor es dinero y es en eso en lo que un Scrum Team se debe focalizar para saber si está haciendo un buen trabajo. Puede sonar crudo y frívolo, pero la capacidad de un equipo de generar retorno de inversión debe ser su principal métrica. Ahora bien, vamos a aclarar un par de conceptos sobre “valor igual a dinero”. 

Por un lado, si estamos en una organización sin ánimo de lucro, o bien es un producto que tampoco lo tiene, entonces valor puede ser un beneficio para la sociedad, por tanto, en ese tipo de equipos el valor no es dinero. Sin embargo, la inmensa mayoría de equipos que utilizan actualmente Scrum sí están en organizaciones con ánimo de lucro, a las que les está costando entender por qué Scrum es una ventaja competitiva. 

Por otro lado, es cierto que el valor es dinero, sin embargo, no siempre es tan sencillo de medir. En un caso “Trivial”, como un ecommerce, podemos medir los ingresos y gastos, y entender el valor. Ahora bien, ¿cómo medimos el valor en una aplicación interna que ayuda a una gestión interna por la que no se cobra de manera directa? Para ellop, tendremos que buscar el porqué construimos este producto. 

¿Por qué hacemos este Producto? 

Hace unos años,  en un gran banco, me invitaron, como Agile Coach,  a una reunión con un equipo que quería incorporar Agile y que iba a arrancar. Este equipo había adquirido un software que había que configurar, con una serie de parámetros, para que funcionara como necesitaba el banco. Durante la conversación, me preguntaron: “Javi, ¿ves mejor Kanban al no ser un producto nuevo? En ese momento, les hice la siguiente pregunta: “¿Por qué habéis comprado este software?”. Se hizo un breve  silencio incómodo y me dieron una explicación. Tras la reunión, mi responsable me comentó que no debía cuestionar el motivo por el que se hace un producto, que nuestro trabajo era ayudarles a crearlo. Estaba en desacuerdo, si no tenemos un motivo, un porqué claro, ¿cómo sabemos que estamos construyendo el producto adecuado? 

Por suerte, en la última revisión del marco Scrum, se incluyó el concepto de Product Goal. Este objetivo busca responder a la pregunta: “¿por qué construímos este producto?” Disponer de este artefacto nos permite definir métricas que nos den información sobre el éxito que estamos teniendo. Es un elemento clave para un equipo Scrum. Si no puedes responder a esta pregunta ni tener un Product Goal, entonces Scrum no debería ser tu método de trabajo. 

En Scrum, valor no es “lo que el cliente quiera”

En una ocasión, un responsable me dijo “Para el cliente, el valor es que esté hecho en Navidad”. Debo decir que ese no es el concepto de valor que trabajamos en Scrum.  Valor debe ir asociado a una métrica y debe centrarse en la entrega continua. Podemos tener fechas, pero rara vez el cumplirlas será síntoma de éxito, entre otras cosas porque muchas veces disminuimos la calidad para poder alcanzar dichas fechas. 

También, podemos observar equipos que hablan de “valor” como cantidad de software que entregan. “Tenemos que entregar valor” y no es cierto, porque en ningún caso lo miden. El hecho de entregar un producto no garantiza que sea de valor. Para saberlo, debemos esperar a que las métricas que hemos fijado mejoren y ahí sabremos que realmente es valor. 

Porque hay una verdad que tenemos que interiorizar: valor se demuestra cuando el usuario recibe nuestro producto, antes es teoría. 

• 

¿Por qué nos cuesta hablar de dinero?

Cuando decimos que el valor es dinero, generamos una sensación fría en los equipos. El dinero es algo frívolo en los países latinos, nos cuesta hablar de salarios y de él. Conozco equipos que, si se les pidiera cobrar en base a resultados, dirían que ese no es su cometido, que eso es responsabilidad de la empresa. Curiosamente, en el mundo latino nos cuesta entender que el dinero y centrarnos en la rentabilidad a corto y largo plazo es clave. 

Hace unos años, el CEO de una empresa para la que trabajaba me comentaba que no quería hacer transparente los números porque los empleados iban a interpretar que la empresa iba mal, no iban a entender que había inversiones futuras que funcionarían. De alguna manera, queremos proteger a las personas del valor de su trabajo, que no lo sepan (para bien y para mal). 

Sin embargo, en los países anglosajones parece que tienen más claro la importancia de generar valor en el trabajo, pensar en resultados. Quizás, ese sea el motivo por el que son capaces de construir soluciones y negocio a través del mundo digital, porque se enfocan en los resultados. 

Centrados en valor en Scrum, todo tiene sentido

Si medimos valor, tenemos claro que tenemos que dar resultados y que el objetivo es rentabilizar. Entonces, y sólo entonces, todas las técnicas asociadas a Agile cobran sentido. Por un lado, las historias de usuario funcionan porque necesitamos entender y describir el comportamiento de un customer para entregarle valor. Las métricas de valor, como lead-time o ROI, son necesarias para saber lo que somos capaces de entregar. Las técnicas de calidad, como TDD o Pair Programming, son necesarias para que la entrega de valor se mantenga en el tiempo… ¡Todo tiene sentido! 

Por eso, si tu equipo no mide valor no es un equipo Scrum (y tampoco Agile), si no se centra en los resultados, entonces no se adapta para generar valor, solo para que incorpore “cambios gratis”. 

Y para tí, ¿qué es valor?