En 2016, la Guía Scrum fue actualizada para añadir los valores Scrum. No fue una adición baladí, sino la respuesta de sus creadores, Ken Schwaber y Jeff Sutherland, al uso de Scrum de forma deshumanizada, mecanizada, que al final llevaba a la aplicación de los viejos axiomas del taylorismo, convenientemente re-etiquetados con la nueva -cada vez menos nueva- terminología Agile.

El problema es que muchos equipos Scrum ni siquiera saben que estos valores existen y, si ignoramos su existencia, difícilmente podremos aplicarlos. Otras veces, aun conociendo que forman parte de Scrum, no se ponen en práctica, dado su supuesto carácter abstracto o teórico.

Para aplicar los valores Scrum será necesario que el Equipo los haga suyos, que los interiorice y reflexione sobre ellos a medida que avanzamos, Sprint a Sprint.

¿Qué son los valores Scrum?

En general, los valores son un conjunto de convicciones o guías de comportamiento que orientan a los individuos en su toma de decisiones y conducta. Los valores Scrum, por tanto, modulan las decisiones del Equipo Scrum (Scrum Master, Product Owner y desarrolladores), así como sus interacciones.

La guía Scrum propone cinco valores, que son: compromiso, coraje, foco, apertura y respeto. Esto supone añadir un componente ético dentro de Scrum como framework, de modo que tanto este como las prácticas que pueda embeber nunca deben quebrantar tales valores.

¿Cuáles son los valores Scrum?

Como anticipábamos, los valores Scrum son los cinco siguientes.

Coraje (courage). Los miembros del Equipo Scrum tienen la valentía para hacer lo correcto y trabajar en problemas complejos. Sabemos que crear productos que nuestros clientes utilicen y paguen por no es nada fácil, como tampoco lo es hacerlo con un proceso de trabajo ágil. Ante los traspiés, que son oportunidades de mejora, nos levantamos.

No hay coraje cuando hacemos directamente lo que algún cliente o jefe pide, sin tener en cuenta su valor real, o cuando degradamos los valores Scrum o los elementos del framework.

Foco (focus). Los compañeros del Equipo Scrum se centran en el trabajo del Sprint y en la consecución del Objetivo del Sprint, estrechamente conectado con el Product Goal. Scrum nos da un cierto grado de certidumbre en forma de Sprints: nos permite dedicar todos nuestros esfuerzos a una parte del Product Backlog, dejando a un lado, si quiera por un momento, el ruido procedente de un entorno cambiante.

No hay foco cuando ignoramos el Objetivo del Sprint, o cuando carecemos de visión de producto, o cuando nos dejamos llevar por el multitasking y la procrastinación.

Compromiso (commitment). Todos hemos de comprometernos personalmente con lograr el Objetivo del Sprint. El compromiso no se entiende como una suerte de contrato por el cual los desarrolladores han de garantizar la entrega de todos los elementos del Product Backlog que hayan seleccionado para el Sprint, sino con dar lo mejor de nosotros mismos para alcanzar las metas del Equipo. La Guía Scrum 2020 enfatiza el significado de este compromiso, hasta el punto de asociar un compromiso a cada uno de los artefactos.

No hay compromiso cuando falta voluntad de aprender y mejorar, o de ayudar a los compañeros para que, entre todos, entreguemos incrementos de software terminado.  

Respeto (respect). Los integrantes del Equipo Scrum se tratan de una forma adecuada y se tienen en consideración como profesionales capaces y autónomos.

No hay respeto cuando menospreciamos a los demás y a su origen diverso, cuando intentamos imponer nuestras ideas porque sí, o, peor aún, cuando insultamos o elevamos el tono.

Sinceridad, apertura (openness). El Equipo Scrum y los interesados o stakeholders han de ser transparentes en cuanto al trabajo y las vicisitudes que surjan.

No hay apertura si ocultamos información sobre los artefactos, o cuando manipulamos o engañamos a compañeros o stakeholders.

Creación de un entorno de psychological safety

Los valores Scrum deben servirnos para crear un entorno de trabajo de “seguridad psicológica”, en el que los integrantes del Equipo Scrum no tengan miedo a hablar abiertamente sobre equivocaciones y aspectos a mejorar. Un espacio donde la crítica constructiva sea posible y en el que favorezcamos la tensión creativa. El conflicto sano, bien encauzado, es una herramienta de enorme poder. En el vídeo de abajo, Amy Edmondson, profesora de Harvard Business School, comenta su sorpresa al descubrir que los mejores equipos de médicos eran los que reportaban más errores, puesto que tenían una cultura en la que hablaban de los fallos que cometían. Si no hablamos con franqueza sobre los problemas y errores en los que incurrimos, ¿cómo evitaremos que vuelvan a producirse?

Hace algunos años fui parte de un Equipo en el que el grado de confianza y respeto mutuo era tal que, sin traumas ni enfados, podíamos decirnos unos a otros que “tal funcionalidad o código es una mierda” (perdón por el lenguaje, es una expresión literal en este caso; bueno, era en Reino Unido, nos decíamos algo así como “I think that’s a piece of shit”). Seguramente éramos directos en exceso, no estoy defendiendo que utilicemos un lenguaje vulgar o irrespetuoso. Solo digo que, para este Equipo en particular y después de años trabajando juntos, a todos nos importaba que la calidad de los que entregábamos fuera lo más alta posible, y podíamos decir lo que pensábamos con total sinceridad. No nos tomábamos las críticas como algo personal, sino que las asumíamos como parte del oficio y las entendíamos como oportunidades de mejora.

En un Equipo menos maduro, recuerdo como esa misma franqueza por parte de uno de sus miembros era percibida por otros como una actitud negativa. Comentarios semejantes al de arriba causaban desánimo y malestar. El grado de confianza y de qué es tolerable y qué no lo es va a depender de cada Equipo y de la etapa en la que se encuentre.

Cómo poner en práctica los valores Scrum

La Retrospective nos brinda la ocasión perfecta para hablar sobre los valores Scrum y dotarlos de contenido especifico. Solo contrastando los valores con ejemplos y situaciones que se hayan dado durante el Sprint seremos capaces de darles sentido, empezando a obrar en consecuencia. No creo que sea necesario tratar los valores en cada Retrospective, pero sí de vez en cuando, para no perderlos de vista.

Por ejemplo, considera plantear algunas de las siguientes preguntas al Equipo:

– ¿Qué valores de Scrum nos han ayudado especialmente en este Sprint?

– ¿Qué valor Scrum tenemos que trabajar con especial intensidad?

– ¿En qué situaciones nos resulta difícil ser fieles a los valores Scrum?

– ¿Qué sucede cuando dejamos de aplicar alguno de estos valores?

…

Considera también dinámicas como la siguiente:

– Escribe los valores en una pizarra (física o virtual).

– Pide al Equipo que indiquen en post-its ejemplos concretos en los que los valores se vieron reflejados durante el Sprint y en los que, por el contrario, fueron socavados.

– Debate cómo mejorar respecto a cada uno de los valores.

¿Son compatibles los valores Scrum con los valores establecidos en mi organización? 

He tenido la suerte de trabajar en empresas con propósito y guiadas por valores. En Hiyacar, por ejemplo, recuerdo conversaciones con sus fundadores sobre los valores de la organización (“The hiya bond”, que os muestro en la imagen), incluso antes de trabajar con ellos. En este caso, según me contaban, prestaron singular importancia a la definición de esos valores incluso antes de fundar la empresa. Los valores eran parte de su ADN.

En principio, asumiendo “nobleza y bondad” en los valores corporativos, estos deberían ser perfectamente compatibles con los valores Scrum. En otras palabras, el Equipo Scrum debería poder “respirar” y actuar de acuerdo con unos y otros, que se reforzarían mutuamente. Donde se producen conflictos es a la hora de conjugar valores y prácticas empresariales que incentiven el individualismo y no el trabajo en equipo, por no hablar de las rivalidades entre departamentos…

¿Utilizas los valores Scrum? ¿Cómo los pones en práctica?