Nov
15
Los 5+1 valores de equipos Scrum altamente efectivos

(Originalmente publicado en el blog de Paradigma Digital)

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”.

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.

Oct
25
Product Owner, ¿interno o del Cliente?

(Originalmente publicado en el blog de Paradigma Digital)

Estos días en Paradigma hay un debate abierto acerca de la figura del Product Owner. Este debate surge por los problemas que existen en algunos equipos cuando el Product Owner no cumple con lo que se espera de él.

En términos de Scrum, el rol de Product Owner tiene unas funciones claramente identificadas y su correcto desempeño es vital para el éxito del Producto. Sin embargo, cuando el Product Owner es del Cliente a veces nos resulta muy complicado conseguir que éste cumpla con lo esperado. ¿Qué hacemos en estos casos? ¿Sería mejor que el Product Owner fuera también de Paradigma?

Para responder esta pregunta, primero hemos de conocer las responsabilidades de un Product Owner de acuerdo a Scrum. Además, deberíamos saber qué cualidades hacen de un Product Owner un Gran Product Owner.

De acuerdo con la Guía Scrum, esencialmente, estas son las tres responsabilidades de un Product Owner:

  1. Es responsable de maximizar el Valor entregado. Para ello, es necesario que el Product Owner:
  1. Conozca el Negocio.
  2. Tenga una Visión del Producto que se quiere construir.
  3. Sea capaz de definir los elementos que crean Valor (aquello por lo que realmente pagan los clientes).
  4. Sea capaz de priorizar estos elementos de acuerdo a esta sencilla regla: primero (siempre que las dependencias lo permitan)  los elementos de máximo Valor al mínimo Coste. La mayoría de Productos que conozco se desarrollan para ganar dinero, cuanto más y antes, mejor.

 

  1. El Product Owner debe asegurarse de que existe un Product Backlog que recoge dichos elementos, y de que están priorizados. ¿Significa esto que es el Product Owner la persona que debe escribirlos físicamente? La respuesta es “No”. Si él no lo hace, puede delegar en otras personas para que lo hagan: stakeholders u otros miembros del Dev Team (analistas, UX, etc.) si así se organiza el equipo. Pero el responsable y la persona que responde ante terceros del mismo es el Product Owner. Por ello, si él no los escribe o no los detalla al nivel requerido, sí debe participar en su definición y descripción, debe guiar a las personas que los escriben, participar en los Refinamientos y velar por que siempre se priorice el máximo Valor al mínimo Coste.

 

  1. El Product Owner debe liderar el Sprint Planning y el Sprint Review, y tiene que participar activamente en el Sprint Retrospective.
  1. En el Sprint Planning, el Product Owner debe definir el Sprint Goal y los elementos del Product Backlog que permiten alcanzar dicho objetivo. El Product Owner debe ayudar al Dev Team a comprender dichos elementos del Product Backlog, explicándolos con suficiente nivel de detalle y respondiendo las preguntas que formule el Dev Team. El Product Owner también debe estar dispuesto a negociar el alcance del Sprint si este excede la capacidad del equipo para ese Sprint.
  2. En el Sprint Review, el Product Owner también debe liderar la reunión y esto es fundamental. Tiene que invitar a los stakeholders clave para explicarles qué elementos del Product Backlog han sido completados y cuáles no. Asimismo, debe comentar el estado del Product Backlog, recoger el feedback obtenido durante la revisión del Incremento, cruzar esta información con el estado actual del mercado, y actualizar el Product Backlog para que este feedback sea valioso de cara al siguiente Sprint Planning.
  3. Por último, en la Retrospectiva, el Product Owner debe participar activamente como un miembro más del Scrum Team para inspeccionar las personas y sus relaciones, los procesos y las herramientas de cara a trazar un plan, unas acciones, que mejoren el trabajo del equipo.

Por tanto, comencemos con algo básico y evidente: si un Product Owner no cumple con estas responsabilidades, bien por falta de tiempo, capacidad o compromiso, entonces no puede ser Product Owner. O dicho de otro modo, el cumplimeinto de estas responsabilidades es condición necesaria para poder ser Product Owner. En caso contrario, existirá una disfunción que, en última instancia, acabará lastrando el desarrollo del Producto y frustrando a todo el equipo.

A continuación, enumeramos las cualidades y habilidades que debería tener un Product Owner para ser un Gran Product Owner:

  • Conocedor del Negocio.
  • Capacidad de decisión.
  • Disponibilidad.
  • Orientado al Valor.
  • Saber cómo funciona el desarrollo software.
  • Comprometido con el equipo.
  • Buen comunicador.
  • Conseguidor.
  • Capacidad de resolución de conflictos.
  • Deseo por mejorar su entendimiento y aplicación de Scrum.
  • Gestionar expectativas.
  • Confiar en el equipo y en el framework.

Una vez que conocemos las principales responsabilidades de un Product Owner y qué cualidades hacen de él un Gran Product Owner, estamos en condiciones de responder a la pregunta que formulamos al comienzo, ¿Product Owner interno o del Cliente?.

En mi opinión, siempre que el Cliente pueda ofrecer un Product Owner y éste se comprometa con las responsabilidades del rol -lo que, además, implica conocimiento del Negocio y dedicación- será mejor opción que un Product Owner interno. No obstante, si el Product Owner propuesto por el Cliente no se compromete, o no cumple con lo esperado durante el desarrollo del Producto, entonces habría que buscar otra persona para desempeñar el rol, bien otra persona del Cliente o bien interno.

Un Product Owner del Cliente, en la mayoría de casos, tendrá más conocimiento del Negocio, “su” Negocio, y esto es fundamental para maximizar el Valor y saber priorizar. Además, lo normal es que tenga mayor capacidad de influencia dentro de las distintas áreas o departamentos de “su” organización, lo que es de enorme ayuda para resolver dependencias y agilizar integraciones. Me atrevería a decir que en Paradigma sabemos resolver cualquier problema técnico y esto nunca supone un bloqueo de un desarrollo, pero: ¿qué ocurre con las dependencias cruzadas y las integraciones con otros productos de la organización? Aquí necesitamos toda la ayuda posible para lograr influenciar y movilizar a las personas adecuadas y un Product Owner del Cliente puede abrirnos las puertas que necesitamos abrir.

Otro aspecto a considerar es la responsabilidad final sobre el Producto desarrollado. Si el Product Owner es del Cliente y el Producto no ofrece el Valor esperado, la responsabilidad es del Product Owner, pues es él quien decide y prioriza los elementos del Product Backlog. Este no es precisamente un tema menor a la hora de elegir entre un Product Owner interno o del Cliente ya que, sin un profundo conocimiento del Negocio, existe un riesgo mayor.

Entre las ventajas de un Product Owner interno estarían su dedicación, su compromiso con el equipo y su conocimiento de Scrum. Sin duda, un Product Owner interno cumplirá con todas las responsabilidades del rol y facilitará el equilibrio de todo el equipo. Sin embargo, es más complicado que conozca el Negocio, la organización, los stakeholders, los contactos e incluso que tenga capacidad de decisión, lo que es fundamental. Es difícil que su opinión sea respetada y acatada dentro de la organización si no forma parte de ella, al menos hasta que se establezca una gran relación de confianza.

Otro punto a considerar, es el carácter de la relación que se establece entre el Cliente y Paradigma. Si queremos facilitar esta relación, es decir, que sea más integrada, un equipo mixto formado por el Cliente y Paradigma facilitará la transparencia y aumentará la cohesión entre ambos. La transparencia es un pilar básico de Scrum, la apertura del trabajo que hace el equipo genera confianza y esto es básico para evitar futuras fricciones.

Conclusión

Aunque cada caso requiere un estudio particular, siempre que el Cliente cuente con un Product Owner que se comprometa con las responsabilidades del rol (e incluso esté dispuesto a pasar evaluaciones por parte del equipo), pueda dedicar el tiempo necesario y conozca el Negocio, será la opción con mayor probabilidad de éxito. Además, es el Cliente quien asume la responsabilidad del Valor generado, lo cual tiene pleno sentido puesto que, al fin y al cabo, el Cliente es el promotor del Producto.

Sin embargo, hay casos en los que esto no es posible, por diversas razones. Entonces podemos contar con Product Owner internos que, sin duda, aportarán muchas otras ventajas, como la implicación, el compromiso, la total dedicación y el profundo conocimiento de Scrum.

En cualquier caso, habrá que estudiar cada situación para tomar la mejor decisión en un contexto específico ya que, el desarrollo de Productos no es, ni nunca será, una Ciencia Exacta.