El Scrum Team

Cuando se utiliza la palabra Team (Equipo) en el contexto de Scrum, puede ser que, de forma automática, se piense en el Development Team (Equipo de Desarrollo) y sus miembros como esa unidad cohesionada, alineada y de alto rendimiento (o en el camino de alcanzarlo).

Sin embargo, cuando utilizamos la palabra Team, en Scrum, debemos ir más allá y pensar en el Scrum Team al completo; un equipo igualmente cohesionado, alineado y de alto rendimiento (o en el camino de alcanzarlo), pero que incluirá a los tres roles del marco Scrum: el Product Owner, los miembros del Dev. Team y el Scrum Master.

La separación de poderes funciones

En el ámbito socio-político, Montesquieu argumentaba que «todo hombre que tiene poder se inclina a abusar del mismo; él va hasta que encuentra límites. Para que no se pueda abusar del poder hace falta que, por la disposición de las cosas, el poder detenga al poder»; dando así pie a lo que se conocería como la separación de poderes, donde cada uno de los poderes independientes y especializados (legislativo, ejecutivo y judicial) mantienen una vigilancia sobre el resto para evitar un abuso de poder por parte de los otros dos.

En el caso del Scrum Team, esta separación se formula no tanto buscando evitar esos abusos de poder (aunque en última instancia, quizá también, como veremos más adelante), si no más bien buscando una especialización o separación de funciones que facilite la adopción de una nueva mentalidad (la Agilidad) que choca de frente con las mentalidades tradicionales que, aún a día de hoy, solemos encontrar en un gran número de organizaciones.

Tener roles especializados en maximizar el valor del producto a desarrollar (Product Owner), en su desarrollo (Dev. Team) y en la promoción y el apoyo a Scrum en el equipo y la organización (ScrumMaster), es una gran ayuda a la hora de que cada uno de estos tres roles pueda evolucionar y adoptar las habilidades requeridas en un contexto altamente cambiante, y con unas culturas organizativas en muchos casos enfrentadas a la mentalidad Ágil, de una forma más eficaz y eficiente, al poder focalizarse en un subconjunto más reducido y homogéneo.

#noproductowner #noscrummaster

. “Cuando utilizamos la palabra Team, en Scrum, debemos ir más allá y pensar en el Scrum Team al completo, un equipo igualmente cohesionado, alineado y de alto rendimiento" Clic para tuitear

Y aunque estas críticas son perfectamente válidas, y pueden ser muy beneficiosas porque permiten iniciar un diálogo y una búsqueda de respuestas a algunas de las dudas que pueden surgir a la hora de aplicar Scrum en las organizaciones, como marco de referencia Ágil, a continuación voy a compartir dos de las razones que me hacen apoyar este modelo:

• En primer lugar, este modelo permite evitar -al igual que en el caso de la separación de poderes de Montesquieu- cierto “abuso de poder” (o la sensación de que dicho abuso existe o pueda existir). 

Imaginemos por un momento una situación en la que una persona actúa como Product Owner + ScrumMaster, trabajando con un Dev. Team en un contexto de una organización tradicional.

Atendiendo al reparto de responsabilidades, esta situación no difiere mucho de una situación tradicional de un Project Manager y un equipo de desarrollo. Si a esto sumamos la cultura tradicional organizativa que se describía, este contexto no va a favorecer en ningún modo la auto-organización del Dev. Team, pieza angular de la cultura Ágil. 

De igual forma, esta situación tampoco es el caldo de cultivo para que la multifuncionalidad del Dev. Team, y la responsabilidad compartida entre sus miembros, puedan darse de forma más o menos espontánea.

• En segundo lugar, este modelo facilita y acelera la adopción de Scrum (y por tanto abre la puerta al cambio de la cultura organizativa hacia una cultura Ágil) puesto que, además de trabajar en desarrollar el producto que más valor aporte al cliente en cada momento, permitirá tener un ojo puesto en las fricciones que el nuevo marco de trabajo y la nueva cultura que se está gestando, provoca en el resto de la organización. 

Porque no hay que olvidar que esta es una de las responsabilidades del Scrum Master en la que, si bien muchas veces queda relegada a un segundo lugar, frente a las labores de promoción y apoyo de Scrum en el seno del Scrum Team, debe poner foco puesto que, si no vigilamos dichas fricciones, es probable que surjan situaciones altamente incómodas que puedan poner en grave peligro la adopción de Scrum y el cambio cultural iniciado con dicha adopción.

Conclusiones

Scrum, el Marco Ágil más extendido en las organizaciones Ágiles (o aquellas que intentan serlo), propone un modelo, el Scrum Team, en el que el Product Owner, el Dev. Team y el ScrumMaster se reparten el conjunto de responsabilidades requeridas para desarrollar el producto, facilitando así la adopción de las nuevas habilidades requeridas para responder de forma ágil a los cambios en las necesidades y en el contexto, evitando situaciones de “abuso de poder”, y facilitando el cambio cultural requerido para lograr llevar la Agilidad a toda la organización.