Technical Product Owner

[Marc Florit]

Buenos días Comunidad,

Llevo tiempo dándole vueltas al enfoque de los Roles en Agile (o Scrum).
Siempre he partido de 2 premisas:
- En equipos inmaduros cuenta con los roles clave al 100% y diferenciados (1 rol = 1 persona = 100%)
- En equipos maduros los roles se difuminan y la responsabilidad de cada uno de ellos para a ser compartida por todo el EQUIPO. A parte de que el Scrum Master pueda jugar un rol menos "intrusivo" (si me permitís la expresión) y pasar a ser un punto de soporte periférico.

Dicho esto, estoy barajando hipótesis sobre cada asunción que damos como Ley, concretamente en lo referente al Product Owner como representante de NEGOCIO.
Es decir, si abogamos permanentemente por la colaboración entre Negocio y Tecnología, además de que debemos asegurar la visión compartida y el alineamiento de objetivos, es realmente clave que el Product Owner sea "alguien de Negocio"?

Si buscas en google han montones de referencias que debaten sobre esta materia. Me ha gustado especialmente el enfoque que se le da en este artículo donde crean explícitamente el rol de "Technical Product Owner":
https://www.techwell.com/techwell-insights/2013/09/how-agile-led-creation-technical-product-owner

Pero realmente os escribo para conocer vuestras opiniones y experiencias al respecto.


Muchas gracias por vuestro tiempo,

Marc Florit

[Jeronimo Palacios]

Hola Marc,

Me parece un tema muy interesante. Un par de ideas:

- Para hacer Scrum, tienes que tener los tres roles. Si no los tienes, entonces estás haciendo otra cosa. Los roles en Scrum no tienen que estar dedicados al 100%, pero tal y como dice la guía de Scrum, la dedicación tendrá un impacto en la productividad.

- El Scrum Master nunca pasa a ser periférico, es un rol clave para gestionar el proceso Scrum ya que a través del mismo, facilita la transparencia, inspección y adaptación. Quizás pase de un rol más leader a un rol más servant, pero sigue teniendo un papel clave.

- El Product Owner es un rol raramente buen entendido. El papel del Product Owner es, literalmente, "optimizar valor". Él Product Owner es el responsable de manejar el presupuesto, de financiar los sprints y de asegurarse de que el valor que obtenemos de los mismos es máximo. Para ello, tiene que jugar un papel importantísimo (y estar acogido) por la parte de negocio.

Después de leer el artículo, creo que lo que necesitaban no es un Product Owner, sino alguien que diera soporte al verdadero Product Owner. Es por eso que se insiste tanto en que haya un único Product Owner por producto y cualquier persona que sea necesaria para darle apoyo, con la nota importante de no llamarlo Product Owner.

Un abrazo,

Jero

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar una entrada en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para ver este debate en la Web, visita https://groups.google.com/d/msgid/agile-spain/2B14B9A4-1A12-4015-91B0-9AAB160C4ABD%40gmail.com.
Para obtener más opciones, visita https://groups.google.com/d/optout.

[Helder De Oliveira]

Los problemas que hemos encontrado con un enfoque técnico para el PO son básicamente tres:

• pérdida de visión de negocio, del uso final y práctico que se le dará a la solución
• historias orientadas no al usuario sino a los servicios, por consiguiente, una orientación subjetiva sobre la arquitectura
• desgaste del equipo en defender soluciones técnicas contra la visión técnica del PO, lo que en equipos inmaduros puede tender a una solución de "lo he hecho porque el PO así lo ha querido" y un PO con un gran escudo anti-bugs que dice "lo técnico es responsabilidad del equipo"

No lo veo muy sano, pero en proyectos legados la diferencia de lo técnico entre el PO y el Equipo no es tan clara, ya que suele ser un PO con el conocimiento de lo ocurrido técnicamente el que de consejos y guía.

Helder De Oliveira http://helder-de-oliveira.branded.me/

[Isidro López]

Hola a todos, hola Marc :-)

Durante mucho tiempo, yo también pensé que tener a una personal al 100% en el rol de SM o PO, sólo tenía sentido en equipos "inmaduros".

Sin embargo, hace un tiempo tuve la enorme suerte de trabajar en una empresa cuyos equipos de desarrollo tenían una nivel de madurez "ágil" enorme, y una productividad mayor de lo que haya conocido jamás.

Y en esos equipos vi cómo el SM y el PO, que eran personas dedicadas al 100% a dicho rol y con uno por equipo (1 SM y 1 PO), tenían trabajo más que suficiente (aportando valor, huelga decirlo).

El SM era un "team servant leader" en toda regla, no una niñera ni alguien que tenía que ir detrás de la gente para cuestiones básicas (tener foco en la daily o mover tareas en el tablero ya estaba muy superado), sino que se centraba en cuestiones de otro nivel que realmente ayudaban al equipo (comunicación no técnica con otros equipos, resolución de conflictos de diversa índole, retrospectivas de donde se sacaban mejoras serias, etc.)

Leer sobre un "PO técnico", honestamente, me ha puesto la carne de gallina :-) Evidentemente, cuanto más conocimiento tenga alguien, mejor, pero creo que deberíamos huir de pretender "crear" ese rol.

Los mejores PO que he conocido eran personas que apenas tenían conocimiento técnico (en algunos casos, ningún conocimiento técnico), era realmente personas de negocio al 100% centradas en el "qué" y en maximizar el valor producido por el equipo. 

Es más, ese rol pasó de ser un proxy del negocio a ser EL NEGOCIO. Hubo una reestructuración en la empresa por la que esa persona pasó a tener la potestad sobre la definición del producto (táctica, estrategia, todo). Y ese PO se encontraba dentro del equipo, incluso físicamente (cada equipo al completo tenía su propia sala de trabajo, lo cual por cierto mejoraba enormemente el foco).

Además, esos PO también eran personas presentes en todos los "rituales" de Scrum, con una transparencia bidireccional total, y que confiaban al 100% en el equipo técnico, que aceptaban un "no" (con explicación y alternativas), y que nunca discutían las estimaciones temporales de tiempo (aunque sí preguntaban cualquier duda que tuvieran y si algo no lo entendían, preguntaban "por qué" sin ánimo de juzgar ni poner en duda nada).

No creo que sea cierto (y mucho menos recomendable) que en un equipo "maduro" los roles se difuminen. Más bien creo que eso ocurre cuando el equipo CREE que es maduro (pero en realidad está lejos de serlo).

Honestamente, creo que estamos en el peligroso punto en el que todo el mundo se pone a hacer experimentos pensando que ya tiene superado "el Scrum de manual", creyendo entender qué es eso de "Scrum" (y dice "hacerlo") o qué es "ser agile"... cuando aún se está, en general, a años luz de eso :-( 

Un abrazo a todos :-)

Isidro

[Juan Ignacio]

> desgaste del equipo en defender soluciones técnicas contra la visión técnica del PO

IMHO esto es de lo mas anti-Scrum que he leido en mucho tiempo. ¿un P.O. con argumentos técnicos? Es como el chiste del perro verde.



--

Juan Ignacio Rodríguez de León
Móvil: 605 890514
E-Mail: euri...@gmail.com
http://www.elornitorrincoenmascarado.com/
http://descon2.com/

[Jose Manuel Beas]

Hola,

Doy fe de que es cierta la afirmación del artículo acerca de la difuminacion del rol de SM en un equipo que va madurando (en una organización que lo tolera, claro). Pero tengo otra opinión acerca del rol de PO.

Isidro lo ha explicado muy bien IMO. Yo lo resumiría como:

PO = Qué hay que hacer
Equipo = Cómo hay que hacerlo

Son roles (responsabilidades) que, en mi experiencia, conviene mantener en personas separadas si queremos que el trabajo fluya respetando los principios ágiles. El qué y el cómo son dos tensiones muy útiles pero muy difíciles de resolver por una única persona.

No quiere ello decir que otras configuraciones no puedan funcionar, pero como bien apunta Jerónimo, dejaríamos de hacer Scrum. Aunque haya vida más allá de Scrum, yo también opino que es bueno llamar a las cosas por su nombre.

Otra conversación sería si la PO es un rol (un conjunto de responsabilidades) cuyas actividades no necesariamente deben ser ejercidas por una única persona. Me refiero a cómo la PO puede/debe dejarse asesorar por otras personas en otras áreas (técnicas y de negocio) para priorizar el plan de trabajo de la manera más eficaz posible (optimizando valor).

Un saludo,
JMB

[Toni Tassani]

Marc,

Resulta muy interesante que en tu planteamiento has querido cuestionar "las asunciones que damos como Ley". Yo encuentro fundamental cuestionarlo todo, incluso Scrum y cada uno de los principios y valores. Pero los cambios que nos alejan del framework Scrum ya no son Scrum y no los debemos llamar así. Aunque no tienen porqué ser malos.

Scrum es un framework muy claro, y en él hay un único PO que es el que trata de maximizar el valor para el negocio. Y no tiene que ver con la madurez de los equipos, porque en los momentos de stress es cuando las cosas se ponen a prueba.

Te planteas que el PO no "sea" alguien de "negocio". No sé qué interpretas con "ser de negocio", pero definitivamente ha de ser alguien capaz de velar por el presupuesto, el mercado y el valor a entregar a los clientes. Que alguien técnico asuma ese rol no tiene porqué ser malo, pero tiene el riesgo de querer influir (o dirigir) en decisiones técnicas y romper los beneficios de la autoorganización.

La figura descrita en el artículo me suena a la figura de un arquitecto en otras estructuras, que es la que hace de puente entre negocio y tecnología. Scrum, como framework, no da respuesta a muchas de las "necesidades" que puedas encontrarte, y a muchos roles especializados como los de Solutions Architect, Technical Writer o Business Analyst. En cada implementación habrá que tener en cuenta el contexto y el framework, y buscar la solución más adecuada.

Cuando en mi anterior organización empezamos a hacer cosas cerca de Scrum definimos que en cada equipo habría un "Product Owner Tandem", una pareja de Product Owners, donde uno sería un Business Product Owner y el otro sería un Technical Product Owner. En nuestro contexto disfuncional esta solución resultó muy efectiva durante un tiempo, pero el mayor error que cometimos fue llamar a "eso" Scrum. Llegó un momento en que dejó de funcionar, resultó imposible reconducir y la palabra "Scrum" ya estaba contaminada.

Muchas gracias Marc por sacar un tema tan interesante.

Toni

--

Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a agile-spain...@googlegroups.com.

Para publicar en este grupo, envía un correo electrónico a agile...@googlegroups.com.
Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/CACg9TNqxkCqtdxMH5MS4ef%2Bir2efdk%2B7RHkOrULR_odzNVvVnQ%40mail.gmail.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

Toni Tassani
Blog http://alapamui.blogspot.com/

Twitter @atassani

[Jorge Uriarte Aretxaga]

(perdón si llega repetido, parece que tengo problemas con mi suscripción al grupo)

El debate de los nombres es eterno, si es Scrum o no, ya ha sido respondido.

Pero Marc era (creo que intencionadamente) algo ambiguo acerca de Agile/Scrum en su pregunta, aunque usara terminología Scrum para ello.

Marc y Toni sacan el concepto de "cuestionarlo todo", y yo soy el primer antidogmas en la fila, pero me gustaría centrar la pregunta:

Si el PO-técnico fuera la respuesta... ¿cuál sería la pregunta?

¿Cuál sería el contexto en que abordaríamos la preocupación de que "el PO sea alguien de negocio o no"?
¿Cuál el contexto que nos pide ese híbrido po-tech?

¿Es un problema de disponibilidad?
¿Es un problema organizacional?
¿Construye el equipo *su* producto o trabaja para otro (cliente, división, ...)?
¿Cuál es la "distancia organizacional", el gap entre el usuario destino real del producto y los constructores del mismo?

Mi opinión sobre la solución propuesta, casi seguro variará en función del problema a resolver, siempre y cuando no estemos atados a Scrum por obligación. Porque si este fuera el caso, la respuesta ya ha sido expresada en este hilo (aunque quizás habría otras preguntas que hacerse :) )

Abrazos y gracias por el debate!

[José Vázquez Sánchez]

Marc, un debate muy interesante, al igual que todas las aportaciones que se están produciendo.

Os voy a dar mi visión.

En una gran organización, es mucho más evidente la separación de "los de Negocio" de  "los de IT", y en base a mi experiencia en este tipo de organizaciones os voy a contar lo que opino y he vivido.

No es que en mi organización se haya implantado Scrum en toda su extensión, ni mucho menos :( , pero con mis experiencias con el framework en mi anterior equipo y con  las iniciativas que ahora se están lanzando ( por fin .. :) ) , creo que puedo aportar algo al debate.

Empiezo diciendo que yo no soy radical en que haya que usar Scrum a rajatabla, como algunos ya habéis comentado. Hay que usar aquello que en el contexto organizativo en el que vivas se adapte mejor a lo principal : entregar valor al cliente y generar beneficios para la organización. Obvio , ¿no?.  Pues a veces, muchas más de las desables,  no lo es... .Cada uno mira para su lado sin empatizar con los demás.

Asi pues, me da igual que sea Scrum de libro o Scrum adaptado. Lo que importa es que las personas tengan la cultura necesaria . Personas = Toda la organización , sean de un lado o  de otro.

Y ahí radica el problema : o conseguimos una alineación total entre lo que llamamos Negocio y lo que llamamos IT, o los problemas apareceran.

La ecuación Valor= ( Conocimientos + habilidades) * actitud , que leía hace unos días en un post ( creo que en iniciativavorpalina...) es critica para todo esto de lo que hablamos.

Los de Negocio que saben un huevo del negocio y tienen habilidades de negocio, si tienen una buena actitud hacia los técnicos, es un +1 

Los técnicos que saben un huevo de tecnología ( y también de Negocio , aunque no lo sepan todo ) y tienen habilidades de tecnología, si tienen buena actitud hacia los de negocio,  es un +1.

Asi pues : 

Si tienes la suerte de que el framework Agil se ha hecho pegajoso en tu organización y ha sido adoptado a todos los niveles, entonces tendrás un PO en toda regla y para mi ya no habrías más que decir.

Si aún no está implantado a todos los niveles y no has conseguido el nivel de interlocución necesario con esa otra parte "del Negocio" , entonces mi recomendación es la siguiente ( situación actual habitual) 

- Consigue en el lado Negocio a tu sponsor del Producto/ Business Analist / responsable de producto, proceso..  etc  y ayudale a entender porqué y para qué quieres hacer Scrum o algo que se le parezca. Esto cuesta y mucho , por experiencia, pero no por ello tienes que dejar de hacerlo. Si crees en ello, no cejes en el empeño.

- Consigue en el lado Técnico a alguien que sepa también mucho de Negocio y que tenga grandes aptitudes y actitudes  de liderazgo y de relación. 

- Establece un tamdem entre ellos dos : Business Process/Product Owner (BPPO)  + Technical Process/Product Owner  (TPPO)   jajaja ,me acabo de inventar dos roles ... ;)  . Va un poco en la línea de Toni.

Entre los dos, tienen que tener el foco en conseguir la mayor y mejor experiencia de cliente posible y una gran excelencia operacional ( con todo lo que conlleva a nivel de entrega de valor , está claro).

- A nivel del resto del equipo con SM y Team, doy por sentado que se aplica el Scrum que mejor se adapte al contexto organizacional ,  y la ecuación V=(C+H)*A , siempre es positiva ( y si no lo es, el SM tiene curro ) 

   Yo , sin embargo, apoyo que sea completo ya que las prácticas son interdependientes y solo si aplicamos todas ellas obtendremos todos los beneficios ( vamos , lo que dicen en todos lados, no descubro nada nuevo).

En resumen, si la organización ( no ya tanto el equipo ) es madura en agilidad , el PO es lo que es  y todos trabajan juntos, en perfecta comunión.. ( que jodido es ... pero hay gente que lo consigue )

Y si la organización no es tan madura, está empezando o quiere empezar , mi recomendación es  la de BPPO + TPPO con Actitud al cuadrado. 

Si este Tandem tiene como puntos de partida comunes :

• Poner primero al cliente en todo lo que hagan.
  
• Hacer las cosas sencillas. 
  
• Entrega de valor temprana.
  
• Fomentar la colaboración y la transparencia
  
• Entender los procesos End-to-end.
  
• Reconocer el talento y fomentarlo
  
• Mejorar las relaciones entre las personas.
  
• Trabajar todos los dias en mejorar el trabajo del dia anterior.
  

Entonces, me da igual como se llamen y lo que hagan .... 

No se si he desbarrado un poco, chicos... pero es que creo de verdad que por encima de Scrum y de sus roles  y cualquier otro marco ágil lo que hay son personas, relaciones y actitudes, y si todo eso funciona... lo demás , ¿ que más da?.

Gracias Mac, el tema de para mucho debate.

Un fuerte saludo.

 

Pepe Vázquez Sánchez

a11...@gmail.com

Foodies experiences in  http://www.agiletaste.com

Writing about Agile Project Management in   http://www.gestiondeproyectosit.es

My EBOOK : https://leanpub.com/Ofertasycontratacionscrum

My Twitter   @PepeVazquezS

es.linkedin.com/pub/jose-vazquez-sanchez/8/5b2/b50/

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/CAGZf_GAPtZ_iPnhf1BJ1DJjHVKTMOyq6Q-_T4JDfMBiSbSCc%2BA%40mail.gmail.com.

[Daniel Ceillan]

Hola Comunidad! (eso suena como si fuéramos hormigas)

+1 a lo expresado por Toni Tassani,

Y ahora arranco...

Si eres tonto y te conviertes al agilismo, serás un tonto-ágil. (normalmente uso una palabra más fuerte para explicar esto, pero lo suavizo para respetar la lista)

Haras sprints, tendrás un scrum master, postits de todos los colores, la scrum guide impresa en 20 idiomas, y la absoluta seguridad de que sigues las "reglas scrum" (escribir esto me descompone) y aún así, seguirás todavía muy debajo de la línea de flotación.

Todavía te falta mucho.

Esto es como la pirámide de maslow. No puedes pretender la realización espiritual (agile) si todavía no comes ni te vistes (condiciones básicas de trabajo, implementes o no agile)

Veo mucha gente intentando ser agil, cuando todavía no cubren aspectos mínimos del trabajo. Asi que eso es importante diferenciarlo, porque sino parece que el único tema en cuestión es "como ser agil" y parece que eso solucionará todo.

Por otro lado "product owner", "scrum master", "stakeholder" suenan como gente rica e importante. Sin embargo "developer" suena como menos importante. Y los developers son el rol más importante, de todos. Y los stakeholders no son necesariamente managers y clientes, pueden ser usuarios finales, que nada tienen que ver con el status quo.

Definir estos roles en un librito, y armar la discusión de "cual es su definicion para saber si lo estoy haciendo bien" en mi opinion es incoherente desde el principio. Porque ningún libro puede definir que es lo mejor para "pepe". Sólo "pepe" puede descubrir en su vida que es lo mejor para él.

Aunque comunmente diría, que el PO es un rol dedicado a tomar decisiones de negocio, el Dev es un rol dedicado a tomar decisiones técnicas, y el SM intenta cultivar coherencia, y ayuda a los otros a tomar decisiones de calidad.

Un saludo!

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/CAGEpV7%2ByR%3DVH8Bd%3D-YB3PAbQmM%2B9bTd4kGVY6%3DKV-R%2BjiTy5nw%40mail.gmail.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

Daniel Ceillan

Blog: www.agile-patterns.com

[Harringer]

Debate +1. Sigue vigente que se aprende más hablando con personas que leyendo libros.

Slds

Harald

Saludos, Harald Messemer Enzyme Advising Group 672456096

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/CACR7dFhTQvbUUuqth8Fd1t14TXjh38rdKnvBhqmyB%2B9-WXUxYQ%40mail.gmail.com.

[Juan Pérez]

Hola a todos!

Muy interesante debate. 

Yo puedo hablar desde la experiencia...

Desde hace tres años he trabajado como Proxy Product Owner  y he tenido la suerte de compartir esta aventura con dos tipos de Product Owner. Uno que que tenia una gran experiencia de negocio pero un background técnico importante el cual muchas veces le perjudicaba seriamente, poniendo el duda las estimaciones del equipo y permitiéndose el lujo de decir "eso son dos consultas SQL", abusando de poder y imponiendo su idea sin escuchar a nadie argumentando que "yo soy el product owner". Podeís imaginar que esto no acabo nada bien...

Después de este PO vino un chico de negocio puro, el cual no tenía ni idea técnicamente hablando pero confiaba en el equipo ciegamente y tenía unas soft skills muy buenas pero de alguna manera el equipo acabó diciéndole "tu eres el PO tu sabrás".

Yo como Proxy PO puedo decir que técnicamente no soy nada bueno pero tengo un equipo de desarrollo espectacular en el cual confío ciegamente y defiendo sus ideas hasta el final. El secreto para mi es tener un equipo balanceado, en el cual si hay alguna de las skills de un PO o un SM no las cumple como dice el libro, tengas alguien en el equipo que sea capaz de tomar el ownership y hacerlo él. 

Es sólo una opinión personal pero para mi lo mas importante es el EQUIPO al completo y no un rol definido. 

¿Alguno de vosotros ha trabajado con un Product Owner que sea igual de bueno en todo lo que propone Scrum? Yo todavía lo sigo buscándolo al igual que a mi me queda muchísimo camino por recorrer.

Un saludo enorme a todos,

Juan

[Angel Agueda]

Hola,

Quizás os resulte interesante conocer la propuesta que hace el framework DSDM 

http://www.dsdm.org/content/7-roles-and-responsibilities

Saludos,

Ángel Águeda

[Vicenç Garcia]

Muy buenas,

el miércoles tendré la suerte de volver a un proyecto en el que ya estuve involucrado unos cuantos meses y que es en el que he disfrutado más en mi vida por su agilidad (+profesionalismo, calidad, propósito, etc). En este proyecto el PO es totalmente de negocio (y venía de un entorno waterfall con muchas reticencias a una aproximación ágil) y encima está ayudada por un BA a tiempo completo. No veo a un PO técnico en ese lugar. 

Según lo que explica el artículo, el PO técnico está al tanto de cosas de negocio y de la solución técnica que se está utilizando. Creo que el PO es un rol que da para ser a tiempo completo (y más), con lo que estar al día del avance técnico del proyecto lo veo imposible.

Otra cosa de la que huiría es la de este rol es más importante que este otro. Para mi todos son vitales.

Un saludo,

ᐧ

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a agile...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/0121d3d5-0662-4b28-a092-1b2cac86ea4a%40googlegroups.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

Vicenç García

http://vgaltes.com

http://geeks.ms/blogs/devnettips
http://www.linkedin.com/in/vgaltes
http://www.twitter.com/vgaltes

[Xavier Albaladejo]

Hola,

En este hilo se ha aclarado muy bien y por diversas personas lo que implica el rol de Product Owner :)

De cualquier manera, me gustaría añadir algunos puntos que creo que pueden ayudar a que se entienda la relevancia del Product Owner en ciertos entornos complejos:

 - El Product Owner también se puede llegar a entender como un "Facilitador dentro del Negocio". Es el que garantiza que exista una prioridad compartida y harmonizada entre todos los stakeholders (incluso haciéndoles "challengins" de si lo que quieren priorizar realmente va a a aportar el valor que le indican). De esta manera se asegura que el equipo de desarrollo trabaja en lo más prioritario sin que nadie lo ponga en duda. Si estas decisiones de prioridad de Negocio se tomasen "desde el lado de IT", si hubiese alguna discrepancia, al final "la culpa" se la acabaría llevando IT. Es decir, es conveniente que lo que esté relacionado con valor de Negocio lo priorice Negocio, e IT sea su "compañero tecnológico" proporcionando su parte en la visión de la solución, coste, dependencias, riesgos... e incluso su opinión de Negocio :))

 - Bajo el mismo prisma de "Facilitador" en el lado del Negocio", el Product Owner también identifica e involucra a las personas necesarias para tener un buen feedback rápido de que lo que se está desarrollando es lo que realmente esperan la organización/stakeholders / usuarios finales.

 - Los dos puntos anteriores implican que la responsabilidad del Product Owner tiene que estar reconocida en la organización, necesita tener la autoridad para realizar esa facilitación y poder tomar decisiones, que no haya "overrides" inesperados y sistemáticos por parte de algún stakeholder o usuario. Eso implicaría que no está funcionando la colaboración con ellos, anterior a esas decisiones (comunicación, transferencia de conocimiento, confianza, etc.).

 - Adicionalmente, el Product Owner no puede perder el contacto con la estrategia de la compañía (tiene que estar alineado con ella y saber lo que va a venir), con la definición del modelo de negocio, con la caracterización/análisis de los diferentes tipos de clientes finales, con las incidencias de los usuarios en el uso del producto, etc. El Product Owner también tiene dedicar parte de su tiempo a estar involucrado en todo esto. Si quedase demasiado "enterrado" en la parte más "operativa" con el equipo de desarrollo, correría el riesgo de aislarse de la realidad del producto o, peor, de que lo aíslen de la parte de Product Management y que desde Negocio lo vean como una persona "de otra área diferente".

Con todo esto, se puede ver que ser Product Owner es una persona con unas buenas capacidades y un montón de trabajo "especializado" en el lado de Negocio (y que quizás le quede poco tiempo para conocer los aspectos técnicos de la solución). Así pues, tiene bastante sentido que en un equipo Agile de "especialistas generalistas" este rol de PO esté encarnado por una persona de Negocio, especialmente en organizaciones complejas y productos grandes :)

Espero haber ayudado un poco más en el tema ;)

--
Xavier Albaladejo
http://www.proyectosagiles.org

[César Ruiz]

Hola a todos.

Suelo ser sólo un usuario de "lectura", pero me ha encantado la definición y además es una figura que en el actual proyecto en el que estoy echo mucho en falta.

Gracias!

--
Has recibido este mensaje porque estás suscrito al grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este grupo y dejar de recibir sus mensajes, envía un correo electrónico a agile-spain...@googlegroups.com.
Para publicar en este grupo, envía un correo electrónico a agile...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/ed67f20b-dadf-42a3-b3dd-575631924546%40googlegroups.com.

[Israel Alcázar]

Hola,

Un hilo muy interesante la verdad. No me que queda mucho mas que añadir a las definiciones y matizaciones ya escritas. Me conecta mucho las aportaciones de Xavier Albaladejo sobre esa labor de "facilitación" en toda la parte de negocio.

Os comparto mi opinión basada en mi experiencia:

- Todavía no he conocido un equipo lo suficientemente maduro como para que la labor de SM o PO se vuelvan periféricas. Quizás he tenido mala suerte, quizás mi concepto de madurez es diferente a la que por ejemplo pueda tener Marc.

Creo que ambos roles son clave para conseguir una mejora grande de los resultados del equipo (que al final es lo que queremos haciendo Agile no?) cuando están focalizados en 1 persona (1 SM y 1 PO) el 100% del tiempo.

- Respecto al debate del Technical PO, lo que me he encontrado en muchos clientes es que ese PO fue hace muchos años (o no tantos) desarrollador y al final "la cabra tira al monte", es decir, tiende de forma mas o menos consciente o inconsciente a participar en decisiones técnicas del equipo lo que, a veces, no suele ser bien visto por estos y puede crear ambientes insalubres que hay que trabajar con mucho cariño.

- Si debe ser o no parte de negocio creo que depende en gran medida del tipo de proyecto /producto que se esté desarrollando. Me he encontrado equipos realizando productos muy técnicos que crean librerías o aplicaciones para otros equipos técnicos. Ahí la labor de un PO con conocimientos técnicos resulta fundamental para entender a todas las partes. Quizás en otro tipo de proyectos con una clara orientación al usuario / cliente tenga todo el sentido que este PO sea alguien que hable y sepa bien de negocio y facilite (como apunta Xavi) a todos los involucrados en el proyecto.

Por otro lado, por aportar algo diferente al hilo, uno de los principales problemas que me encuentro en las organizaciones con el rol de PO es que también suele ser el "jefe" del equipo. Esto implica temas como revisiones salariales, petición de vacaciones, aprobación de formaciones del equipo y un largo etcetera que hace que se establezca una relación jerárquica entre ellos (PO - SM - Team) lo que provoca muchas veces que no se tenga la confianza suficiente para rebatir la opinión del PO y otras muchas insalubridades :).

Ahí mis 2 centimos.

Saludos.

Israel Alcázar Rodríguez
israel...@gmail.com

--

http://thinkingwithyou.com

Foodies experiences: http://agiletaste.com

About me: http://israelalcazar.com

Twitter: @ialcazar

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/CAEguLu_XPSCu5sYs3-n7rYZbZ3tv%3D%3DQeg3By_BHUqEnmkRhYrA%40mail.gmail.com.

[Adrian Perreau de Pinninck]

Como bien recalca Israel un Product Owner tecnico puede tener mucho sentido si el producto es tecnico.

Yo mismo me encontre en esa situacion durante mas de un año como Program Manager del equipo que estaba desarrollando las herramientas de Continuous Delivery para un departamento de I+D de cientos de personas.

Obviamente, nadie de negocio hubiera podido llevar el rol de PO en ese contexto. Ya que los clientes y los stakeholders eran los mismos programadores y jefes de departamento.

Como bien dice Xavier, hace falta facilitar el consenso entre los stakeholders. En este caso, siendo tecnicos, hacia falta alguien tecnico con suficiente credibilidad para conseguirlo y una vision de negocio, que en este caso significa ser capaz de justificar economicamente la inversion.

Si que es verdad que requiere un gran esfuerzo facilitar todo este proceso manteniendose fuera del patio tecnico del equipo. Ademas de apaciguar la masa de ingenieros que opinan que se deberia estar haciendo de otra manera. Si no lo haces pierdes la motivacion del equipo por falta de autonomia. He aqui donde un buen scrum master es esencial.

Espero haber aportado una vision mas concreta de como podria encajar un PO "tecnico".

Saludos,
Adrian

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/CAKCURLxoNLK%2BZmwV%3DZ_C-uY1MGB7z745g2BfB3Y6-X_oH1tcGw%40mail.gmail.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

Improving your Mondays

[Xavier Albaladejo]

+1 Adrián ;) el PO representa a los usuarios finales y stakeholders, tiene que conocer sus necesidades y cómo operan el producto :)

--
Has recibido este mensaje porque estás suscrito a un tema del grupo "agile-spain" de Grupos de Google.
Para anular la suscripción a este tema, visita https://groups.google.com/d/topic/agile-spain/yKi7v3pqhYg/unsubscribe.
Para anular la suscripción a este grupo y a todos sus temas, envía un correo electrónico a agile-spain...@googlegroups.com.

Para publicar en este grupo, envía un correo electrónico a agile...@googlegroups.com.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/CAFSMUruFy3hmdVMzC5Ez%2B7gtXNQv3HW%3D_YKMio4D9eWuHohRyQ%40mail.gmail.com.

Para acceder a más opciones, visita https://groups.google.com/d/optout.

--

Xavier Albaladejo
http://www.proyectosagiles.org

[Marc Florit]

1000 Gracias a tod@s por vuestros aportes!

(echaba de menos a esta comunidad que es capaz de generar conversaciones super interesantes)

Todavia no he tenido tiempo de leer el hilo pero por encima percibo inputs enormemente interesantes.

Sí que es cierto que el hacer o no Scrum de un tiempo a esta parte se me ha tornado secundario en pro de crear un entorno de colaboración eficiente y efectivo.

Como bien subraya Jorge, cualquier aproximación estará supeditada al contexto por lo que ahí sacaremos nuestra mejor respuesta ágil: "Depende!".

+1 a la visión de Xavi del PO como Facilitador dentro de Negocio, aunque tal vez sería buena en esa "facilitación" poder aportar algo de visión técnica, ahí lo dejo ;)

Os dejo que no me da la vida.

Luego os leo con el cariño y detenimiento que merece e intento aportar.

Gracias,

Marc Florit

cramt...@gmail.com

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/CAFSMUruFy3hmdVMzC5Ez%2B7gtXNQv3HW%3D_YKMio4D9eWuHohRyQ%40mail.gmail.com.

[Isidro López]

Totalmente de acuerdo, pero para mí, si se trata del desarrollo de herramientas técnicas para un departamento de TI, ESO es "el negocio". No considero que sea necesario ponerle un adjetivo delante, porque por esa regla de tres, acabaríamos hablando de "Marketing Product Owner", "Financial Product Owner", etc.

Para ver esta conversación en el sitio web, visita https://groups.google.com/d/msgid/agile-spain/CAKo0HwZGFy1x_MV9h%3DzkvYi7WhYJOTCQS2xJ%2BJa%2BEDDJ%2BJovSA%40mail.gmail.com.

[Jose Manuel Beas]

No considero que sea necesario ponerle un adjetivo delante, porque por esa regla de tres, acabaríamos hablando de "Marketing Product Owner", "Financial Product Owner", etc.

+100

 

 

--

Un saludo,
Jose Manuel Beas

http://jmbeas.es

[Miguel Ángel Díez Bielsa]

He disfrutado mucho leyendo todos los mensajes. Gracias, Marc por abrir la espita y a los demás por vuestras aportaciones. Me han servido de mucho ya que en mi empresa, desde hace 5 meses hemos emprendido una "aventura hacia el Scrum" y es muy enriquecedor escucharos y aprender.

Gracias de nuevo.

El viernes, 16 de octubre de 2015, 14:38:58 (UTC+2), Marc Florit escribió:

[Gemma]

Hola Marc & CIA,

Como algunos ya sabéis he estado fuera unos añitos poniendo más foco a otros menesteres y hace un mes volví a España incorporándome de nuevo al mundo del agilismo del país. ¡Me encanta ver cómo ha crecido todo esto!

Marc, creo que el tema del PO es recurrente y quién más quién menos ha tenido sus inquietudes al respecto…

Quizá tengo un enfoque muy relativista, pero de verdad creo que la definición del rol, skills, funciones, % de dedicación… depende mucho del tipo de organización, del producto, del equipo y un largo etcétera.

De verdad no tiene mucho que ver el PO de una organización de I+D o de otra que haga sw financiero, de una PYME o una grande corporación multinacional, de una empresa que recién empieza con Agile a otra que tiene un nivel alto de madurez…

A menudo he estado en organizaciones donde el rol ha ido cambiando, adaptándose a necesidades del mercado, del equipo, de estructura (organigrama), incluso de la persona que lo ejercía.

En el fondo creo que la figura pretende evitar las grandes distancias que ha habido entre la parte técnica y el negocio (la definición de negocio también depende de cada proyecto/organización/fin…). Se trata de que el “gap” sea mucho menor y a poder ser que desaparezca. Creo que el reto es que cada organización / equipo encuentre qué le funciona mejor.

Creo que debemos hacernos las preguntas adecuadas: ¿para qué es el rol del PO?, ¿cuál es el fin?, ¿por qué Scrum le da tanta entidad?, ¿por qué se necesita? y ahí que cada uno vea cómo hace para alcanzarlo. Se podría crear otro hilo respondiendo a estas preguntas :-)

Un abrazo!

Gemma

PD: Aprovecho para hacer una pregunta de algo que me ha sorprendido un poco ¿dónde está el aporte femenino en este foro?, ¿no hay muchas agile coaches mujeres en España?, ¿o no participan mucho? con lo que nos gusta hablar a las mujeres... jeje :-)

El viernes, 16 de octubre de 2015, 14:38:58 (UTC+2), Marc Florit escribió:

[Alex Ballarin]

Compañeros,

he disfrutado leyendo vuestros argumentos, muy interesantes. Me he acordado de vostros cuando he visto esta posición the Technical Product Owner en Skyscanner.  No dan mucho detalle, pero igual os interesa leerlo. :-)

http://www.skyscanner.net/jobs/job/technical-product-owners/