Project Management Ecuador

Scrum Master no es igual a Product Owner

Scrum Master no es igual a Product Owner

Si ha podido experimentar algo con Scrum, es probable que esté familiarizado con los roles de Scrum Master y Product Owner. Pero en caso de que no sea así, aquí hay un desglose rápido: el Scrum Master es responsable de garantizar que el equipo siga el proceso de Scrum, mientras que el Product Owner se asegura de que lo que el equipo construya aporte el mayor valor a la organización. Estos roles suenan tan engañosamente simples, que a veces una sola persona intenta abordar ambos.

Pero antes, desmitifiquemos algo…

Mito: ¿Se manejan cronogramas en Scrum?

El papel del Scrum Master no es administrar los cronogramas del proyecto, por lo que no encontrará ninguna respuesta directa a esta pregunta. Cada Sprint podría considerarse como un proyecto, o un conjunto cohesivo de ítems del Product Backlog podría considerarse como un proyecto. Mejor aún, un equipo de Scrum se aleja de la mentalidad de proyecto hacia una mentalidad de producto.

Los desarrolladores poseen el plan para cumplir con cada meta de Sprint (Sprint Goal), y se utiliza un Sprint Backlog para ese propósito. Los desarrolladores también puede usar los radiadores de información para rastrear su propio progreso (por ejemplo, gráficas de Burn-down, de Burn-up, diagramas de flujo acumulado (CFD) y otras técnicas más avanzadas.

El Product Owner pronostica cuando pueden liberarse (release) ítems de un Product Backlog para un producto determinado, y puede compartir esa liberación a todos los interesados en la revisión del Sprint (Sprint Review).

El trabajo del Scrum Master, a un alto nivel, es servir al los desarrolladores, al Product Owner y a la organización. Los Scrum Masters facilitan, enseñan, entrenan, provocan la eliminación de los impedimentos para progresar, y defienden Scrum. La Guía de Scrum continúa diciendo:

El Scrum Master debe trabajar con el Product Owner, los desarrolladores y otras partes involucradas a comprender si los artefactos son completamente transparentes. Hay prácticas para hacer frente a la transparencia incompleta: El Scrum Master debe ayudar a todos a aplicar las prácticas más apropiadas en ausencia de transparencia completa. Un Scrum Master puede detectar transparencia incompleta inspeccionando los artefactos, patrones de detección, escuchando estrechamente a lo que se dice, y detectando las diferencias entre los resultados esperados y reales.

La Guía de Scrum

En la mayoría de los casos, un cronograma de proyectos es más representativo de las metodologías orientadas por un plan que de las metodologías ágiles. Hay casos en que hay una fecha límite asociada con la resolución de un problema. Por ejemplo, si está trabajando con algo impactado por los cambios en las leyes o regulaciones, el producto o el servicio puede necesitar cumplir con una fecha determinada. En cambio, en términos generales, un proyecto ágil trabaja agregando valor, y se termina cuando el costo de otra iteración excede el valor que se obtendría al realizar esa iteración.

No todo proyecto puede ajustarse a un marco de trabajo ágil.

Volvamos al tema que nos atañe, ¿por qué un Product Owner querría ser Scrum Master y viceversa?

Para mayor información de términos de Scrum y Agile, consulte este Diccionario de Bolsillo de términos Agile.

Esto puede suceder en una implementación de Scrum desde cero, cuando un Product Owner nunca se asigna oficialmente al equipo, dejando al Scrum Master a cargo de estas responsabilidades. También puede suceder cuando el Scrum Master del equipo también tenga asignadas tareas para este, y simplemente esté demasiado abrumado para concentrarse en el proceso de Scrum. En estos casos, el Product Owner puede intentar dar un paso adelante para liderar el proceso, además de sus propias responsabilidades. 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 solucionarlo.

Escenario 1: Scrum Master actúa como Product Owner

Con mayor frecuencia, cuando estos roles se combinan, el Scrum Master también lleva el sombrero de Product Owner. Si bien suena lógico, es posible que el Scrum Master no tenga acceso a los clientes para recopilar comentarios valiosos. Sin comentarios procesables, el equipo simplemente divide un producto no validado en partes cada vez más pequeñas y entrega cada una de manera incremental. Si bien la entrega incremental es una mejora con respecto a una sola entrega grande, la realidad es que en realidad es solo una forma más eficiente de entregar el producto incorrecto.

Cuando el Scrum Master actúa como Product Owner, es fácil perderse una visión coherente para el equipo, lo que resulta en la entrega de trabajos de bajo valor. Esto puede suceder cuando el Scrum Master, que carece de acceso al cliente o de una verdadera visión del producto, simplemente acumula el trabajo pendiente con los elementos que encuentra más interesantes o familiares. Esto da como resultado que el equipo desempolva la aplicación realizando pequeñas mejoras en las funciones existentes o eliminando errores de baja prioridad, pero sin realizar ningún trabajo significativo. En este caso, el valor bajo no debe confundirse con la baja calidad: si bien el equipo puede estar produciendo un trabajo de alta calidad, no significa que esté teniendo un impacto significativo en el producto.

Escenario 2: Product Owner actúa como Scrum Master

El Product Owner es un trabajo de tiempo completo. Esto significa que es fácil que se deslicen responsabilidades ajenas a esta función. Cuando el Product Owner actúa como Scrum Master, generalmente vemos que las piezas menos tangibles del proceso de Scrum comienzan a disminuir lentamente. Las retrospectivas (Sprint Retrospectives) suelen ser la primera víctima, ya que sus resultados pueden parecer (incorrectamente) menos relevantes para un Product Owner ocupado. Si bien es posible que no cancele oficialmente una retrospectiva, puede considerarla más relevante para el equipo de desarrollo que para él y, por lo tanto, dejar esta ceremonia en sus manos. Estas reuniones parecen poco importantes para la organización y eventualmente desaparecen.

Alternativamente, el síntoma puede no ser tan evidente como una reunión perdida. En algunos casos, se seguirán celebrando reuniones periódicas, pero empezará a notar que su enfoque cambia sutilmente. Por ejemplo, las reuniones diarias (Daily Scrum) todavía ocurren, pero en lugar de actuar como una oportunidad para que el equipo planifique su trabajo para el día, se transforman lentamente en una reunión de estado en la que cada miembro del equipo informa su progreso al Product Owner, quien no debería participar ahí. Del mismo modo, las reuniones de planificación de Sprints (Sprint Planning) seguirán ocurriendo, pero en lugar de que el equipo llegue a estimaciones y un plan de sprint juntos, pueden verse obligados a asumir compromisos incómodos debido un Product Owner demasiado entusiasta.

Cómo corregirlo

Tanto el Scrum Master como el Product Owner, en su mayor parte, son trabajos de tiempo completo. Cuando la misma persona intenta desempeñar ambos roles, casi siempre se produce un desastre. En los casos en los que el Scrum Master está cumpliendo con las responsabilidades del Product Owner, la solución más simple puede ser liberar al individuo de sus responsabilidades de Scrum Master, permitiéndole enfocarse en el rol del Product Owner por completo. Muchos Scrum Masters eventualmente gravitan hacia el rol de Product Owner y, últimamente, esto se ha convertido en una progresión profesional muy popular para aquellos con gusto por la Gestión de Productos.

Sin embargo, tenga en cuenta que su equipo todavía necesita un Scrum Master. Esta es su oportunidad de encontrar a quien que esté preparado para el desafío y asesorarlo en su nuevo rol. Si tiene éxito, tendrá un Scrum Master nuevo y dedicado, creado dentro del equipo, y un nuevo Product Owner dedicado con experiencia en el proceso de Scrum. Esa es una gran victoria.

En situaciones en las que el Product Owner actúa como Scrum Master, la solución es encontrar un nuevo Scrum Master que pueda dedicar tiempo al rol. Esto no solo libera al Product Owner de administrar el proceso de Scrum, sino que también ayuda a crear una tensión saludable entre los Scrum Masters y los Product Owners. Idealmente, Scrum Master y Product Owner actúan como fuerzas opuestas. Mientras que el Product Owner representa el interés de los clientes, el Scrum Master representa los intereses del equipo. Cuando una sola persona intenta llenar ambos roles, esta tensión saludable se pierde y el fulcro inevitablemente se va demasiado lejos en una dirección.

Esto se ve a menudo cuando el propietario del producto intenta ambos roles, ya que puede inclinarse hacia conjuntos de características más grandes y una prisa de salir el mercado, que no solo sacrifica la inversión del equipo en la calidad del producto, sino que también puede tener afectar el bienestar general del equipo. Liberar al Product Owner para centrarse completamente en la propiedad del producto, al tiempo que permite que una persona completamente diferente se centre en el proceso de Scrum, ayuda a restablecer el equilibrio y mejorará el resultado final.

Excepciones

Hay excepciones a todas las reglas, y es posible que una persona sirva ambos roles con éxito. Solo tenga en cuenta que esta no es la norma, ni debe ser una solución a largo plazo. Para brindarle a su organización la mejor oportunidad de éxito al usar Scrum, permita que dos individuos distintos atiendan estos roles. Incluso si está luchando para encontrar a aquellos con la aptitud correcta, estará mejor con dos personas que tengan una pasión por crecer en sus respectivos roles, en lugar de un individuo excepcional que luchan por equilibrarse ambos.

No podrá obtener beneficios al tratar de conseguir dos roles por el precio de uno.

Si necesita nuestra asistencia para sacar adelante su proyecto, no dude en contactarnos. Estamos prestos para brindarle Asesoría OnLine en Dirección de Proyectos. Si lo que desea es certificarse como Director de Proyectos, opte por nuestro Programa Integral de Capacitaciones.

Resumen
Scrum Master no es igual a Product Owner
Nombre del artículo
Scrum Master no es igual a Product Owner
Descripción
¿Un Scrum Master debe escribir historias de usuario?, ¿debe asumir las responsabilidades del Product Owner?, ¿debe hacer cronogramas? Cuánto aporta a la organización definiciones correctas en un ambiente ágil.
Autor
Publisher Name
Project Management Ecuador
Publisher Logo

Máster en Sistemas de Información Gerencial de la Escuela Superior Politécnica del Litoral (ESPOL). Professional Scrum Master™, Project Management Professional (PMP®). Miembro activo del Project Management Institute (PMI®), Capítulo Ecuador, desde el mismo año. Tiene más de 10 años de experiencia en el Sector Financiero y Banca, en el área de Tecnología de Información y Comunicaciones y Desarrollo de Aplicaciones y Sistemas, y más de 6 años en Administración Estratégica de Proyectos Institucionales. Ha trabajado desde el 2006 en dos de los mayores bancos de la ciudad de Guayaquil como Director de Proyectos. Ha liderado y culminado diversos proyectos, entre otros: Migración de Contact Centers, físicamente y actualización de su infraestructura tecnológica, Implementación de módulos completos de ERPs para varios departamentos, con su correspondiente adaptación y entrenamiento. Lanzamiento de nuevos canales financieros y Corresponsales No Bancarios. Nuevos productos para personas naturales y jurídicas. Actualización y optimización de la plataforma de Interaction Voice Response (IVR). Otros de complejidad similar. Ha dictado clases de Project Management y el uso de Microsoft Project Professional 2013, entrenamiento y formación profesional en Centros de Educación Continua en todo el país.

Deja un comentario

Translate »
A %d blogueros les gusta esto: