IEBSchool - La Escuela de los Negocios y los Emprendedores

Contenido destacado del mes

Agile y cascada, amigos?

Quiero deciros que Agile no viene para sustituir a las metodologías más tradicionales, sino a ser su “amigo”. Es cierto que normalmente se tienden a ver comparativas de Agile vs métodos tradicionales, de desarrollo iterativo e incremental vs cascada; y … [ leer más ]

Lo más leído

Tags

Mezclando roles en Scrum

15 mayo, 2019, en agile, metodologías ágiles, roles, scrum por Carmen Guadalupe Hidalgo Muñoz
Tags: , ,

1 Star2 Stars3 Stars4 Stars5 Stars (No Ratings Yet)
Loading...

Lo 1º que se me vino a la cabeza al pensar en este tema fue: si la flexibilidad y el cambio son la tónica en general en metodologías ágiles y en particular en Scrum, aquello a lo que vienen a responder, ¿por qué no podrían serlo también para los roles?

Primero necesitaba tener claro el papel que juega cada una de las figuras clave dentro de un proyecto:

  1. Product Owner: es el dueño del producto y de su backlog, el máximo representante del clienteen la Organización. El responsable de definir «QUÉ» se quiere conseguir en cada Sprint.
–          Skills destacados
  • Negociación
  • Comunicación
–          Conocimientos
  • Del Producto y de su Negocio
  • Financieros básicos (P&L)
  1. Scrum Master: es el garante del modelo Scrum. Sirve al Product Owner en la planificación y el mantenimiento de la Pila de Producto, y al Equipo Técnico para que se auto-organicen y eliminen impedimentos.
–          Skills destacados
  • Liderazgo
  • Comunicación
–          Conocimientos
  • Del Modelo Scrum
  • De Gestión
  1. Equipo Técnico: es el garante del incremento del producto, el responsable de definir «CÓMO» se va a conseguir el incremento en cada Sprint
–          Skills destacados
  • Colaboración
  • Comunicación
–          Conocimientos
  • Técnicos (ad hoc dependiendo de la naturaleza del producto y del objetivo de cada sprint)
  • De Gestión

Podemos analizar también el papel de algún rol no tan estudiado en Scrum, como es el del analista, un rol transversal que es responsable de compartir la información, hacer análisis ad hoc y saber qué pautas se necesitan en el volcado de la información.

Una vez clarificadas las funciones, ya atisbamos que no son tan sencillas como para que de 1ªs podamos aventurarnos a asumir por las buenas más de un rol a la vez.

Una de las ventajas poderosas de Scrum es tener dos tipos diferentes de responsabilidades: la responsabilidad compartida del producto final y la responsabilidad individual basada en el rol de cada miembro del equipo. Pensando en estos individualismos, y si pensamos además los principios de Scrum dictan que los roles nunca deben combinarse, quizá no parezca buena idea combinarlos en una misma persona.

Eso sí, oficialmente puede recomendarse no hacerlo, pero también es cierto que algo tan determinante como es el tamaño de una empresa puede también condicionar la posibilidad de que cada rol lo asuma una persona. Pensemos en una startup sin apenas presupuesto; o en una empresa más grande, donde la directiva no quiera asumir el coste de pagar a un Scrum team completo para comenzar a implantar este framework.

Aunque en esos casos los multirroles sean algo impuesto, hemos de reconocer que también hay ventajas de trabajar con este sistema:

Por ejemplo, en el caso de Product Owner y Scrum Master, que sería un posible 1er tándem para poder aunar, ambos roles comparten intereses comunes:

  • Están preocupados por el desempeño del equipo
  • Se involucran con el equipo
  • Ambos entienden la importancia de la calidad en la ejecución de su trabajo.

Poniéndonos esos dos sombreros a la vez, es muy posible que se pueda administrar mejor la planificación de Sprint sabiendo cómo queremos que evolucione el producto, no?

Pensemos ahora en el caso de un Scrum Master o el Product Owner que sean a la vez miembro del equipo. Como bien señala la Agile Alliance, los Scrum Masters de hoy están presionando a los equipos para que sean más auto-organizados que nunca hasta el punto en que casi ya no necesiten esta figura. Pero este papel combinado no es para todos, necesitaremos que se den al menos un par de características clave en la persona que aúne todas estas funciones:

  • Que sea altamente sociable. El equipo necesita sentirse cómodo teniendo discusiones porque requerirán enseñanza y tutoría para confiar en esta persona.
  • Que tenga experiencia técnica, ya necesitan poder hablar el mismo idioma que el equipo. Habrá ocasiones en las que el equipo necesite hablarle como Scrum Master o Product Owner y otras veces en que necesite hablarle como miembro del equipo. En esos casos, claramente la mejor opción es elegir uno de los roles y comunicarse de esa manera.

Por último, pensemos en un Analista que pueda ejercer las funciones de Product Owner, que si atendemos a las conclusiones que extraíamos de la última masterclass que tuvde Alberto Ambrosio, es un tándem más que posible teniendo en cuenta el papel transversal del analista, involucrado y de apoyo a la toma de decisiones del PO que lleva a cabo; en este contexto el analista acaba por adquirir un conocimiento del producto que puede hacerle apto para desempeñar funciones propias del dueño de producto.

Ahora bien, si pensábamos que esté cúmulo de funciones no suponían más que un reto interesante, la realidad está bastante lejos. Todos ellos son trabajos a full time, y existen bastantes detractores de los multirroles en Scrum (entre ellos instituciones de la talla de la Scrum Alliance); no basándose únicamente en la recomendación oficial de que no deberían mezclarse, sino en razones sin duda de peso. Hay toda una serie de inconvenientes que es posible que desaconsejen esta fusión de figuras.

Centrémonos de nuevo en el tándem Scrum Master- Product Owner, que sin duda es que más literatura ha generado sobre este asunto.

Existe de forma general una tensión saludable entre Scrum Masters y los propietarios del producto. Idealmente, el Scrum Master y el PO actúan como fuerzas opuestas. Mientras que el propietario del producto representa el interés de los clientes, el Scrum Master representa los intereses del equipo. Cuando una persona intenta cumplir ambos roles, esta tensión sana se pierde, y eso no siempre es bueno.

Ese conflicto de intereses que pueda crearse puede provocar que dedique más tiempo a defender el producto que a eliminar obstáculos o a facilitar conversaciones para el equipo que a crear historias de usuarios; o que pueda pedirle al equipo que haga cosas que interrumpirán y dañen el proceso de obtener el mejor producto posible en el menor tiempo posible. Se rompería el equilibrio necesario en la triada de responsabilidades de la que habla Oscar R. Onrubia en una serie de posts de su blog.

También pensemos que es posible que el SM no tenga acceso fácil a los clientes para recopilar  un feedback valioso. Sin una retroalimentación procesable, el equipo se dedicaría a dividir un producto no validado en partes cada vez más pequeñas, entregando cada uno de forma incremental. Eso sólo cumpliría una pequeña parte de los objetivos de Scrum.

Además, un artefacto importante en este framework como son las reuniones, pueden cambiar sutilmente su enfoque, convirtiéndose en encuentros en los que cada miembro del equipo reporta su progreso al Propietario del producto.

Qué hay del Scrum Master o el Product Owner que a la vez es un miembro del Equipo Técnico?

Es cierto que es un poco extraño que un desarrollador que supuestamente trabaje en las historias de usuario proporcionadas por el propietario del producto, lo ayude al mismo tiempo a dirigir sobre cómo escribir y priorizar las historias de usuario. Que un desarrollador logre anular su geek interno en favor de las necesidades comerciales del producto, o que el PO consiga que no le vean como un “auditor” del trabajo del equipo técnico. Pero también es verdad que éste puede jugar un papel de analista de negocio y realizar tareas de análisis y documentación; habrá pocas personas que puedan hacer mejor que él el manual de usuario, ayudándole así a ahondar en el conocimiento del producto desde todos los puntos de vista. En general no hay una oposición tan profunda a la unificación de roles en estos casos.

Habiendo examinado con detalle pros y contras: excepto para el caso de equipos muy seniors y maduros, es probable que cuando permitamos este rol múltiple de una persona en el grupo, comencemos a erosionar aquellas cosas que hacen que el trabajo sea ágil. Básicamente podemos caer en la misma trampa en la que suelen caer los proyectos convencionales, agotando los mecanismos que impulsan la eficiencia y la eficacia.

Referencias

https://www.obs-edu.com/es/blog-project-management/scrum/principales-roles-de-la-metodologia-agil-scrum

https://cristinaramosvega.com/los-roles-scrum/

https://www.scrumalliance.org/agilecareers/careersblog/june-2016/can-the-scrum-master-also-be-the-product-owner

https://modelometodoygestion.wordpress.com/2013/11/25/puede-una-persona-ejecutar-el-rol-de-propietario-y-scrum-master/

https://modelometodoygestion.wordpress.com/2013/12/09/triada-de-responsabilidades-scrum/

https://modelometodoygestion.wordpress.com/2013/11/07/scrummaster-formar-equipo/

https://www.agilealliance.org/resources/experience-reports/multiple-roles-scrum-master-as-a-team-member/

https://www.frontrowagile.com/blog/posts/92-mixing-roles-in-a-scrum-team

 

 

 

 

 

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos necesarios están marcados *

comentarios para esta entrada