Administrar un Product Owner en una organización que aún no es ágil

TL; DR

Realmente parece que el Scrum Master y el Product Owner se han tragado la trampa de la velocidad y la utilización. Rompe el ciclo.

Diseccionando el Rol del Propietario del Producto

El PO quiere saber cuántas horas tiene disponible el programador X durante cada sprint y exactamente qué hará con ellas.

No es asunto suyo en una tienda Scrum. Es parte del equipo Scrum, pero no está a cargo de la asignación de historias ni de la organización del equipo. Un equipo Scrum se organiza a sí mismo (cuando funciona bien), por lo que esto es un no-no.

Quiere demostraciones de características completadas al final de cada sprint[.]

Esto es legítimo. Una Sprint Review es una reunión estándar de Scrum y definitivamente forma parte del marco. Debe centrarse en características completas y visibles para el usuario, pero eso es algo así como un detalle de implementación. Lo fundamental es que la Revisión del Sprint es la oportunidad de mostrar al Dueño del Producto ya las partes interesadas lo que se completó durante el Sprint más reciente.

[S]i una implementación es más complicada de lo que esperábamos y algo no se hace, considera que hemos roto nuestro compromiso.

Tal vez, y tal vez no. Hay varios temas envueltos aquí. Mirémoslos.

1. El equipo debe tener una "definición de hecho". Si el Sprint Goal no se ha cumplido y el trabajo no cumple con la definición de hecho, entonces simplemente no está hecho. Nunca se hace parcialmente; en Scrum, "hecho" para una historia de usuario es todo o nada.
2. La advertencia al axioma anterior es si el Equipo y el Propietario del Producto redefinen cooperativamente "hecho" durante el transcurso de un Sprint. Si se encuentra en la mitad de un Sprint y se da cuenta de que no alcanzará el Objetivo del Sprint ni completará una historia, entonces debe involucrar de inmediato al Propietario del producto para discutir sus opciones.
3. Si el Equipo está ejecutando correctamente la Planificación del Sprint, entonces el Equipo se está comprometiendo con el Objetivo del Sprint y un conjunto de historias de usuarios. Por eso es importante estimar correctamente y no comprometerse demasiado.

Cómo manejar sprints fallidos o fallidos

Sin embargo, el PO se equivoca al hacer de esto un problema de culpa. El trabajo del Scrum Master es utilizar el proceso Scrum para gestionar las expectativas de todos durante y después de un Sprint fallido.

Si un Sprint está en peligro de fallar, el PO debe involucrarse lo antes posible. El propietario del producto tiene varias opciones:

1. Trabaje con el equipo para redefinir el Sprint Goal o las historias de usuario aceptadas para recuperar el valor del Sprint.
2. Termina el Sprint antes de tiempo para que una Retrospectiva del Sprint y una nueva sesión de Planificación del Sprint puedan reiniciar el proceso ahora que todos tienen más información.

Ninguna opción debería ser un "juego de culpas". Tener que renegociar o reiniciar un Sprint es algo común en Scrum, especialmente con equipos que son nuevos en la estimación. Por lo general, es el resultado de algunos o todos los siguientes:

• Impedimentos del proceso que no fueron previstos o incluidos en las estimaciones de la historia.
• Estimaciones erróneas de una o más historias de usuario.
• Un Sprint Goal demasiado ambicioso.
• Compromiso excesivo durante la planificación de Sprint debido a estimaciones incorrectas de la historia, sobreestimación de la velocidad del equipo, antipatrón de "utilización del 100%" , tener historias asignadas al equipo (en lugar de que el equipo haga sus propios compromisos) o cualquier otra razón que coloca más historias en el Sprint Backlog de las que razonablemente se pueden completar en un solo Sprint.

Antipatrón de utilización

El antipatrón de utilización al 100% es lo que más me preocupa. Dices que el Product Owner dice cosas como:

Bien, tenemos 40 horas de trabajo por persona para Arthur y 32 horas de trabajo por persona para Candace, y dado que se supone que cada uno debe trabajar a medio tiempo en este proyecto, deberían terminar ese trabajo al final del próximo sprint.

Esta es una doble falacia. Primero, el Propietario del Producto no puede estimar el trabajo-esfuerzo para el equipo. Su función es priorizar las historias y trabajar con el resto del Equipo Scrum para ajustar el alcance o las fechas de entrega para cumplir con los requisitos comerciales en función de las estimaciones del Equipo sobre la cantidad de trabajo involucrado.

En segundo lugar, un Scrum Team exitoso se autoorganiza. Si el propietario del producto está asignando trabajo, intentando implementar una utilización del 100 % por persona o microgestionando de otro modo los procesos dentro del Sprint del equipo, entonces el Scrum Master debe:

1. Educar al Product Owner sobre los beneficios (y limitaciones) del proceso.
2. Asegúrese de que el equipo no se comprometa demasiado.
3. Entrenar al equipo para que se organice de la manera más eficiente posible en torno a los Sprint Goals aceptados. Esto no tiene nada que ver con la utilización y todo que ver con la propiedad compartida y los compromisos voluntarios .

El objetivo de Scrum no es maximizar la velocidad de las funciones o la utilización de los recursos; el objetivo de Scrum es administrar el Cono de Incertidumbre involucrado en proyectos grandes o complejos, y crear un ritmo de trabajo sostenible basado en estimaciones de historias cada vez más confiables. En otras palabras, la confiabilidad y la consistencia triunfan sobre la velocidad; la velocidad evoluciona a medida que los procesos, las prácticas de estimación, la automatización y el flujo de trabajo mejoran con el tiempo.

En un entorno verdaderamente ágil, ¿el PO llega al nivel de decir cosas como: "Está bien, tenemos 40 horas de trabajo por persona para Arthur y 32 horas de trabajo por persona para Candace, y dado que se supone que cada uno debe ser la mitad de tiempo en este proyecto, deberían terminar ese trabajo al final del próximo sprint". ??

Bueno, en un entorno Scrum, o en cualquier otro entorno de proyecto, el propietario del producto no debe estimar las tareas de los desarrolladores. Las personas que realizan el trabajo deben proporcionar estimaciones, especialmente al descomponer las historias en tareas. Esto es aún más importante en Scrum, donde el equipo se autoorganiza.

Además, dado que recién está comenzando, es probable que no tenga un control sobre la velocidad del equipo (cuántas historias puede implementar el equipo en una iteración) y esto hace que la declaración del propietario del producto sea aún más ridícula.

En mi grupo, los propietarios de productos son responsables de lo que vamos a hacer y los equipos son responsables de cómo se va a hacer.

Está perfectamente bien que el propietario del producto comparta una opinión, pero no se debe confundir las estimaciones con el objetivo.

Puede ser el momento adecuado para que su grupo revise los 10 errores mortales del desarrollo de software . :-)

Descripciones de funciones... o la falta de ellas. Las descripciones de roles mal redactadas causarán estragos en sus capacidades.

Si este PO está fuera de sus límites con el enfoque en las horas realmente depende de cómo su organización defina el rol. Apuesto a que podría obtener algunas opiniones inconsistentes al examinar este sitio. Pero al final del día, se convierte en cómo su organización define los límites de cada función.

Hablando de límites, esto a menudo se pasa por alto cuando se redactan descripciones de funciones. La mayoría solo escribe a las responsabilidades. Se olvidan de responsabilidades y límites.

Debido a que se está quejando, parece que el PO está sobrepasando su percepción de dónde está el límite entre su rol y el rol del líder del equipo ágil.

No se encuentra su respuesta sobre lo que es correcto en un entorno ágil; se encuentra estableciendo adecuadamente descripciones de roles firmes para la organización.

Entendimiento común ágil

En resumen, las metodologías ágiles como Scrum o XP suelen dividir las responsabilidades en 3 partes:

1. el equipo multifuncional : todas las personas (desarrolladores, evaluadores, integradores...) necesarias para lograr el trabajo real del proyecto. Por lo general, son autoorganizados, lo que básicamente significa que no hay nadie fuera del equipo que asigne el trabajo a los miembros individuales del equipo . Se comprometen con el trabajo que pueden hacer en cada iteración (para metodologías centradas en la iteración como Scrum. Puede ser un poco diferente con equipos centrados en el flujo como en Kanban)

2. el entrenador : llamado "Scrum Master" en Scrum, es responsable de la parte CÓMO. Conoce la metodología y cómo aplicarla. Su trabajo consiste en ayudar tanto al propietario del producto como al equipo a trabajar juntos. No es un director de proyecto en el sentido clásico del término y no asignará trabajo ni impondrá sus decisiones .

3. el propietario del producto : llamado "cliente" en XP, es responsable de la parte QUÉ. El propietario del producto es el representante de las partes interesadas. Para el equipo, su función consiste en proporcionar un conjunto priorizado de elementos para trabajar (características, historias de usuarios, etc.). Para las partes interesadas, su función es informar sobre el progreso del proyecto. El propietario del producto suele trabajar a tiempo completo en el proyecto y está fácilmente disponible para el equipo.

Entonces, si usted, me refiero a su empresa, equipo, OP, etc., decidió explícitamente utilizar dicha metodología, pero no lo hizo, no debe haber dudas sobre cuál es la responsabilidad de todos. En este caso, el Dueño del Producto no debería (tener que) lidiar con la parte CÓMO en absoluto.

El papel de un Scrum Master es importante aquí, ya que se asegurará de que nadie cruce la línea. Para una respuesta centrada en Scrum, también debe leer la pregunta " ¿Por qué el maestro de scrum y el gerente de proyecto no pueden ser la misma persona? ", que presenta respuestas muy interesantes.

Definición de roles

mi equipo de desarrollo de 20 personas ganó un Product Owner

Mi comprensión de su pregunta es que el propietario del producto se dejó caer en su equipo deus ex machina . Si entiendo bien, puede haber un malentendido en la definición de roles que debe tratar de aclarar. La respuesta de David Espina es bastante clara aquí en este punto. "Product Owner" es solo un nombre después de todo...

Gerente de Proyectos Clásicos

El PO quiere saber cuántas horas tiene disponible el programador X durante cada sprint y exactamente qué hará con ellas.

Si su OP solía ser un administrador de proyectos de comando y control, es posible que tenga problemas para convertirse "solo" en un PO. Está acostumbrado a tener muchas métricas relacionadas con el trabajo individual que le permiten monitorear el progreso del proyecto. Trate de entender por qué quiere recopilar estos datos y cómo podría proporcionarle indicadores relevantes que lograrían el mismo rol pero a un nivel superior (velocidad, rendimiento, tiempo de ciclo, etc.)

También podría querer asegurarse de que todos estén 100% cargados. Consulte la respuesta de CodeGnome sobre ese punto. Lea también el artículo de Pawel Brodzinski A Myth of 100% Utilization .

Confianza

"Está bien, tenemos 40 horas de trabajo por persona para Arthur y 32 horas de trabajo por persona para Candace, y dado que se supone que cada uno debe trabajar medio tiempo en este proyecto, deberían terminar ese trabajo al final del próximo sprint. "

Si su Dueño de Producto a menudo quiere llegar a este nivel, entonces podría haber un problema de confianza entre él y usted. Tal vez su falta de experiencia con proyectos ágiles, su experiencia con proyectos no ágiles o un posible compromiso roto al principio del proyecto lo hace reacio a confiar en usted y en su equipo. Bajo la presión del negocio, es posible que quiera "hacerlo él mismo".

En esta situación, desea resolver las cosas rápidamente, ya que es probable que esta falta de confianza mate su proyecto.

Resumen

¿Es legítima mi declaración anterior sobre el papel del PO?

En términos absolutos: sí. Su definición de propietario del producto es muy "scrumy". Pero la cuestión es que obviamente hay un malentendido en alguna parte, ya sea sobre el papel del otro, o sobre las habilidades del otro, o sobre el objetivo del otro, etc. Asegúrese de que ambos estén en la misma página en esta pregunta.