Responsabilidades en Scrum

Responsabilidades en Scrum
Development Team

En la Guía Scrum 2017, las responsabilidades (accountabilities) eran roles. El motivo del cambio es destacar que el equipo Scrum en su conjunto se centra en ofrecer un incremento valioso y útil en todos y cada uno de los Sprint. La idea errónea de que el Scrum Master y el Product Owner estaban separados del equipo de Desarrollo fue perjudicial durante un tiempo y quizás el desencadenante de distorsiones en los límites de la autorganización. Si estamos todos en un equipo, todos somos colectivamente responsables de los éxitos y fracasos.

A nuestro cerebro le encanta la metáfora.

Apoyándonos con la serie Vikings desarrollaremos la metáfora para discutir sobre Scrum y las responsabilidades ágiles dentro del equipo Scrum (Scrum Team).

Las responsabilidades en Scrum son como las posiciones en un barco largo, y el propósito era comerciar o asaltar. La tripulación del barco trabaja en conjunto para llegar a su destino y regresar. El propósito clave de Scrum es construir y entregar un incremento valioso y liberable en cada Sprint. El equipo Scrum trabaja en conjunto para garantizar que lo que construyen en todos y cada uno de los Sprint sea del mayor valor posible para la organización o el propósito al que sirven.

Los roles en Scrum usando una metáfora del gran barco

El Equipo Scrum

El equipo Scrum es un pequeño equipo cohesivo de personas con todas las habilidades necesarias para trabajar hacia la consecución del objetivo del producto. El equipo debe ser lo suficientemente pequeño para poder trabajar en conjunto de manera efectiva y lo suficientemente grande para garantizar que todas las habilidades necesarias estén presentes en el equipo. El Equipo Scrum posee colectivamente la Definición de Terminado (ahora un compromiso), que asegura que el Incremento sea utilizable.

Scrum tiene tres responsabilidades, cada una con un enfoque diferente:

Producto Owner (figura verde)

El qué”. Con un enfoque en el valor, el tiempo de comercialización, el retorno de la inversión (ROI) y el costo total de propiedad (TCO).

Desarrolladores (figuras rojas)

El como”. Concéntrese en construir algo que esté Hecho: que el incremento sea utilizable y potencialmente liberable . El contexto en el que se está construyendo el producto y el dominio del trabajo determinarán las habilidades necesarias.

Scrum Master (figura azul)

Asegúrese de que la empresa y el equipo comprendan y utilicen correctamente el marco de Scrum. Ayudando a todos a comprender cómo utilizar el marco al valor máximo respondiendo a las necesidades del mercado. También apoyarán al Scrum Team para eliminar los impedimentos que están interrumpiendo la capacidad del Scrum Team para lograr su objetivo común.

Existe un entrelazamiento de apoyo entre las tres responsabilidades, y cada responsabilidad crea el entorno y la comprensión para que los demás rindan al máximo de su potencial.

La metáfora del barco vikingo

Una de las características definitorias de la cultura vikinga es el libre albedrío (para las personas libres, desafortunadamente no para los esclavos). El líder proporcionaría una dirección, sin embargo, la posición en sí misma no otorgaría obediencia automáticamente. El Capitán tendría que encontrar una tripulación que esté de acuerdo con la intención del viaje (dónde atacar, comerciar o explorar).

El capitán

Elegiría la dirección y navegaría el barco. Utilizarían su experiencia y comprensión de las condiciones para dirigir el barco hacia la dirección prevista. Era de esperar tormentas y era necesario realizar ajustes constantes como en cualquier navegación.

El capitán tiene la autoridad para dirigir el barco y el deber de cuidar al resto de la tripulación para encontrar el mejor destino para ellos.

En Scrum, este es el Product Owner. El Product Backlog es el timón.

La pandilla

Cuando es necesario, la tripulación maneja los remos y rema el barco, o maneja la vela. Ellos son los responsables de mantener el barco en movimiento hacia y desde el destino.

El capitán tiene la autoridad para dirigir el barco y el deber de cuidar al resto de la tripulación para encontrar el mejor destino para ellos.

En Scrum, estos son los desarrolladores. Están comprometidos a utilizar las herramientas y el entorno a su disposición para ofrecer un incremento constante del producto “Terminado”.

El contramaestre

Quizás esto no sea históricamente exacto, ¡pero ayuda en la metáfora!

Hay alguien que se asegura de que sucedan las cosas correctas en el barco. Ayude a todos a saber cuál es su función, prepare el barco para el clima, cuándo enviar remos y golpear el tambor para remar a tiempo, etc.

El capitán tiene la autoridad para dirigir el barco y el deber de cuidar al resto de la tripulación para encontrar el mejor destino para ellos.

En Scrum, este es el Scrum Master.

Visualizando esto:

  • Sin desarrolladores, no hay progreso.
  • Sin un Product Owner, el viaje carece de dirección y enfoque
  • Sin un Scrum Master, los peligros ocultos pueden detener el viaje
  • Como equipo completo, se llega al destino mediante un esfuerzo concentrado.
Mezcla de roles
Una pregunta recurrente es ¿Puede una persona ocupar varios roles?

Usando la metáfora del barco, podemos discutir el impacto potencial de tener múltiples responsabilidades. Existe la probabilidad de que la persona se concentre en aquello de lo que obtiene más satisfacción, inclinándose hacia las actividades que más le gustan. ¿Irán a donde más se necesitan? ¿Cómo sabrá la gente qué responsabilidad tienen? A veces es más obvio hacia dónde deben dirigirse sus esfuerzos. Es probable que esto interrumpa el buen funcionamiento del equipo. Recuerde que un equipo en funcionamiento y desempeño tiene una dinámica que se caracteriza por las interacciones entre los miembros. No existe una regla fija al respecto, ya que cada situación es única. El efecto común es que ni la rendición de cuentas se cumple con eficacia, o una de las responsabilidades no se atiende en absoluto.

La clave aquí es que haya claridad dentro y fuera del equipo sobre quién tiene la responsabilidad.

Product Owner y desarrollador
¿Quieren conducir o remar?

Probablemente habrá ocasiones en las que el barco no se gobierne mientras están remando, o el barco irá más lento ya que están navegando y no remando.

Product Owner y Scrum Master
¿Quieren tocar el tambor o conducir?

El conflicto de intereses entre los dos roles afecta al equipo y al producto. La tensión natural entre producto y estructura se altera.

Scrum Master y desarrollador
¿Quieren golpear el tambor o remar?

Probablemente habrá ocasiones en las que los remos chocan porque no golpean el tambor, o el barco pierde impulso al tamborilear y no a remar. Puede suceder que el barco se mueva más rápido cuando golpea el tambor. Cuando hay un nuevo miembro del equipo, ¿Quién les ayudará a entender cómo funciona el barco?

Sirviendo a muchos equipos

Cuando se comparte el tiempo entre los equipos, es un desafío ser justo con todos los equipos de manera equitativa. Por lo general, es el equipo que hace más ruido el que llama la atención; puede que no sea el equipo con mayor necesidad. Esto es particularmente notable cuando una organización comienza a escalar su desarrollo de productos.

En la metáfora del drakkar, pasan la mayor parte del tiempo nadando entre barcos, o los barcos tienen que reducir la velocidad para poder subir de un barco a otro.

Cuando golpea la tormenta ...

En la navegación cuando llega la tormenta, necesitas todas las manos a la obra. Debes seguir conduciendo el barco hacia las olas o arriesgarte a volcar. Si una ola lo suficientemente grande golpea desde un lado, te hundes. Todos los miembros de la tripulación deben desempeñar sus funciones de manera eficaz para mantener el barco a flote.

Si seguimos con la metáfora, la tormenta son los eventos inesperados que ocurren en la entrega del producto. Cuando sucede lo inesperado, sin que la gente se comprometa y se concentre en cumplir con sus responsabilidades, entonces lo inesperado puede volcar el producto, poniéndolo fin o desviándolo de su curso.

Donde se rompe la metáfora …

El Product Owner debe confiar en el equipo dentro de un Sprint y dejar que se concentren en lograr el objetivo del Sprint; esto es poco probable en un barco largo.

Los Desarrolladores tienen la libertad de adaptar la arquitectura y la forma del Producto para garantizar que el producto sea utilizable (previamente liberable). ¡Esto no se aborda en esta metáfora! Durante el Sprint, el Product Owner debe permitir que los Desarrolladores se autoorganicen en la forma en que entregan el Sprint Goal.

El Scrum Master adopta un verdadero estilo de liderazgo, al servicio de los desarrolladores, el Product Owner, el equipo Scrum y la organización. Prefieren usar una postura de “Preguntar, no decir”. Sin látigo, sin órdenes.

Leave your Comment