En scrum, ¿alguna vez tiene sentido contratar a un propietario de producto?

Resumen

¿Tiene sentido contratar a un propietario de producto externo a la empresa? Si lo hago, ¿qué habilidades deben tener?

Quizás. Una mejor pregunta es si alguien dentro o fuera de la empresa tendrá una mejor visión de un producto determinado. Personalmente, he tenido éxito como Product Owner externo y he visto a Product Owners internos tener éxito y fracasar. Así que la respuesta es, como siempre, "depende".

Análisis

La Guía Scrum describe el rol del Propietario del producto de la siguiente manera:

El Dueño del Producto es responsable de maximizar el valor del producto resultante del trabajo del Equipo de Desarrollo. La forma en que se hace esto puede variar ampliamente entre organizaciones, equipos Scrum e individuos.

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 del Product Backlog;
• Ordenar los elementos en el Product Backlog para lograr mejor los objetivos y misiones;
• Optimizar 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 de la cartera de productos al nivel necesario.

Hablando pragmáticamente, para gestionar el Product Backlog y optimizar el valor, un Product Owner necesita:

• una visión sólida y bien comunicada del producto; y
• suficiente conocimiento del producto, sus características y su propuesta de valor para poder priorizar características y definir objetivos iterativos para el Equipo Scrum.

En la práctica, esto significa que los mejores Product Owners tienen experiencia en el dominio del producto, y el Product Owner ideal también tiene experiencia con la empresa, sus partes interesadas y sus clientes.

Ninguna de estas cosas son, estrictamente hablando, requisitos iniciales para alguien asignado al rol. Un Product Owner puede crecer en el rol y puede obtener el conocimiento esencial durante el ciclo de vida del proyecto. Sin embargo, es probable que una persona que carezca de estas cosas comience como un Propietario del producto sustituto, en lugar de ser el verdadero tomador de decisiones del proyecto. Esto es contrario al espíritu de Scrum, que dice:

El Product Owner es una persona, no un comité. El propietario del producto puede representar los deseos de un comité en la cartera de productos, pero aquellos que deseen cambiar la prioridad de un elemento de la cartera de productos deben dirigirse al propietario del producto.

En algunos aspectos, el propietario del producto define el producto. Por lo tanto, es poco probable que tener un propietario del producto sin la visión o el conocimiento suficientes para impulsar el proyecto tenga éxito en el puesto. Además, es poco probable que un proyecto que carece de un rol sólido de Product Owner funcione sin problemas o que brinde el máximo valor.

Si bien todo esto puede apuntar a la noción de que un Product Owner debe provenir de una empresa, eso no es necesariamente cierto. A veces, una perspectiva externa de alguien que tiene un conocimiento profundo de un mercado o experiencia en la entrega de productos similares puede ser excepcionalmente valiosa.

Scrum es un deporte de equipo, y es difícil tener éxito cuando, si el equipo es corto, hay un jugador fuerte en un papel clave. Al final, "adentro" o "afuera" son menos importantes que garantizar que la persona que ocupa el puesto sea la persona adecuada con la combinación correcta de conocimientos y habilidades, además de ser la persona adecuada para la empresa y el Equipo Scrum.

TL;DR : probablemente no, a menos que traigan alguna experiencia clave que aún no tenía en su empresa.

Depende, la mayoría de los propietarios de productos que he visto en los equipos son lo que yo llamaría un propietario de producto proxy . Traducir las necesidades comerciales en historias y ayudar a las partes interesadas a priorizar entre ellas. Proteger al equipo mientras se comprende lo que significa la deuda técnica y se recopila suficiente conocimiento comercial para satisfacer las necesidades diarias del equipo Scrum. Aún así, preferiría a alguien de dentro de la empresa, incluso para este puesto, porque aporta conocimiento del dominio y tal vez pueda convertirse en un verdadero propietario del producto.

Un dueño de producto emprendedor. Alguien que posee el producto. Alguien que establece la estrategia y la visión. Probablemente no sea alguien a quien pueda contratar en la empresa. A menos que esta persona aporte el conocimiento de dominio experto que necesita para el producto que de otro modo aún no se encuentra en su empresa.

También depende de tu escala. Es posible que tenga un Propietario de producto principal y un par de Propietarios de producto de área . Deben ser dueños de su área o también son solo representantes.

Por lo tanto, para los propietarios de productos proxy y de área, puede contratar a un aprendiz rápido con experiencia en ser el propietario del producto Scrum para un solo equipo Scrum. Esto podría ponerlos en velocidad rápidamente. Esto podría tener sentido si tiene muchos equipos, digamos tres o más.

Si está buscando a alguien para hacer crecer su negocio y ser DUEÑO del producto, no podría ignorar sus habilidades actuales de Scrum, las podemos enseñar. El sentido comercial, el conocimiento experto del dominio y una buena sensación para la estrategia a largo plazo en su industria son un poco más difíciles de entrenar.

Definitivamente NO si es su primer propietario de producto, a menos que traigan algo realmente especial además de las habilidades de Scrum: una red de ventas, conocimiento profundo de la industria, financiación, etc.

He visto empresas Waterfall-Agile en Alemania que contratan propietarios de productos para dividir ideas en largas listas de epopeyas e historias. Estos son más analistas de requisitos comerciales. Una especie de propietario del producto proxy pero peor.

Por lo tanto, depende del tipo de propietario del producto que esté buscando, pero para un verdadero propietario del producto como lo pretendía Scrum. No, no tiene sentido.

TL; DR: Claro, ¿dónde más contratarías uno?

¿Tiene sentido contratar a un propietario de producto externo a la empresa?

Seguro Por qué no. Usted contrata a todo el resto de su personal fuera de la empresa, los propietarios de productos no crecen en árboles mágicos en el sótano. Es un trabajo como Scrum Master o Miembro del Equipo de Desarrollo. Necesitas uno, contratas uno.

Si lo hago, ¿qué habilidades deben tener?

Deben conocer Scrum (obviamente) y tener experiencia en su materia. Tampoco contrataría a cualquier desarrollador para desarrollar su producto. Si, por ejemplo, una empresa médica contrata, esperaría ver requisitos médicos opcionales, un fabricante de piezas integradas para automóviles puede querer tener experiencia en esa parte. Pero al final, eso vale para todos los roles. Cada dueño de producto está construyendo un producto para otros, los clientes. Comprender lo que el cliente quiere es una parte clave y el PO debe estar al tanto de eso y ponerlo en nuevas historias de usuarios todo el tiempo. Asumir que el PO podría venir con ese conocimiento ya existente es peligroso. Claro, las personas con experiencia tienen una ventaja inicial, pero aprender y adaptarse es una parte clave de su trabajo, por lo que cada OP potencial debería poder comenzar desde cero.

Todd A. Jacobs y Niels van Reijmersdal han proporcionado respuestas verdaderamente excelentes a una buena pregunta.

Aquí está mi giro:

Si tuviera que elegir entre

a) un OP experimentado de otra industria

b) un experto en la materia sin la menor idea sobre la propiedad del producto

¿cuál elegiría?

No creo que a) sea necesariamente la elección incorrecta. Un PO experimentado que esté preparado para cambiar de dominio ya sabrá que tendrá que ponerse al día muy rápidamente, ya que se trata de una curva de aprendizaje muy pronunciada. He trabajado con una persona que hizo esto con mucho éxito, el resto fracasó rápidamente.

Entonces, mi elección sería b), pero solo con la condición de que estén totalmente comprometidos con el aprendizaje de la propiedad del producto, que puede considerarse un subdominio por derecho propio. Creo que hay productos que requieren conocimientos de dominio que no se pueden aprender en el trabajo como PO. Por ejemplo, un producto utilizado por cirujanos necesita un propietario del producto que sea cirujano (o un experto en un dominio equivalente, suponiendo que sea posible) y no existe una vía rápida para convertirse en cirujano (¡esperamos!). Pero, ¿puedes encontrar un cirujano que esté interesado en el mundo de Scrum y Agile?

Mi 'prueba' es la temporada de conferencias. Hay una próxima conferencia para cirujanos: ¿puede su 'PO de carrera' apreciar lo que dicen los oradores lo suficiente como para impactar sus decisiones sobre el producto? Hay un conflicto de programación entre la principal conferencia para cirujanos y la mejor conferencia Agile de la temporada: ¿su 'cirujano-PO' elegirá la conferencia Agile para apoyar su aprendizaje?