Scrum y el Poder de Decisión.

Introducción.

Toda empresa, no importa su tamaño, se precia de tener un organigrama. Este es un sketch que podés leerlo de abajo hacia arriba (aunque también podés leerlo de arriba hacia abajo), en donde podés ver quién reporta a quién, quién te evaluará a medio año y a fin de año, y quién puede tomar tal o cual tipo de decisiones. La pregunta que aparece, cuando en la conversación dónde se habla de cómo organizar la empresa usando el marco de trabajo Scrum es: ¿Quién está arriba de quién en el organigrama?

¿Quién es quién en Scrum?

Observando la Scrum Guide, solamente se mencionan tres roles, a saber: Product Owner, Scrum Master y Developer. El resto de los roles que uno puede ver en empresas medianas y grandes, comunmente, como el rol de Product Manager, son agregados cuando se usan otros marcos de trabajo ágil junto a Scrum.

Básicamente, el rol del Product Owner es el de maximizar el valor de los entregables que el cliente desea, lo cual hace mediante el ordenamiento de cada una de las historias de usuario. Y ese ordenamiento encima no lo hace el Product Owner, si no que está realizado por el cliente y es el PO el que lo hace reflejar en el Product Backlog.

El Scrum Master es el que guía al equipo a que éste incorpore las buenas prácticas que se mencionan en la Guía a fin de poder ser un verdadero "equipo ágil". Aquí también sucede lo mismo que con el Product Owner, el cual está supeditado a lo que el cliente considere como prioritario, pero en el caso del Scrum Master, éste está supeditado a la Guía Scrum.

Los developers son los que crean los entregables. La única decisión que pueden tomar es cómo llevar a cabo esos entregables (eso incluye la calidad, los tests, las tecnologías a utilizar). En verdad, dentro de los roles del marco de trabajo ágil, son los que tienen más libertad para tomar decisiones.

¿Quién toma las decisiones entonces?

En Scrum hay dos decisiones ha tomar:

  • ¿Qué se hace?
  • ¿Cómo lo hacemos?

De la sección anterior, queda claro que la primera la hace el cliente. Es quién mejor sabe qué es lo que quiere, la prioridad que tiene entre las demás cosas que desea, y cuándo lo quiere. Y con respecto a la segunda pregunta, la respuesta es que los developers son lo que deciden cómo hacer los entregables; ellos son los que conocen las tecnologías y cómo aplicarlas para poder crear los entregables que el usuario quiere tener.

¿Y todo esto como se relaciona con el organigrama?

Al comienzo del artículo hablé del organigrama y lo definí suscintamente como el sketch de las relaciones de poder (o toma de decisiones) que existen en una empresa. Si uno intenta hacer algo parecido a un organigrama en una compañía que usa Scrum, éste se reduciría a:

No hay texto alternativo para esta imagen
Relaciones entre los roles en Scrum y también con el cliente.

Digo algo parecido, porque en ningún organigrama se incluye al cliente como parte del mismo.

Sacando al cliente del sketch de más arriba, se puede observar que no hay una jerarquía en Scrum. Ésta es la explicación por qué se habla de roles, y no de posiciones. Nadie tiene poder de decisión sobre los otros. Otras preguntas que surgen, a partir de este sketch, son:

  • ¿Y el CEO?
  • ¿Y la CIO?
  • ¿Y los demás?

Aquéllas son posiciones dentro de la compañía, y se ha visto que no hay posiciones en Scrum, hay roles.

Conclusiones.

  • El "organigrama" de un equipo Scrum pone en pie de igualdad a cada uno de los roles dentro del marco de trabajo,
  • cada uno de los roles tiene responsabilidades que le son inherentes al rol. No los puede compartir (aunque si pedir sugerencias si hay dudas con respecto a un tema en particular),
  • la influencia de las personas que ocupan posiciones en la compañía (CEO, CIO, etc.) es absolutamente nula en un equipo Scrum. La responsabilidad de ellos es llevar a la administración de la compañía.
  • El poder de decisión es compartido por todos quienes son partes del Scrum Team.

Si una empresa quiere lograr el éxito en la implementación de Scrum, debe entender que el cambio organizacional es profundo y que, en su máxima expresión, significa el fin de las jerarquías dentro de ella y que las decisiones las toman los integrantes del Scrum Team de forma compartida.

Gracias a todos por su apoyo 🙂

Inicia sesión para ver o añadir un comentario.

Más artículos de Ramiro Exequiel Cervera Portillo

Otros usuarios han visto

Ver temas