search
top

Cómo definir responsabilidades en un equipo ágil, matrices RACI y otros

Mira que habré visto equipos que comienzan a implantar agilidad y si hay algo que se repite en la mayoría de ellos es la confusión sobre los roles y responsabilidades de cada miembro o cada rol.

Ya decía hasta Kent Beck, autor de eXtreme Programming, en libro su Planning Extreme Programming (XP), que necesitamos un proceso software con responsabilidades claras por la misma razón que necesitamos leyes: para evitar el miedo, para no perder nuestros “derechos”, para preservar la seguridad y evitar miedos. Y ya lo comentamos aquí en el blog, el miedo es un peligro mayor que cualquier mala práctica de gestión software.

Aunque no son pocos los artículos y post que tratan las responsabilidades típicas en un proyecto ágil (mismamente en el blog le hemos dedicado varios post, como Derechos y deberes de los miembros de un equipo Scrum (o ágil en general, o de cualquier tipo), o las infografías que hicimos en su día para ello, como Una infografía (en español) sobre el Rol del Product Owner o Una infografía (en español) sobre el rol del Scrum Master) parece que no son suficientes. Hace falta algo más.

Y por ello, por lo anterior, son varias las iniciativas que se suelen usar para bajar un poco, y acotar más, las responsabilidades de los miembros de un equipo ágil, o de un equipo Scrum. En este post te voy a contar las principales, con sus pros y con sus contras.

Las matrices RACI

Hay una técnica, bastante antigua, por cierto, llamada RACI, o matriz de responsabilidad. Dicha técnica se utiliza para determinar la responsabilidad, o el rol que ocupa, un perfil, o una persona, o un grupo, respecto a las diferentes tareas que se deben lleva acabo.

El nombre de RACI viene de los cuatro papeles que alguien puede tomar frente a una responsabilidad:

  • R, de Responsible o, en español, el Responsable de hacer la tarea.
  • A, de Accountable, o el que la Aprueba, el que da el OK.
  • C, de Consulted, o Consultado, vamos, al que se le pregunta.
  • I, de Informed, Informado, al que se le cuenta el resultado y los avances.

Críticas a la Matriz RACI en agilidad (o en gestión de proyectos en general)

Hay tres criticas principales: las matrices RACI ponen en riesgo que los equipos sean auto-organizados, liberan de responsabilidad a todo el equipo y pueden disparar la burocracia.

Matrices RACI y el peligro de centralizar responsabilidades

Vamos con la primera, el método RACI recomienda sólo una R por rol (es decir, no tener dos R, dos responsables, para una misma tarea, para evitar “vacíos de responsabilidad”). Ejemplo:

Product Owner
Asegurar que al comienzo de cada Sprint está claro el “done”, es decir, cuándo se considera, bajo qué criterios, que algo se ha terminado R

 

Y desde algunos foros se critica que esta manera de trabajar incita a que el resto de roles se desentiendan de aquellas responsabilidades en las que no tienen una R. Y en relación a esto, se critica que las matrices RACI frenen la creación de equipos “auto-organizados”.

El concepto de “auto-organizado” ya lo tratamos en el blog hace un tiempo, te dejo aquel post sobre equipos auto-organizados, pero te resumo que se basa en que el equipo es dirigido y organizado por sus propios miembros, la gerencia puede dar forma y empujar al equipo y sus miembros, pero la dirección no dicta los detalles de cuál es la solución ni el proceso de cómo crearla. El equipo es responsable no sólo de dirigir y organizarse para alcanzar sus objetivos, sino también de controlarse y adaptarse su para corregir y mejorar su propio desempeño. Esto significa que el equipo puede cambiar la forma en que se dirige y organiza.

Y la matriz RACI… puede bloquear la auto-organización, cosa que, dicho sea de paso, es altamente complejo en la mayoría de los equipos, y no por las matrices RACIS, sino por cuestiones culturales, madurez, etc.

Matrices RACI, responsables y culpables

En un artículo de hace ya unos años, Mike Cohn trataba el tema de las responsabilidades y el riesgo de buscar responsables para las actividades… y culpables cuando no se cumplen.

Concretamente, él hablaba del error de considerar que el Product Owner es el responsable final de todo y liberar al resto del equipo de la responsabilidad, cosa que puede fomentar mucho la “R” de la matriz RACI.

Matrices RACI y la burocracia

La tercera crítica es la burocracia. Sobre esta crítica no he visto mucho escrito por ahí y os la traigo de mi propia experiencia. Cuando veo a alguien haciendo una matriz RACI la mayoría de las ocasiones acabo viendo un Excel de 200 filas con letras por todos los lados, discusiones añadidas, etc.

Alternativas y adaptaciones de la matriz RACI a equipos ágiles

Hay varias, todas con sus pros y sus contras, creo que lo mejor es que conozcas las principales y, según la situación, tomes lo que mas te convenga en cada momento.

Tableros de Autoridad

Jurgen Appelo, autor de Management 3.0, propone que si usas una matriz RACI en un equipo ágil evites diferenciar entre R (Responsable) y A (Accountable, o el que la Aprueba), que utilices uno solo ya que cada uno “es responsable de hacer lo que le toca y de hacerlo bien y validarlo él mismo”. Y va más allá proponiendo una técnica alternativa llamada “Tableros de Autoridad”.

Un “Tablero de Autoridad” es una matriz que tiene en filas las áreas clave de responsabilidad (evitando meter tareas, para evitar burocracia) y el columnas 7 niveles de delagación:

Tell: Tú tomas una decisión por los demás y puedes explicar el porqué, sólo si quieres.

Sell: Tú tomas una decisión por los demás, pero intentarás convencerlos de que tomaste la decisión correcta.

Consult: Preguntas primero, antes de tomar una decisión, respetas las opiniones del resto.

Agree: Discusión con todos los involucrados hasta alcanzar un consenso sobre la decisión final.

Advise: Opinas, pero la decisión final no es tuya.

Inquire: Dejar a los demás para decidir.

Delegate: Se deja la decisión de en otros y ni siquiera quieres saber acerca de los detalles.

Adaptaciones de la Matriz RACI a proyectos ágiles y Srum

Por la web puedes encontrar muchas, como esta.

Quizá una de las más populares, sin falta de polémica (ver los comentarios) es esta propuesta. Abajo te dejo la matriz.

Concluyendo…

Como te contaba al principio, el tema de roles y responsabilidades en un equipo ágil al principio parece una cosa obvia y a la hora de la verdad trae bastante lio.

Muchas veces, las listas de responsabilidades parecen no ser suficientes, listas como las que te dejé en Derechos y deberes de los miembros de un equipo Scrum (o ágil en general, o de cualquier tipo) o las infografías que hicimos en su día para ello, como Una infografía (en español) sobre el Rol del Product Owner o Una infografía (en español) sobre el rol del Scrum Master.

Por lo anterior, hay varias propuestas, que principalmente parten de las famosas, y antiguas, matrices RACI, que, dicho sea de paso, tienen bastantes críticas.

Todas estas técnicas tienen sus pros y sus contras, creo que lo mejor es que conozcas las principales y, según la situación, tomes lo que mas te convenga en cada momento.

Una respuesta to “Cómo definir responsabilidades en un equipo ágil, matrices RACI y otros”

  1. darley biviana pacheco dice:

    Gracias por este post!
    Concidencialmente me encontraba en la clase de la especialización viendo el tema de matrices RACI, cuando lo vi y pude aportar las tres críticas que se realizan a este instrumento.
    En la experiencia laboral puedo aportar que efectivamente esta matriz se convierte en un artefacto sumamente tedioso de administrar, el cual se tiene como cumplimiento de norma por el sistema de gestión de calidad y diversos controles que hacen la auditorias, pero realmente no otorga un punto estratégico ni genera toma de decisiones a partir de su análisis, ya sea porque se este utilizando mal o porque efectivamente no responde a la dinámica de roles de la entidad.

Dejar una respuesta

Tu dirección de correo electrónico no será publicada.

top