¿Puede un Product Owner ser un desarrollador en Scrum?

¿Puede un Product Owner ser un desarrollador en Scrum? En teoría sí, pero ¿lo recomienda Scrum?

El rol del propietario del producto se define explícitamente como un rol separado en Scrum. Las personas a veces usan múltiples sombreros, pero generalmente es una mala idea y ciertamente no lo recomienda el marco.
@CodeGnome: ¿Dónde? ¿Puede proporcionar una referencia que indique que los roles y las personas son una relación de 1 a 1?
La gente podría estar interesada en un hilo relacionado en Programmers SE que encontré esta noche. Si bien no son canónicos, las publicaciones ciertamente abordan el problema de los muchos sombreros que muchas de nuestras propias respuestas abordan a continuación.
@aclear El Libro de reglas oficial de Scrum dice claramente: The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master.Del mismo modo, una cárcel consta de un guardia, un recluso y un alcaide. Siéntase libre de describir cómo funcionaría cualquiera de los marcos según lo previsto con cualquier persona que desempeñe dos o más funciones definidas por el marco al mismo tiempo.
Encuentro maravillosamente esclarecedor que hayas comparado Scrum con una prisión. Para llevar su analogía a los extremos, si la cárcel consta de 1 alcaide, 1 guardia y 1 recluso, no impediría que el alcaide le dé al guardia algún tiempo libre basado completamente en su título.
@AndrewClear: entonces, en su opinión, ¿cree que es aceptable que 1 miembro del equipo de desarrollo priorice y decida el retorno de la inversión para todas las funciones en las que está trabajando el resto del equipo? Ese desarrollador también será responsable de comunicarse con las partes interesadas externas (lo que genera una dinámica de equipo divertida (cultura de la culpa)) y el desarrollador también estaría presente en el stand-up pero pidiendo progreso como propietario del producto. ¿Crees que funciona y quieres una regla explícita que establezca que no funciona? Disfruten las Retrospectivas :-) serán eh... 'interesantes'.
@ Venture2099 - Hombre, eso es mucho odio. Pero eso sí, se da que la cultura de empresa y el tipo de trabajo son compatibles. Por ejemplo, un equipo Scrum establecido que trabaja en una base de código más antigua y realiza principalmente trabajo de mantenimiento. O una pequeña empresa emergente en la que todos tienen múltiples funciones. O una empresa que ha abrazado por completo la holocracia. Valoro la flexibilidad sobre la rigidez, tanto en el proceso como en el software.
@AndrewClear nadie dice que no valore la flexibilidad. La pregunta no es "¿Puede un desarrollador actuar también como usuario final principal en un escenario de desarrollo?". La pregunta es si un PO también puede ser un desarrollador y la respuesta en Scrum es... no. Si eliges adaptar Scrum, eso es admirable y doblo las reglas todo el tiempo. Simplemente no lo llamo Scrum ni etiquete a las personas como fanáticos. ¿Estás encarnando los valores ágiles? Seguro. ¿Estás haciendo Scrum? No.
Estás equivocado, lo siento. Aquí hay un enlace a la guía de Scrum: scrumguides.org/scrum-guide.html#team . Ahora vaya a leer la parte sobre el tamaño del equipo de desarrollo. Así que sí, todavía estarías haciendo Scrum. Si vas a ser un fanático, al menos RTFM.
Muéstrame la oración exacta que dice que el propietario del producto es miembro del equipo de desarrollo. ¿Dónde está? No me equivoco y varias personas te lo han dicho ahora; simplemente no estás dispuesto a aceptarlo.
@venture2099, del enlace publicado por Andrew Clear arriba, con respecto al equipo de desarrollo: "Los roles de Product Owner y Scrum Master no están incluidos en el recuento [del miembro del equipo de desarrollo] a menos que también estén ejecutando el trabajo del Sprint Backlog". En contexto, esto significa que el propietario del producto o el Scrum Master pueden considerarse parte del equipo de desarrollo si están realizando un trabajo de desarrollo. No comentaré si es o no la mejor práctica, pero usted pidió la oración exacta que dijo que podían, y creo que ahí está :)

Respuestas (14)

Es posible que un desarrollador también actúe como propietario del producto, pero no creo que sea recomendable. Aquí están mis 2 razones principales:

  • Puede crear conflicto de intereses.
  • Reducirá su salida como desarrollador

PO tiene que priorizar la acumulación (la parte qué) donde el equipo decide la cantidad de trabajo que se puede entregar en cada sprint (la parte cuánto). De manera similar, PO brinda retroalimentación sobre el sprint durante las reuniones de revisión del sprint y decide aprobar o rechazar el sprint que ha sido entregado por el equipo, lo que genera un conflicto de intereses.

Ser un PO necesita un compromiso frecuente tanto con el cliente como con el equipo para que todos tengan una visión alineada de lo que se debe entregar y cuándo. El PO debe estar disponible para responder las preguntas que surjan del equipo. Si su tiempo se divide entre el compromiso y el desarrollo, seguramente tendrá un efecto negativo en la eficiencia tanto para los roles de desarrollo como para los de PO.

Esto es lo que Roman Pichler tiene que decir sobre Scrum Alliance . El propietario del producto debe:

  • colaborar estrechamente con el equipo de manera continua para guiarlos y dirigirlos
  • gestionar la cartera de productos
  • responder a las preguntas del equipo
  • suministre realimentación
  • resultados del trabajo de cierre de sesión

Esto es mucho trabajo para una OP que requeriría toda su atención. Para equipos altamente alineados y de alto rendimiento, el rol de Scrum Master puede necesitar menos tiempo, pero un PO aún tendrá que dedicar una cantidad de tiempo similar independientemente.

En su publicación de referencia sobre Product Owners, el Sr. Pichler también dijo: "Le recomendé que liberara la mayor parte de su agenda y aplazara la mayoría de sus otros compromisos para tener suficiente tiempo disponible" para realizar sus responsabilidades clave como Product Owner. Un PO que está haciendo todo lo que requiere el rol no tendrá tiempo para desempeñar también el rol de otra persona.
Correcto, como dijo @ToddA.Jacobs, para mí, mucho más preocupante que los deberes de orden de compra que arrastran la producción como desarrollador es que los deberes de desarrollo en la práctica le impedirán ejecutar completamente los deberes de orden de compra, lo que tiene un efecto mucho más perjudicial porque la mala planificación es más peligroso que una mala ejecución.

La Guía Scrum es explícita en que esto está permitido:

Los roles de Product Owner y Scrum Master no se incluyen en este recuento a menos que también estén ejecutando el trabajo del Sprint Backlog.

Ojalá pudiera hacer +1 en esto unas mil veces. No estoy seguro de por qué la gente se confunde tanto en este punto.
Esta respuesta es la misma que ya se dio: pm.stackexchange.com/a/11501/27189

Si bien la Guía Scrum no establece explícitamente si el Scrum Master o el Product Owner son o no parte del equipo de desarrollo, son parte del Equipo Scrum:

El Equipo Scrum está formado por un Product Owner, un Scrum Master y el equipo de desarrollo.

Lo que infiere que tanto el Product Owner como el Scrum Master operan fuera del equipo de desarrollo.

Además, la Guía Scrum también establece:

Los roles, artefactos, eventos y reglas de Scrum son inmutables y, aunque solo es posible implementar partes de Scrum, el resultado no es Scrum. Scrum existe solo en su totalidad y funciona bien como un contenedor para otras técnicas, metodologías y prácticas.

El propietario del producto también es responsable de gran parte de la administración y la limpieza del trabajo pendiente, nuevamente de la Guía Scrum:

El propietario del producto es la única persona responsable de gestionar la cartera de productos. La gestión de la cartera de productos incluye: Expresar claramente los elementos de la cartera de productos; Ordenar los elementos en el Product Backlog para lograr mejor los objetivos y misiones; Asegurar el valor del trabajo que realiza el Equipo de Desarrollo; Asegurarse de que el Product Backlog sea visible, transparente y claro para todos, y muestre en qué trabajará el Equipo Scrum a continuación; y Asegurarse de que el Equipo de desarrollo comprenda los elementos del Product Backlog al nivel necesario. El propietario del producto puede hacer el trabajo anterior o hacer que el equipo de desarrollo lo haga. Sin embargo, el propietario del producto sigue siendo responsable.

Según la información anterior, diría que no se recomienda, y si lo hiciera, en realidad no estaría haciendo Scrum (según el documento mantenido por los fundadores). Habiendo dicho eso, ¿es inherentemente algo malo? No, simplemente no deberías llamarlo Scrum.

http://www.scrum.org/Scrum-Guides

http://www.youtube.com/watch?v=IyNPeTn8fpo

Solo para aclarar: PO y SM ciertamente son miembros del equipo Scrum, pero no son miembros del equipo de desarrollo.
De hecho, la guía Scrum establece que un Scrum Master o Product Owner puede considerarse parte del equipo de desarrollo. Esto aparece en la sección "Tamaño del equipo de desarrollo".
@DanSolovay: si se refiere a "El Scrum Master ayuda a todos a cambiar estas interacciones para maximizar el valor creado por el Equipo Scrum", creo que esto es un cambio con respecto a la iteración anterior de la guía, como la sección de tamaño del Equipo Scrum fue cambiado de otras maneras. Buena actualización.
@JoshBruce: No, en referencia a esto: pm.stackexchange.com/a/14570/16719 El lenguaje parece bastante claro de que esto está permitido. Cuando tiene sentido es una pregunta mucho más complicada, pero puedo pensar en varios escenarios, especialmente para proyectos internos con equipos pequeños (por ejemplo, herramientas de desarrollo de construcción). Lo principal que deja en claro la Guía Scrum es que cuando el desarrollador habla como propietario del producto, está hablando con una autoridad especial. Si los otros desarrolladores respetan esto, no veo un conflicto intrínseco.
@DanSolovay: disculpas, quise decir: "Los roles de Product Owner y Scrum Master no están incluidos en este recuento a menos que también estén ejecutando el trabajo del Sprint Backlog"; pegó la cita incorrecta.

Lamentablemente no. Un buen propietario del producto tiene mucho trabajo de coordinación con los clientes, soporte, gestión, lo que requiere mucho tiempo (y reuniones). Por lo tanto, solo queda una pequeña cantidad de tiempo para el trabajo de desarrollo y para estar con el equipo. Además, esta pequeña cantidad de tiempo será interrumpida por usuarios, clientes, gerentes, reuniones de todos modos.

Además, si el propietario del producto sabe demasiado sobre los detalles de implementación, puede llevar al equipo a una determinada dirección tecnológica y puede estar menos abierto a otras sugerencias.

La propiedad del producto requiere un tipo diferente de mentalidad. Incluso si uno tiene un PO y una mentalidad de desarrollador, cambiar entre ellos lleva tiempo y un gran esfuerzo.

Todos asumen que el PO estará codificando. ¿Qué pasa con la ejecución de casos de prueba manuales que fueron escritos por los miembros del equipo orientados a la prueba? ¿Qué pasa con la creación de pruebas de interfaz de usuario automatizadas? ¿Escribir nuevas pruebas unitarias en código heredado?
Si estamos hablando de Scrum, no veo la diferencia entre codificar y probar. Imagine que el PO comienza a codificar una prueba de aceptación, pero se le pide que se una a una reunión y luego tiene que escribir un informe de estado, etc. Independientemente del tipo de tarea, no puede concentrarse o involucrarse completamente en el trabajo del equipo.
Estoy de acuerdo con Zsolt: el PO no debería ser un programador. De hecho, puede funcionar incluso mejor si el PO no es miembro del departamento de desarrollo o TI. Si su empresa tiene un equipo de gestión de productos, es mejor obtener su orden de compra desde allí.

Algunas respuestas se refieren a la Guía Scrum cuando dicen que no. Sin embargo, de acuerdo con esa referencia, diría que no sería un problema para el SM y el PO desarrollarse, dadas las circunstancias adecuadas:

Los roles de Product Owner y Scrum Master no se incluyen en este recuento [el tamaño del equipo de desarrollo] a menos que también estén ejecutando el trabajo del Sprint Backlog.

Sí. PO es un sombrero como cualquier otro. La única combinación excluida es PO y Scrum Master.

Editar Sabiendo que la comunidad estaría vehementemente en mi contra aquí, corté la longitud de mi respuesta ya que realmente no me gustaba la idea de tener otra discusión con un fanático de Scrum. A ellos les diré esto: la guía de Scrum es muy explícita al decir que es muy explícita (vea las citas en la respuesta de Josh Bruce como evidencia). La Guía Scrum muy específicamente nunca dice que el PO no puede ser miembro del Equipo de Desarrollo.

Dicho esto, si su PO solo está ocupado el 20% del tiempo y es un desarrollador completamente calificado, ¿realmente me importa si va a hacer que deje de decir que estoy haciendo "Scrum" mientras sigo entregando valor a mi ¿clientes? No, no en lo más mínimo.

El propietario del producto es responsable de la economía del producto. Mientras él/ella esté cumpliendo con ese rol y su trabajo en proceso esté controlado, no veo ninguna razón por la que no deban agarrar un teclado.

Gracias por las ediciones (incluso si su punto de vista puede ser diferente al que otros tendrán con respecto a Scrum). No soy un experto en Scrum, pero siempre pienso en marcos como estos como algo para tomar y luego modificar para que se ajusten a sus propios requisitos y objetivos organizacionales. Claro, puede que no sea Scrum verdadero en ese momento, pero bien o mal, siempre he sido fanático de usar lo que sea que funcione.
Creo que su respuesta sería mejor sin la pequeña diatriba sobre la comunidad. Cíñete a los hechos y la información útil.
Mi "mini-vociferación" fue sobre los fanáticos de Scrum, y definitivamente no sobre la comunidad de Stack en general (tampoco estoy seguro de si 1.5 oraciones cuentan como una diatriba, pero meh).
Entonces, su brillante idea es tener 1 miembro del equipo de desarrollo responsable de la aprobación y el rechazo del resto del trabajo del equipo de desarrollo... permítanme comenzar con el aplauso lento. Genio. Debo ser Scrum Zealot. ¡La dinámica del equipo será increíble!
Sí, así es. Esto puede funcionar bien, dado el contexto y la cultura adecuados. Además, ¿por qué la hostilidad? Si no estás de acuerdo conmigo, bien. Realmente no hay ninguna razón para ser grosero al respecto...
La hostilidad es una reacción a tu actitud ridícula de que la "comunidad" de alguna manera no está dispuesta a aceptar tu genio y cualquiera que no esté de acuerdo contigo es un fanático. No aprecio tu actitud y he respondido de la misma manera. Lo que está sugiriendo puede funcionar en una pequeña fracción del equipo Scrum e incluso entonces, no es Scrum. Es un marco adaptado que usted mismo ha inventado. No es algo malo, pero deja de argumentar que la Guía Scrum lo recomienda de alguna manera. No lo es. En serio, ¿puedes honestamente no ver la diferencia?
Vea la respuesta de Dan Solovay a continuación. Cálmate, haz RTFM y que tengas un buen día.
lo he leído Muéstrame la oración que dice que el propietario del producto puede/es/debe ser miembro del equipo de desarrollo. Incluso un copiar y pegar será suficiente.
"Los roles de Product Owner y Scrum Master no se incluyen en este recuento a menos que también estén ejecutando el trabajo del Sprint Backlog". Esta declaración indica directamente "puede".

Si está buscando anécdotas, soy PO y desarrollador/arquitecto de un equipo. Esto es más por necesidad que por elección. Personalmente, lo encuentro bastante difícil, porque significa que no tengo la oportunidad de brindar el nivel adecuado de soporte de PO que mi equipo merece. No puedo dedicar el 100 % de mi tiempo al desarrollo y no puedo dedicar el 100 % de mi tiempo a ser el propietario del producto, por lo que ambos roles sufren.

OTOH, mi equipo es altamente productivo, posiblemente el equipo más productivo y feliz de la empresa. Entonces, como equipo, podemos hacer que funcione. Al final del día, eso es lo más importante, ¿no? Un equipo verdaderamente autoorganizado hará lo que sea necesario para realizar el trabajo.

Dicho esto, no recomiendo probarlo a menos que no tengas otra opción. A pesar de lo productivo que es mi equipo, me gusta pensar que seríamos aún más productivos con un PO de tiempo completo, ya sea yo o alguien más.

¡¡¡¡¡SI!!!!!

Veamos el espíritu de scrum

1) Enfócate en cómo ayudar, no en tu “trabajo”

2) Retrospectiva Iterativa, para Cambiar y Adaptar.

Así que pueden probarlo y ver cómo funciona, reflexionar sobre ello y decidir en grupo si es beneficioso. Recuerde que el rol del propietario del producto es organizar el trabajo atrasado y proporcionar dirección, así que asegúrese de que eso suceda de manera efectiva y no debería tener problemas.

Puedo decir que ejecuto scrum de forma independiente en proyectos en solitario todo el tiempo. ¿Es una especie de blasfemia que soy un miembro del equipo, maestro de ceremonias y dueño del producto? Son 3 roles distintos, pero solo finjo que soy 3 personas y los hago todos yo mismo.

Las personas que responden que no son solo fanáticos, el proceso define la flexibilidad y la adaptación. Puedes hacer lo que te convenga, que cambia de una situación a otra. Debes intentar que tu primer sprint sea puro, pero después de eso, la retrospectiva está destinada a invocar mejoras y cambios.

Incluso si hay inconvenientes al hacerlo, no significa que no puedas. Si esto se aplica a su proyecto y organización, entonces hágalo. Usar scrum no implica "apagarte el cerebro" y seguir reglas estrictas sin adaptarlas a tu caso.

Supongamos que el equipo de desarrollo está desarrollando un producto para ellos mismos. El PO podría estar fácilmente en el equipo. Puede que eso no se ajuste a la definición precisa de equipo Scrum, pero Agile no dice que tienes que usar Scrum. Equipos autoorganizados, así que organícense de la manera que funcione.

No, por supuesto, el PO no puede ser un desarrollador y viceversa. Scrum tiene que ver con roles y diferentes puntos de vista sobre la misma visión u objetivo. Además, la tarea que debe realizar un PO es totalmente diferente a la tarea que debe realizar un desarrollador.

Para brindar un buen producto es bueno que el equipo sea desafiado (creo que por eso se llama Scrum ) por el PO y viceversa.

Al proporcionar comentarios, el equipo también puede hacer que el PO piense en el producto o en las funciones que desea implementar. Entonces, debido a los diferentes puntos de vista, todos los participantes están evolucionando. Si un PO también fuera un desarrollador, no usaría este efecto.

Scrum se trata de entregar valor de forma incremental a sus clientes. Los roles, eventos y artefactos son simplemente el mecanismo que facilita esto. No pierda el bosque por los árboles, ¿o sus clientes realmente le pagan para ser un equipo Scrum que sigue las reglas del juego?
Estoy totalmente contigo. Pero creo que, si la separación no se usa como está escrita en el libro, también se podría decir 'Hagámoslo como un equipo normal con una jerarquía estándar'. Olvídate del scrum. Ya trabajé en un equipo scrum y tuvimos algunos problemas serios porque no nos apegamos al sistema de roles...
Para que conste, está permitido por la Guía Scrum. En la sección "Tamaño del equipo de desarrollo" dice: "Los roles de Product Owner y Scrum Master no se incluyen en este recuento a menos que también estén ejecutando el trabajo del Sprint Backlog". Sin embargo, si es una buena idea es otra cuestión. [Dan Solovay, Andrew Clear, Josh Bruce y el usuario 9015 también citaron esto en otros comentarios y respuestas aquí.]

El PO generalmente tiene otras responsabilidades pero, por supuesto, si cree que puede hacer una contribución como miembro del equipo de desarrollo, es de esperar que el equipo agradezca su aporte. Un riesgo es que la estructura de autoorganización plana del equipo se vea comprometida por tener a alguien que pueda ser visto como "primero" entre iguales. Creo que un buen PO querría hacer una distinción clara entre los momentos en los que tienen puesto su sombrero de PO y los momentos en los que trabajan como un desarrollador más en el equipo.

no lo recomiendo Los roles son muy diferentes. Al igual que el SM, el PO representa entidades comerciales (y sus perspectivas) que son distintas de las del equipo.

Después de pensarlo un poco más, simplemente diría: "La respuesta es no".

El PO es el enlace entre la empresa y el equipo, y representa la perspectiva de la empresa sobre lo que está sucediendo (como una "entrada" para el equipo), además de comunicar el estado a la empresa (como una "salida"). Y esa debe ser su ocupación de tiempo completo. Si intenta "también" ser alguien que escribe código fuente, realmente no puede aferrarse a esa objetividad. Cuando está escribiendo código fuente, inevitablemente comienza a ver todo en términos de código fuente, y esa es realmente la razón por la cual PO se formaliza como un rol separado.

¿Puede un Product Owner ser un desarrollador en Scrum?
RespuestasAquíPolítica de privacidad1y, 1v