Trabajo en equipo con Scrum Masters y Scrum Developers

Clase 7 de 12 • Curso de Fundamentos de Product Owner

Clase anteriorSiguiente clase

Arles A. Pinzon Molina

student•

Los 4 valores que salen en el manifiesto ágil:

🤝 Individuos e interacciones sobre procesos y herramientas.
📲 Software funcionando sobre documentación extensiva.
↔️ Comunicación con el cliente sobre negociación contractual.
💥 Respuesta ante el cambio en lugar de seguir un plan.

Felipe Bernardo González Barranco

student•

:clap: :clap: :clap:

Joan S.TrianaV

student•

TRABAJO EN EQUIPO CON SCRUM MASTERS Y SCRUM DEVELOPERS

Los 4 valores que salen en el manifiesto ágil: • Individuos e interacciones sobre procesos y herramientas. • Software funcionando sobre documentación extensiva. • Comunicación con el cliente sobre negociación contractual. • Respuesta ante el cambio en lugar de seguir un plan.

Los agilistas se enfocan en individuos e interacciones sobre procesos y herramientas, no quiere decir que no se tengan procesos y no se usen herramienta, sino que para que un proceso sea efectivo, sus interacciones deben de ser de calidad y para que una herramienta cumpla su objetivo las interacciones con la herramienta son fundamentales.

Como Product Owner interactuamos mucho con diferentes perfiles, el principal objetivo que se tiene es representar la voz del cliente y hacer que se cuide, por ello, todas nuestras interacciones, todas nuestras acciones deben traer claridad, porque como Product Owner se es responsable del ¿Qué?, y este ¿Qué? Debe estar claro, y en todas las interacciones se debe de alimentar esa claridad.

La principal medida de progreso y avance es el Software funcionando, la documentación es importante pero no la extensiva o la documentación de justificación o burocrática, la documentación que se cuida es la que se enfoca en entendernos, documentar para crear una base de conocimientos que sirva para crear producto y tomar decisiones de acciones.

Los contratos son muy importantes pero la parte colaborativa es la que se procura cuidar, en la parte de colaboración con el cliente, es donde el Product Owner tiene la parte más activa porque representa al cliente, su voz, su opinión dentro de los equipos.

La agilidad es planeación a corto plazo con visión a un objetivo de largo plazo, el Product Owner cuida que cada uno de esos planes a corto plazo realmente estén enfocados al objetivo mayor y ayudar al equipo a poder adaptarse para responder a los cambios. La mejor manera de que un Product Owner pueda ayudar a responder al cambio, es explicar el origen y contexto del cambio, que al equipo le quede claro cual es el origen del cambio para poder establecer una mejor solución.

Principios fundamentales del manifiesto ágil en función del Product Owner:

• Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de software con valor: nos orienta al cliente, tener una entrega lo más temprano posible, no esperar tener un producto perfecto porque este no existe, el valor se va creando y el Product Owner máxima el valor y asegura que se pueda entregar y sobre todo recuerda para quien estamos trabajando. • Los responsables de negocio y los desarrolladores trabajamos juntos, de manera cotidiana durante todo el proyecto: se debe romper la jerarquía, se debe unir, trabajar sin intermediarios pero con moderadores. • La atención continua a la excelencia técnica y al buen diseño mejora la agilidad: el buen diseño y la excelencia técnica viene de un buen análisis, ese análisis y especificación proviene de los Product Owners, crear entornos de análisis colaborativo y poder todos cuidar la excelencia técnica y el buen diseño. Lo técnico no solo es influido por el equipo de desarrollo de software, es influido por la especificación también.

En el marco Scrum, interacciones principales que se van teniendo:

• Cuando se tiene un Backlog o pila de producto, en esta creación de backlog se debe tener en cuenta la perspectiva del equipo, por lo tanto acá ya se empieza a interactuar. • En el primer evento de scrum, sprint planning o planeación del spring se activa la planeación y estimación colaborativa para poder elegir con que elementos de trabajo se va a enfocar en el sprint siguiente. • Día a día pueden surgir cosas, lo que se desea que ocurra es avance, en algunas ocasiones ocurren impedimentos que hacen más lento o bloquean el equipo, el Product Owner puede ayudar a clarificar si es que algún impedimento tiene que ver con una especificación o con un tema de priorización y mientras el equipo va desarrollando los elementos de trabajos elegidos en la planeación el Product Owner esta refinando los elementos de trabajo que vienen para tener listos los elementos de trabajo que siguen en el próximo sprint. • Se acaba el sprint de desarrollo, y se revisa que se hizo, en la revisión del sprint el Product Owner se encarga de invitar a otros involucrados de la empresa u otros involucrados relevantes para que juntos hagan la inspección de que fue lo que el equipo trabajo, el Product Owner también debe participar de las daylis lo más que se pueda. • Antes de irse a planear otra vez, se debe de hacer una retrospectiva donde el equipo analiza las mejoras en función a como nos comunicamos y como estamos trabajando juntos.

Marylin Giugni Ortega

student•

Los conflictos que obsevo en el escenario 2, está el enfoque o la prioridad que le están dando al aplicativo, y se están ubicando cada uno en su área y sin intersección.

Yeni Alexandra Espinosa

student•

En el escenario 2: Se nota el conflicto de que los responsables del negocio y el desarrollo de la solución, cada uno trabaja por su lado y no hay trabajo en equipo. Están dejando de lado el valor de individuos e interacciones sobre procesos y herramientas, ya que están pensando solo en la herramienta.
En el escenario 3: Están cometiendo un error al dejar por fuera a los encargados del análisis funcional lo que puede afectar al cliente final ya que la apliación puede no cumplir con los requisitos necesarios

Marylin Giugni Ortega

student•

En el escenario 3 se está dejando fuera de las reuniones a los que participaron en el análisis funcional, por lo tanto se podría tener un producto que no cumpla con los requerimientos

Jonathan Quiros Barquero

student•

Escenario 3: Equipo con experiencia mixta y poca cultura ágil

Algunos miembros nunca han trabajado con Scrum.
Falta de cocreación UX + Dev (Santiago aislado del front-end).
Sandra actúa como líder técnica, pero también empuja la facilitación.

➤ Conflictos que se pueden generar:

Resistencia al cambio y falta de entendimiento del rol Scrum
- Devs esperando instrucciones en vez de autoorganizarse.
- Sandra cargando con decisiones que deberían ser colectivas → equipo no se empodera.
Colaboración fragmentada
- UX (Santiago) y front-end no trabajan juntos desde el inicio → retrabajo.
- QA y Dev involucrados tarde → bugs en etapas finales.
Problemas en ceremonias Scrum
- Retrospectivas poco efectivas (falta de confianza → no hablan de problemas reales).
- Daily Scrums usados como status report → pérdida de valor.
Desmotivación / baja moral
- Si algunos sienten que no aportan o que no se les escucha, baja la participación y aparecen tensiones personales.

Solución Agile:

Reforzar la figura de Scrum Master (Sandra debe enfocarse más en facilitar y no en dirigir).
Implementar dinámicas de colaboración UX–Dev (Design Studio, prototipado conjunto).
Fomentar seguridad psicológica en retrospectivas (ej. votaciones anónimas, formatos visuales).
Coaching ágil inicial para madurar al equipo en la práctica de Scrum.

David Esteban Urrutia Rodríguez

student•

Me ha encantado este curso! Profe Vanessa pregunta, Soy nuevo en el rol de product owner y no tengo aún conocimientos muy técnicos sobre desarrollo de software... es una buena idea invitar a los desarrolladores a las charlas con los clientes? con el fin de que ellos puedan de primera mano entender el requerimiento en aspectos tecnológicos pero adicionalmente dar una luz sobre si es viable o no? quedo atento, mil grtacias!

Dani Landa

student•

¡Hola David! Puedes elegir a un jefe técnico que te ayude con esa cuestión. Adicional, puedes tomar los cursos de Platzi para que te ayuden a fortalecer tus habilidades técnicas. ¡Saludos!

Vanessa Amaya

teacher•

Hola David!

En este nuevo camino que inicias como PO necesitas entender el mundo de tu cliente y el mundo del desarrollo de software, por lo tanto te recomiendo:

Acercarte mucho a los desarrolladores, expliques lo que se necesita y entiendas la complejidad de lo que solicitas a partir de las conversaciones con los desarrolladores.
Por lo que escribes, entiendo que estás en un esquema donde tú eres PO del lado de proveedor y tienes un cliente. Si esto es así, las reuniones de entendimiento del Producto iniciales, las puedes hacer solo tú. Tú eres el filtro de entendimiento para el equipo, ahora que cuando ya sean las entregas, en los Sprints Reviews donde se le entregue al cliente, llévate a todo el equipo. Si el cliente tiene un equipo técnico con quien tus desarrolladores necesiten interactuar, ayuda a que esto suceda.

mhalabi

student•

Sin iniciar / Blackloge o pila de producto. Qué tiene que tener como características un elemento de trabajo para poderlo tomar y pasar a en proceso.

Sprint backlog / sprint planning: activamos la planeación y estimación colaborativa para poder elegir con qué elementos de trabajo nos vamos a enfocar en el sprint siguiente.

Daily Scrum: día con día ocurren cosas e impedimentos que hacen más lento o bloquean el equipo. Impedimentos con especificación y priorización. PO refina los requerimientos para tener listos los elementos de trabajo para los próximos sprints.

Sprint review: Ver qué fue lo que hicimos. PO se encarga de invitar a otros involucrados para que juntos hagan inspección para que vean como el equipo trabaja. Involucramiento diario. Retrospectiva: Todos los partidos están involucrados en para interactuar.

en proceso: cuando un entregable lo empiezan a hacer realidad. Qué criterios tenemos que tomar en cuenta para llegar a terminado. Verificar que algo se terminó y puede ser entregado. (está en cero por ciento porque no está terminado).

En pruebas:

Terminado: Conjunto de terminados.

Jorge Abraham Maldonado Bazán

student•

Esta es una de las mejores clases de este curso, y de los cursos disponibles de SCRUM.

Silvia Isabel Lozano Argel

student•

Reto: Que clase de conflictos puede haber dentro de las interacciones de roles principales en escenario 2 y 3 : En el escenario 2 Susana y Sergio han escogido diferentes enfoques en cuanto a público objetivo de la app para las estrategias de marketing y para la priorización de requisitos a desarrollar. En el escenario 3. Santiago no se esta relacionando con Luz y Gustavo para no hacer reuniones muy largas que le pudieran quitar mucho tiempo en la creación del diseño de experiencia de usuario lo cual puede generar desconexion y reprocesos mas adelante.

Maria Alejandra Naranjo

student•

Definitivamente, me encanta este curso!

Manuel Lopez

student•

En el escenario 2, estan trabajando individualmente en una estrategia en lugar de discutirlo. En el escenario 3, se esta dejando por fuera parte del equipo durante el desarrollo del producto que puede acarrear consecuencias como un producto sin un MVP o sin testear

Eleonora Peña Rodriguez

student•

Las historias de usuario son fundamentales en el rol del Product Owner (PO) dentro de Scrum. Estas permiten capturar los requisitos desde la perspectiva del usuario, facilitando la comunicación entre el equipo y las partes interesadas. El PO es responsable de definir, priorizar y gestionar estas historias para asegurar que el desarrollo se alinee con las necesidades del cliente y del negocio. Esto no solo mejora la calidad del producto, sino que también ayuda en la planificación y ejecución efectiva del trabajo del equipo.

Juan Carlos Javier Vargas

student•

Estimada profesora Bajo su experiencia ¿Cómo el PO podría involucrase sin afecta la comunicación entre el equipo de desarrolladores? -Entiendo que la última versión de la guía Scrum indica que los dayli para los desarrolladores pero sin obligar a que cualquier otro como el PO pueda asistir (y no participar) -Además de su asistencia que puede afectar en la comunicación de los desarrolladores y esto puede romper con el pilar de transparencia y con el valor de coraje (por no decir la verdad sobre los errores que pudieron tener).

Y si me puede dar una recomendación de donde llevar el programa y donde certificarme como Agile Coach y/o Líder agile.

Muchas Gracias

Jonathan Quiros Barquero

student•

Escenario 2: Desalineación inicial (marketing vs ventas)

Susana (Marketing): enfocada en el consumidor final, quiere una experiencia impecable y atractiva.
Sergio (Ventas): enfocado en los ejecutivos de crédito, necesita rapidez y cumplimiento normativo.

➤ Conflictos que se pueden generar:

Prioridades encontradas en el backlog
- Marketing pide features de UX/UI llamativos → no generan valor inmediato.
- Ventas pide validaciones de crédito estrictas → más técnicos y urgentes.
Criterios de éxito distintos
- Marketing mide “adopción del consumidor final”.
- Ventas mide “agilidad en aprobación de créditos”.
Falta de visión compartida de producto
- Riesgo de que cada área empuje hacia su propia agenda → backlog caótico, entregas incoherentes.

Solución Agile: El Product Owner (Sergio) debe alinear objetivos de negocio, priorizar lo que aporta valor al usuario principal (ejecutivo de ventas) y usar herramientas como Impact Mapping para que todos vean el “Why” compartido.

Edwar Y. Castillo B.

student•

Emanuel Simon Zepeda

student•

1. Relación con el Scrum Master

El Scrum Master es un facilitador y coach del marco Scrum, no un jefe del equipo. El Product Owner debe trabajar con él para:

Asegurar la comprensión del marco Scrum El Scrum Master apoya al PO para que gestione el backlog siguiendo buenas prácticas.
Facilitar la comunicación con stakeholders El Scrum Master ayuda a crear un entorno de transparencia y colaboración.
Eliminar impedimentos organizacionales El Scrum Master trabaja con el PO y la organización para resolver bloqueos que afecten el flujo de valor.

Ejemplo de buena práctica:

El Scrum Master facilita una reunión con gerencia para que el PO justifique la priorización del backlog usando métricas de valor.

2. Relación con los Scrum Developers

Los Scrum Developers son responsables de entregar el incremento de producto de calidad. El Product Owner debe trabajar con ellos para:

Aclarar historias de usuario y criterios de aceptación Responder dudas y aportar contexto del negocio para que las soluciones sean funcionales y valiosas.
Colaborar en el refinamiento del backlog Escuchar estimaciones y sugerencias técnicas para mejorar la priorización y dividir historias grandes.
Definir objetivos de Sprint claros Alinear expectativas sobre lo que se espera entregar y el valor que aportará.

Ejemplo de buena práctica:

El PO presenta la visión de producto en la Sprint Planning y los Developers sugieren dividir una épica en tres historias más pequeñas para asegurar su entrega en el sprint.

3. Principios para un trabajo en equipo efectivo

Transparencia: Compartir información completa y actualizada sobre prioridades, objetivos y cambios.
Colaboración continua: No limitar la interacción a eventos Scrum, mantener comunicación abierta durante todo el sprint.
Respeto mutuo: Valorar las decisiones técnicas del equipo y las prioridades del negocio definidas por el PO.
Aprendizaje conjunto: Revisar resultados en la Sprint Review para ajustar tanto backlog como prácticas de trabajo.

Nilson .

student•

En el caso de que algun Scrum Developer tenga dudas respecto a su Historia de Usuario asignada, puede contactar directamente con los usuarios que harán uso de esa funcionalidad en el producto de software, o solo deben contactar al Product Owner..???

Cady Berenise Antigua Cruz

student•

Hola! no veo el caso de estudio.. pueden ayudarme?

Platzi

student•

El caso de estudio se encuentra en los recursos de la clase. Te sugiero revisarlos para poder analizarlo y hacer tu recomendación.

lguerrero3067

student•

Buenas tardes,

donde estan los retos que se mencionan en cada clase para resolver . Gracias

Vanessa Amaya

teacher•

Hola! Están en los anexos en la sesión de caso de estudio.