Después del AgileFest, tuve una muy enriquecedora conversación con uno de los asistentes al evento con el que pude expresarle varios puntos sobre el rol del Product Owner, los cuales expresaré en este post.

El inicio de la conversación lo marcaron dos realidades:

• La adopción de Scrum es un esfuerzo organizacional intencional: Si no hay un "champion", "sponsor" en los altos mandos, es muy probable que el esfuerzo sea fútil. Si el valor de Scrum no es percibido en el upper-management, se está cuesta arriba. Al ser organizacional, los stakeholders experimentan una forma diferente de hacer las cosas. La adopción es arriba hacia abajo, no al revés.  Ahora bien, "de arriba hacia abajo" es la consecuencia, la causa es que alguien del upper-managament compró la idea. Tiene sus ventajas cuando todo empieza como un "grass-roots movement" o de “guerrilla” en las trincheras de ingeniería pues la inquietud llega arriba en algún momento y allí se puede convencer a alguien para que apoye la iniciativa para que entonces baje con respaldo.
• Fallar en concretizar el rol del Product Owner causa la mayoría de fracasos en adoptar Scrum. Y cuando digo "fracaso" me refiero que el proyecto no cumplió las expectativas, es decir, el proyecto falló.

Elaboraré un poco sobre el Product Owner, y trataré con mi explicación aclarar porqué no tener un Product Owner te lleva al fracaso (hey por eso hay certificaciones/cursos para llegar a ser un Product Owner, imagínese):
Mike Cohn en su libro Succeeding with Agile: Software Development Using Scrum menciona que el Product Owner tiene dos responsabilidades generales:

1. Proveer la visión.
2. Proveer los límites o condiciones, las restricciones.

La primera es generalmente clara, pero lo segunda se aborda muy poco.
Sin embargo la segunda responsabilidad es vital pues describe las realidades dentro de las cuales la visión debe concretizarse.
Los límites o condiciones vienen normalmente en la forma de restricciones:

• Lo necesito para Setiembre.
• Necesitamos reducir el costo por unidad a la mitad.
• Debe correr al doble de la velocidad.
• Debe usar solo la mitad de memoria que lo que usa ahora.
• Y por supuesto, una intrínseca, hasta obvia: No debe tener pulgas [bugs, defectos, seguiré llamándolos pulgas] según lo especificado.

Esas restricciones las da el Product Owner, pero a su vez son restricciones que fueron puestas sobre él por los stakeholders de una u otra forma.

El Product Owner jamás debe permitir que los usuarios finales reciban un "producto pulguiento". Esa restricción de ser claramente transmitida al equipo desde el día uno. Si en la primera iteración el equipo entrega incrementos [User Stories "completos" según el equipo] pulgosos, el Product Owner no los puede aceptar. Él es responsable por eso. Si hay un problema de habilidades [QA, buenas prácticas, diseño, etc..] en el equipo, eso debe escalarse inmediatamente. Usando Scrum, se detecta ese problema muy temprano si no se ha detectado en el momento de conformar el equipo.

Realmente el Product Owner pasa muy ocupado: Recibiendo requerimientos y coordinando con todos los stakeholders, actualizando el Product Backlog, confirmando que las restricciones se están cumpliendo.

Un buen Product Owner es aquel que complementa sus habilidades con Product Management. Como consejo:en algunos casos es más fácil decirle al upper-management que necesitamos un "Product Manager" en lugar de decir ocupamos un "Product Owner".

Espero ser claro en este punto: El equipo de desarrollo no puede transgredir los limites establecidos por el Product Owner, a menos claro, que esos límites sean absurdos, cínicos, imposibles. El equipo no anda por la libre haciendo lo quiere. El equipo debe complacer completamente las expectativas del Product Owner según las restricciones que él establezca.

Y atención: El Product Owner define el "qué" y las restricciones, el equipo define el "cómo". En el ámbito del "cómo" (de nuevo, según las restricciones) el Product Owner no tiene autoridad. El ScrumMaster ayuda al equipo a encontrar un "cómo" que mejore continuamente y lo lleve a ser hiper-productivo.

Product Management

¿Conviene tener un departamento o equipo de Product Management? La respuesta a eso depende si la institución debe crear varios productos de cierto tamaño los cuales deben obedecer a una estrategia institucional que se revise cada cierto tiempo.
Ser un Product Manager es una de las profesiones más difíciles pero importantes. Por eso es difícil encontrar alguien que quiera aceptar un puesto así. Debe construir un producto tomando como entradas:

1. La estrategia de negocio: "Durante este año iremos en esta dirección".
2. Las opiniones y requerimientos de los stakeholders, que a veces son varios: Muchos managers queriendo meter la cuchara.
3. La retroalimentación continua de los usuarios finales.
4. Las tendencias de mercado. Coordinar constantemente el departamento de ventas y el de mercadeo.
5. Requerimientos para cumplir con las leyes estatales y regulaciones institucionales internas.
6. Criterio técnico del equipo de desarrollo.

El éxito de un equipo de Scrum estriba dos factores:

• Product Managenement: Una buena definición del Producto y evolución del mismo.
• Project Management: Un ciclo de desarrollo de software iterativo incremental basado en la retroalimentación constante y la auto-regulación de un equipo multifuncional.