Un modelo mental para diferenciar entre ambas posiciones y evitar contratrar, y ser contratado, para ejercer unas tareas que no corresponden a lo que se espera.
gracias por este post, que ayuda a estructurar la conversación. Me gustaría hacer unas matizaciones desde mi punto de vista (más centrado en Scrum).
Todos los modelos son válidos cuando funcionan y dan valor. En este caso las discusiones son más de preferencias y relaciones entre roles.
La filosofía de Scrum se basa entre otros en:
1. Desescalar la organización en equipos (o equipos de equipos) más pequeños responsables de entregar valor a cliente, cubriendo todo el ciclo de vida de estrategia > planificación > ejecución > feedback.
2. En estos equipos hay pocas "etiquetas" de roles y mucho solapamiento de funciones entre miembros. Esto facilita la colaboración, la toma de decisiones basada en la inteligencia colectiva y mitiga los riesgos de dependencias.
3. Orientar el ciclo de vida a la entrega de valor, rehuyendo de la secuencialidad y acercándose al feedback lo más frecuente posible.
Así, en un modelo alineado con Scrum se hablará menos de departamentos y fases, conceptos que aparecen en estos gráficos que planteas.
Se suele asignar el "San Benito" de industrializado y masivo a Scrum, con resultados a menudo muy mejorables, aunque retaría a cualquier otro modelo a conseguir llevar la agilidad a entornos tan "hostiles" para ver si le salía mejor. :-)
La separación entre PM y PO que planteas tiene sentido para segregar responsabilidades en equipos medios y grandes, pero como explicaba antes, no es una visión genuina de Scrum. En este caso es mejor no llamar PO a lo que es un "PO proxy", o intermediario del equipo con el PM.
Es difícil llegar a un acuerdo en este debate porque se basa en puntos de vista lícitos y diferentes. En los orígenes de Scrum, el rol se llamaba Agile Product Manager, pero Ken Schwaber decidió cambiarle el nombre a PO tras el desastre del proyecto Centinel del FBI, donde un PM poco empoderado era un "coladero" de los stakeholders en frente del equipo. El nombre de PO quería dejar claro el "ownership" del producto y que por tanto las decisiones importantes pasaban por esta figura.
Hola Simón,
gracias por este post, que ayuda a estructurar la conversación. Me gustaría hacer unas matizaciones desde mi punto de vista (más centrado en Scrum).
Todos los modelos son válidos cuando funcionan y dan valor. En este caso las discusiones son más de preferencias y relaciones entre roles.
La filosofía de Scrum se basa entre otros en:
1. Desescalar la organización en equipos (o equipos de equipos) más pequeños responsables de entregar valor a cliente, cubriendo todo el ciclo de vida de estrategia > planificación > ejecución > feedback.
2. En estos equipos hay pocas "etiquetas" de roles y mucho solapamiento de funciones entre miembros. Esto facilita la colaboración, la toma de decisiones basada en la inteligencia colectiva y mitiga los riesgos de dependencias.
3. Orientar el ciclo de vida a la entrega de valor, rehuyendo de la secuencialidad y acercándose al feedback lo más frecuente posible.
Así, en un modelo alineado con Scrum se hablará menos de departamentos y fases, conceptos que aparecen en estos gráficos que planteas.
Se suele asignar el "San Benito" de industrializado y masivo a Scrum, con resultados a menudo muy mejorables, aunque retaría a cualquier otro modelo a conseguir llevar la agilidad a entornos tan "hostiles" para ver si le salía mejor. :-)
La separación entre PM y PO que planteas tiene sentido para segregar responsabilidades en equipos medios y grandes, pero como explicaba antes, no es una visión genuina de Scrum. En este caso es mejor no llamar PO a lo que es un "PO proxy", o intermediario del equipo con el PM.
Es difícil llegar a un acuerdo en este debate porque se basa en puntos de vista lícitos y diferentes. En los orígenes de Scrum, el rol se llamaba Agile Product Manager, pero Ken Schwaber decidió cambiarle el nombre a PO tras el desastre del proyecto Centinel del FBI, donde un PM poco empoderado era un "coladero" de los stakeholders en frente del equipo. El nombre de PO quería dejar claro el "ownership" del producto y que por tanto las decisiones importantes pasaban por esta figura.
Te invito a leer un post sobre el tema que escribí el año pasado. https://itnove.com/blog/scrum/product-owner/product-owner-y-product-manager-son-iguales-o-diferentes/
En que consiste esta parte estratégica? Me cuesta imaginar ejemplos de trabajo del pm, hacen balances de presupuestos según los protectos?