Si ha experimentado con el scrum, probablemente esté familiarizado con los roles de Scrum Master y Propietario de Producto. Pero en caso de que no lo esté, aquí tiene un rápido desglose: El Scrum Master es responsable de asegurar que el equipo siga el proceso de Scrum, mientras que el Propietario del Producto se asegura de que el equipo dedique tiempo a construir cosas que aporten el mayor valor a la organización. Estos roles suenan tan engañosamente simples que a veces una sola persona tratará de abordar ambos.
Esto puede suceder en una implementación de scrum cuando el dueño del producto nunca es asignado oficialmente al equipo, dejando al Scrum Master para que se encargue de estas responsabilidades. También puede suceder cuando el Scrum Master del equipo es también un contribuyente individual, y simplemente demasiado abrumado para centrarse en el proceso de scrum. Independientemente de la razón, cuando un equipo intenta combinar todas las responsabilidades en un solo rol, casi nunca termina bien. Veamos algunas de las formas en que esto puede salir mal, y cómo arreglarlo.
Escenario 1: Scrum Master actúa como propietario del producto
Lo más común es que cuando se combinan estos roles, resulta que el Scrum Master también lleve el sombrero de Dueño de Producto. Aunque parezca lógico, el Scrum Master puede no tener acceso a los clientes para obtener información valiosa. Sin una retroalimentación procesable, el equipo simplemente divide un producto no validado en piezas cada vez más pequeñas, entregando cada una de ellas de manera incremental. Aunque la entrega incremental es una mejora con respecto a una sola entrega grande, la realidad es que es realmente una forma más eficiente de entregar el producto equivocado.
Cuando el Scrum Master actúa como dueño del producto, es fácil perder una visión coherente para el equipo, lo que resulta en la entrega de un trabajo de bajo valor. Esto puede suceder cuando el Scrum Master, al carecer de acceso al cliente o de una verdadera visión del producto, simplemente apila el trabajo atrasado con los artículos que le resultan más interesantes o familiares. El resultado es que el equipo desempolva la aplicación haciendo pequeñas mejoras en las características existentes o limpiando errores de baja prioridad, pero sin realizar ningún trabajo significativo. En este caso, el bajo valor no debe confundirse con la baja calidad: Si bien el equipo puede estar produciendo un trabajo de alta calidad, eso no significa que tenga un impacto significativo en el producto.
Escenario 2: El dueño del producto actúa como Scrum Master
La propiedad del producto es un trabajo a tiempo completo. Esto significa que es fácil que las responsabilidades fuera de este papel se deslicen. Cuando el Propietario del Producto actúa como un Scrum Master normalmente vemos que las piezas menos tangibles del proceso de scrum empiezan a decaer lentamente. Las retrospectivas son a menudo la primera víctima, ya que sus resultados pueden (incorrectamente) parecer menos relevantes para un Dueño de Producto ocupado. Aunque el propietario del producto no cancele oficialmente una retrospectiva, puede considerarla más relevante para el equipo de desarrollo y, por lo tanto, dejarle la programación a ellos. Estas reuniones parecen no tener importancia para la organización y finalmente desaparecen.
Por otra parte, el síntoma puede no ser tan flagrante como una reunión perdida. En algunos casos, las reuniones regulares seguirán ocurriendo pero empezarás a notar que su enfoque cambia sutilmente. Por ejemplo, todavía se producen reuniones diarias pero en lugar de actuar como una oportunidad para que el equipo planifique su trabajo del día, se transforman lentamente en una reunión de estado en la que cada miembro del equipo informa de su progreso al Propietario del Producto. De la misma manera, las reuniones de planificación de sprints seguirán teniendo lugar, pero en lugar de que el equipo llegue a estimaciones y a un plan de sprints juntos, pueden verse obligados a asumir compromisos incómodos como resultado de un Propietario de Producto demasiado entusiasta.
Cómo arreglarlo
Tanto el maestro de scrum como el dueño del producto, en su mayoría, son trabajos de tiempo completo. Cuando la misma persona intenta cubrir ambos roles, casi siempre se produce un desastre. En los casos en que el Scrum Master está cumpliendo con las responsabilidades del propietario del producto, la solución más simple puede ser liberar al individuo de sus responsabilidades de Scrum Master, permitiéndole enfocarse en el rol de propietario del producto por completo. Muchos Scrum Masters eventualmente gravitan hacia el rol de Dueño de Producto y, últimamente, esto se ha convertido en una progresión de carrera muy popular para aquellos con gusto por la Administración de Productos.
Sin embargo, ten en cuenta que tu equipo aún necesita un Scrum Master. Esta es tu oportunidad para identificar a un miembro del equipo que esté preparado para el desafío, y entrenarlo para su nuevo rol. Si tiene éxito, tendrá un nuevo Scrum Master dedicado, criado dentro del equipo, y un nuevo Propietario de Producto dedicado con experiencia en el proceso de scrum. Es una gran victoria.
En situaciones en las que el propietario del producto actúa como Scrum Master, la solución es encontrar un nuevo Scrum Master que pueda dedicarle tiempo al papel. Esto no sólo libera al propietario del producto de la gestión del proceso de Scrum, sino que también ayuda a crear una sana tensión entre los Scrum Masters y los propietarios del producto. Idealmente, el Scrum Master y el Propietario del Producto actúan como fuerzas opuestas. Mientras que el Dueño del Producto representa los intereses de los clientes, el Scrum Master representa los intereses del equipo. Cuando una sola persona trata de cumplir con ambos roles, esta sana tensión se pierde y el punto de apoyo inevitablemente se inclina demasiado en una dirección.
Esto se ve a menudo cuando el propietario del producto intenta ambos papeles, ya que el punto de apoyo puede inclinarse hacia conjuntos de características más grandes y una carrera hacia el mercado, lo que no sólo sacrifica la inversión del equipo en la calidad, sino que también puede afectar a su bienestar general. Liberar al Propietario del Producto para que se concentre completamente en la propiedad del producto, mientras permite que un individuo completamente diferente se concentre en el proceso de scrum, ayuda a restaurar el equilibrio y sirve mejor al resultado final.
Para llevar
Hay excepciones a cada regla, y es posible que una persona cumpla ambas funciones con éxito. Sólo hay que tener en cuenta que esta no es la norma, ni debe ser una solución a largo plazo. Para dar a su organización la mejor oportunidad de éxito al usar el scrum, permita que dos personas distintas desempeñen estas funciones. Incluso si está luchando por encontrar a aquellos con la aptitud adecuada, estará mejor con dos personas que tengan la pasión de crecer en sus respectivos roles, en lugar de un individuo excepcional que luche por equilibrar ambos.
¿Quieres saber más sobre cómo funciona realmente el ágil? Echa un vistazo al curso de Jeremy, Ágil en el mundo real, para conocer estrategias concretas para que las mejores técnicas ágiles funcionen en tu equipo.