Los 5+1 valores de equipos Scrum altamente efectivos.

Decía Stephen R. Covey, en su libro “The 7 Habits of Highly Effective People”, que las personas que centran su vida en torno a unos principios sólidos tienen una mayor probabilidad de alcanzar el crecimiento personal e interpersonal y, sencillamente, ser más felices.

Sin embargo, si los principios son el territorio, los valores representan el mapa con el que movernos por ese territorio. Los principios son externos y objetivos, son las leyes naturales que determinan las consecuencias de nuestros actos, mientras que los valores son internos y subjetivos, sirviéndonos de guía para nuestra conducta.

Si extrapolamos esta idea al concepto de equipo parece muy interesante preguntarse cuáles son los valores que pueden convertir a un equipo promedio en un equipo que sepa interpretar la realidad con un buen mapa, que les permita tomar la mejor decisión posible en cada momento y actuar en consecuencia. Así pues, ¿te gustaría conocer qué valores crean equipos altamente efectivos?

La Guía Scrum describe los valores por los que debería guiarse todo equipo Scrum:

Literalmente dice así: “Cuando los valores de compromiso, coraje, foco, franqueza y respeto son encarnados y vividos por el Equipo Scrum, los pilares de Scrum de transparencia, inspección y adaptación cobran vida y construyen confianza para todos.”

Con frecuencia, cuando en las formaciones y charlas describimos el framework Scrum, pasamos muy de puntillas por su sistema de valores, seguramente porque tenemos que contar muchas cosas y muy poco tiempo.

Sin embargo, si tenemos en cuenta que Scrum es un framework ligero, donde muchas decisiones se dejan a cargo del equipo, resulta fundamental contar con un sistema de valores que unifique los comportamientos del equipo de cara a facilitar la transparencia, los procesos de inspección y adaptación, y contribuyan a crear la confianza necesaria tanto en el propio equipo como en su ecosistema (stakeholders, management, comunidad, etc.).

Cito un ejemplo muy ilustrativo, que estoy seguro que cualquier persona que haya hecho una Daily Meeting entenderá.

Hay equipos en los que los miembros del Dev Team se limitan a contestar, de un modo más o menos espontáneo, las tres preguntas que sirven de guía para el evento, aka: ¿qué terminaste ayer?, ¿qué planeas hacer hoy? y ¿qué te bloquea?

Sin embargo, ¿cuántos equipos usan esta reunión para compartir información, colaborar de verdad y replanificar su trabajo de ese día para asegurarse de que todos están enfocados y alineados para avanzar hacia el Sprint Goal?

O, ¿cuántos equipos usan la Daily para identificar un riesgo recién descubierto que puede hacer peligrar el Sprint Goal y poner de manifiesto la necesidad de una replanificación inmediata?

Recordemos que, además de errónea en cuanto al sistema de valores, la daily es errónea directamente por “formato”. Creo que la diferencia entre uno y otro comportamiento estriba en la comprensión y asimilación del sistema de valores sobre el que se apoya Scrum.

Los valores no pueden ser tomados a la ligera por ningún miembro del Scrum Team, desde el Product Owner hasta el último miembro del Dev Team en incorporarse al equipo. Los valores dan orientación y sentido a nuestro trabajo, nuestro comportamiento y nuestras acciones.

Como dice Roy E. Disney: “When your values are clear to you, making decisions become easier”.

5 1 valores que los equipos Scrum deberían desarrollar

1 Compromiso

Este valor ha sido malinterpretado durante mucho tiempo. Muchos lo entendieron como un contrato estricto no escrito por parte del equipo por el que debían completar, sin excepción ni excusa alguna, el Sprint Goal y el alcance acordado.

O peor, el Product Owner tomaba por compromiso la exigencia al Dev Team de hacer todo lo que fuera necesario para completar todo el trabajo planificado, aun a sabiendas del no cumplimiento del DoD (Definition Of Done) y de la consiguiente generación de deuda técnica.

Sin embargo, compromiso significa que cada miembro del equipo Scrum (es decir, todos, incluido Scrum Master y Product Owner) hará el máximo esfuerzo posible y será completamente transparente sobre el progreso del Sprint.

En el mundo del desarrollo software, cualquiera que tenga una mínima experiencia y se haya enfrentado a un proyecto real del mundo real, sabrá que un compromiso cerrado e inviolable en alcance sencillamente es imposible y solo conduce a la frustración.

El matiz es muy importante: en el Sprint Planning el equipo hace una predicción del trabajo que podrá llevar a cabo, no una firma de un contrato con sello lacrado. Compromiso significa dedicación y se refiere a las acciones y el esfuerzo, no al resultado final.

Por ejemplo, podemos jugar a relacionar este valor con uno de los principios universales, la Justicia. Si el Product Owner o un miembro del Dev Team no dedica el suficiente tiempo, energía y voluntad a contribuir a la consecución de los objetivos del equipo, como sí hacen el resto de miembros, ¿sería esta circunstancia justa respecto del resto de integrantes del equipo que sí están comprometidos?

Los miembros de un equipo Scrum se comprometen con los objetivos del equipo y, como dice Gunther Verheyen, con la calidad, con aprender, con ser mejores profesionales, con la transparencia, con auto-organizarse cada vez mejor, con ser proactivos, con la entrega de incrementos, con la inspección y adaptación, con la mejora continua del DoD, con aportar el máximo valor posible al producto que desarrollan, con el propio Scrum como framework, e incluso con el manifiesto Agile y los principios que de él emanan.

2 Foco

“Begin with the end in mind”, proclama Stephen R. Covey como el segundo hábito más importante en su libro “The 7 Habits of Highly Effective People”.

Todos sabemos que el enemigo número uno de la productividad es la multitarea, la dispersión y la falta de concreción en los objetivos que se pretenden alcanzar. Scrum proclama que todos los miembros del equipo deben enfocarse en el trabajo planificado en cada Sprint que, en última instancia, permite cumplir los Sprint Goals.

El equipo debe enfocarse en lo que es más importante ahora, sin preocuparse en exceso por el futuro, que puede ser muy incierto y cambiante. El equipo no debe dedicar tiempo a tareas que puede que no sean necesarias en el futuro, eso sería tirar tiempo y dinero a la basura. YAGNI (You Ain’t Gonna Need It) o KISS (Keep It Simple Stupid) pueden ayudarnos a recordar que debemos mantener el foco.

He hablado con algunos Product Owners preocupados con la dedicación de ciertos miembros de equipos a determinadas tareas que no estaban incluidas en el Sprint (ni habían surgido en las replanificaciones diarias), simplemente porque habían decidido que algo podría ser buena idea o podría necesitarse en el futuro.

Aunque es difícil trazar una línea entre, por ejemplo, lo que evita deuda técnica o aumenta la calidad, y lo que es una pérdida de foco, casi siempre hay que decir tres veces NO a un trabajo o tarea que no está directamente relacionada con alcanzar el Sprint Goal.

Como regla general, lo mejor es siempre hacer el mínimo trabajo posible que me permite cumplir el objetivo.

Foco es centrarse en cumplir el Sprint Goal y, por extensión, en los ítems del Product Backlog que forman parte del Sprint. Si el Sprint Goal está bien definido y los ítems del Product Backlog fueron bien priorizados, entonces el equipo estará trabajando en entregar el máximo valor posible en cada momento. Eso es foco.

3 Franqueza

En realidad la palabra inglesa “openness” puede traducirse como franqueza, sinceridad o actitud abierta y receptiva.

Scrum defiende la transparencia como un pilar básico del empirismo sobre el que se sustenta. Sin transparencia es imposible llevar a cabo la Inspección y la Adaptación. Por tanto, el Dev Team debe ser transparente con el trabajo que realiza, con el progreso del mismo, y con el conocimiento que adquiere (documentación).

El Product Owner debe facilitar el acceso a la información relevante a los stakeholders (Product Backlog, Total Cost of Ownership, etc.). Todos los miembros del equipo deben facilitar la transparencia en las comunicaciones y la compartición de información que facilite la colaboración dentro y fuera del equipo.

No solo lo anterior, el equipo debe estar accesible y disponible para interactuar con los stakeholders (especialmente en este caso, el Product Owner, por razones obvias) o con otros miembros de la comunidad (equipos de arquitectura, de seguridad, etc).

Incluso los miembros del equipo deben estar abiertos a aprender nuevas habilidades o adquirir nuevos conocimientos que les conviertan en multi-funcionales (cross-functional teams). Los miembros del equipo deben tener una actitud abierta y proactiva para mejorar sus capacidades y competencias profesionales, lo que además de contribuir al beneficio del equipo, se traduce en crecimiento personal.

4 Respeto

He de reconocer que la primera vez que leí “respeto” en la Guía Scrum pensé que consistía en ser educado con los miembros del equipo (¡cómo no!). Pero más adelante descubrí que el respeto, tal y como lo entiende Scrum y el mundo Agile, es un concepto fascinante.

Los miembros de un equipo Scrum respetan el conocimiento, las habilidades y la experiencia profesional no solo del resto de miembros del equipo, sino también de aquellas personas con las que se relacionan, sean de su propia organización o de otra.

Los miembros de un equipo Scrum se respetan entre ellos compartiendo información, fomentando un espíritu colaborador, aprendiendo y tomando decisiones juntos. Los miembros de un equipo Scrum se respetan entre ellos comprendiendo sus roles Scrum y la responsabilidad de cada uno dentro del equipo.

Los miembros de un equipo Scrum respetan a los sponsors no desarrollando “features” que nadie va a usar después. Los miembros de un equipo Scrum respetan a los sponsors no gastando dinero en cosas que no aportan valor alguno al producto. Los miembros de un equipo Scrum respetan a los sponsors no dedicando el esfuerzo a tareas que no aportan ningún valor al producto.

Los miembros de un equipo Scrum respetan a los usuarios escuchándolos, mostrando interés por sus problemas y dándoles una solución.

Los miembros de un equipo Scrum respetan a la comunidad no permaneciendo como una isla o una unidad aislada dentro de la organización, sino participando activamente para transferir conocimiento y experiencia.

5 Coraje

El equipo debe tener coraje para hacer lo correcto. Por ejemplo, considerar el cambio como algo necesario para adaptarse a un mundo cambiante, a pesar de que a veces nos obligue a deshacer caminos andados.

Hay que tener coraje para ser capaz de desarrollar el producto sin mirar al futuro más de lo necesario, centrándote en lo que sabemos que es importante ahora, en lugar de en lo que podría (o no) ser importante en el futuro.

El equipo debe tener coraje para resolver los impedimentos que puedan surgir en el camino, anticipando los riesgos, sacando a la luz los problemas y pensando en una solución. Hay que tener coraje para reconocer los errores cometidos, ser transparentes y aprender de los mismos.

El equipo debe tener coraje para mejorar la aplicación de Scrum, identificar los puntos débiles en su ejecución y defender por qué es beneficioso mejorar su práctica.

5 1. Proactividad

Este valor no forma parte de la Guía Scrum, pero lo considero tan fundamental para el trabajo en el seno de un equipo (y para la vida en general) que me gustaría explicarlo en una acepción distinta a la que la mayoría normalmente piensa que se refiere.

La mayoría de las personas piensa que proactividad significa “hacer más cosas”, o yendo algo más allá, “tomar la iniciativa”.

Sin embargo, en un sentido más amplio, proactividad significa, como explica Stephen R. Covey en el libro citado anteriormente, “ser responsable de nuestras decisiones”.

Es decir, nuestro comportamiento depende de nuestras decisiones, no de las condiciones. Si vemos el término “responsabilidad”, del latín responsum, veremos significa “la habilidad de responder”. Lo vemos en la siguiente figura:

Las personas reactivas guían su conducta por sus sentimientos, por las circunstancias o por las condiciones puntuales, mientras que las personas proactivas guían sus decisiones por sus valores, cuidadosamente seleccionados e internalizados.

Para mí este descubrimiento cambió, en cierta medida, mi forma de actuar ante la vida. Por ello, recomiendo a cualquiera interesado en profundizar en el tema la lectura del capítulo uno del mencionado libro de Covey.

Por eso, considero que la proactividad es el valor que cierra el círculo de los valores que debe tener un equipo Scrum altamente efectivo, porque permite filtrar todas las decisiones, comportamientos y acciones del equipo por el sistema de valores de Scrum.

Si conseguimos que los miembros de un equipo Scrum comprendan la importancia de la proactividad, entendida como la capacidad de elegir la respuesta ante un estímulo filtrándola con los valores de Scrum, todas las decisiones que se tomen serán coherentes y estarán alineadas con el framework, y esto es fundamental para el éxito de la ejecución del proyecto.

Conclusiones

En general, cuando explicamos Scrum a los miembros de un equipo u otros interesados, no abordamos con profundidad el sistema de valores sobre el que se apoya.

Los valores de compromiso, foco, franqueza, coraje y respeto ayudan a guiar el comportamiento y la toma de decisiones de un equipo. Al ser un framework ligero, hay muchas decisiones que el equipo debe tomar de manera auto-organizada y para que estas estén alineadas con el framework Scrum deben filtrarse por su sistema de valores.

Aunque Scrum no lo incluye, el valor de la proactividad permite tomar consciencia acerca de cómo responder ante los estímulos que recibe un equipo y decidir, libre y conscientemente, cómo responder, cómo comportarse y cómo actuar.

Para crear un equipo Scrum (incluso no Scrum) altamente efectivo, es vital que los miembros del equipo comprendan e interioricen este sistema de valores.