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.

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.

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.

• 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

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

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.

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

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.

Definitivamente, me encanta este curso!

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

El PRODUCT OWNER **tiene que refinar **los próximos requerimientos del siguiente Sprint

Los valores:
Individuos e interacciones
software funcionando
colaboración con el cliente
Respuesta ante el camnio

En los stand up meetings, tengo entendido que puede estar, pero no participa. (product owner

Interacciones

Que tipos de conflictos entre interacciones de roles principales:
Escenario 2:
No hay una colaboración para definición del producto final cumpla con los requisitos del usuario y se alinee con los objetivos comerciales.

Escenario 3:
En las reuniones debe estar todo el equipo de Scrum, para garantizar la transparencia.
Habrá problemas de comunicación.

Susana y Sergio tienen enfoques diferentes, aunque tienen un objetivo en común, sus visiones y prioridades difieren, van a tener que llegar a un acuerdo, consensuar un punto medio, de lo contrario el engranaje del grupo se verá afectado desde estos roles tan importantes.

Hola, mis respuestas para el reto

Escenario 2 y 3:

• Se vulnera el principio 4 - responsables de negocio y desarrolladores trabajamos juntos.
• Se vulnera el valor 1, individuos e interacciones, ya que no están conversando para tener la sinergia como equipo.
• Se vulnera el principio 6, ya que el equipo no se está comunicando para lograr el mejor análisis posible

Escenario 2:
Un conflicto es que Susana esta enfocando la estrategia en el marketing y enganchar a los clientes, mientras que Sergio se enfoca en la experiencia de los ejecutivos de venta. Si ambos no trabajan en equipo y priorizan teniendo en cuenta ambas perspectivas puede surgir un conflicto que desvíe el optimo desarrollo de la aplicación.

Escenario 3:
Un problema está en el no permitir que tanto Santiago el Diseñador UX , como Luz y Gustavo quienes hacen el análisis funcional; compartan experiencia y faciliten el desarrollo de la UX.

En el escenario 2 , existe un grave problema de comunicacion que hace que las 2 personas que conocen mas del negocio esten trabajando cada uno por su lado violando a su ves un principio ágil Colaboración , el escenario 3 al no fluir la información en todo el equipo existe un problema de transparencia la cual en agilísimo es importante pues toda la información debe ser conocida por todo el equipo.

En el escenario 2 están trabajando por su lado soluciones al parecer de cada uno.
En el escenario 3 están trabajando independientemente y no se esta enterando de los requerimientos del cliente.

No se está cumpliendo trabajo en equipo con Scrum masters ni con Scrum developers. Las interacciones son fundamentales.
Como PO se tiene que representar la voz del cliente y todas sus interacciones deben llevar esa claridad, ya que es responsable del QUE.

No estoy de acuerdo en tener al PO en las dailys, si vamos al objetivo de la Daily, que es entender si el equipo de Desarrollo tiene un bloqueante, es el Scrum master quien debe luego gestionar con el PO si hay alguna duda, mas no en la daily, ya que se pierde el objeto de la reunion y se convierte en una reunion tecnica o reunion de seguimiento

Lo que veo es que en el escenario 2 Susana y Sergio no están trabajando en conjunto, no hay comunicación de equipo.
En el escenario 3 se esta dejando de lado a Luz y Gustavo quienes son los que tienen los requerimientos del producto, por ende como lo van a poder diseñar?

Es un gran camino a realizar para que todo el proceso marche bien y todos los colaboradores estén en la misma via, sobre todo es difícil de implementar una mentalidad agil en equipos de trabajo cerrados al cambio y que ya trabajan de cierta manera, pero todo proceso puede ser mejorable

Caso nro 2: Por estar al mismo nivel Susana y Sergio ningun de los dos estan escuchandose y eso hace que pierdan el enfoque que le estan dando a los productos de la empresa, como Opinion deberia de existir un Lider entre ellos.
Caso nro 3: Estan cometiendo un error en no incluir a Luz y a Gustavo, ya que ellos previamente habian realizado un analisis y saben cuales son los requeriiientos especificos del sistema.

Escenario 2: Sergio y Susana no estan trabajando en equipo y ak estar al mimo nivel en el organigrama ninguno escuchara la sugerencia del otro. Por eso considero que se debe establecer un responsable de la estrategia.
Escenario 3: Santiago, no cuenta con el tiempo necesario y es posible que no le este dedicando el tiempo que requiere el proyecto y no se esta enterando de los requerimientos del cliente, ni de los impedimentos del equipo.