Mostrando las entradas con la etiqueta equipo del producto. Mostrar todas las entradas
Mostrando las entradas con la etiqueta equipo del producto. Mostrar todas las entradas

lunes, septiembre 23, 2024

Priorizar vs. Ordenar el Backlog: Más Allá de la Semántica

Imagen generada por DALL-E


Hola a todos,

Durante mucho tiempo, en mis entrenamientos de Scrum, solía decir que el Product Backlog se "prioriza". Sin embargo, al analizar con más detenimiento la Guía Scrum 2020, noté que el término correcto es "ordenar". Aunque podría parecer una diferencia semántica, en realidad, tiene profundas implicaciones en la manera en que gestionamos el trabajo del equipo. Ordenar no es simplemente priorizar; es entender el contexto, los diferentes tipos de trabajo y las necesidades estratégicas del negocio para decidir el orden en el que se abordarán los ítems.

¿Qué Significa Ordenar un Backlog?

Ordenar implica más que asignar niveles de importancia o urgencia. Es un proceso que requiere una comprensión holística de todos los elementos que componen el backlog y sus interrelaciones. Veamos en qué se diferencia ordenar de priorizar:

  1. Ordenar: Organizar ítems en función de múltiples criterios como riesgo, valor, complejidad, dependencias y necesidad estratégica. Requiere un entendimiento profundo del entorno y de cómo cada ítem contribuye al objetivo general del producto.
  2. Priorizar: Asignar un nivel de importancia o urgencia a cada tarea. Este enfoque puede ser útil, pero se queda corto cuando hay múltiples dimensiones a considerar.

Un Ejemplo Cotidiano

Supongamos que tienes las siguientes tareas en un día ocupado:

  1. Preparar un informe para una reunión importante.
  2. Responder correos electrónicos pendientes.
  3. Llevar a cabo una tarea de investigación para un proyecto a largo plazo.
  4. Hacer una llamada de seguimiento a un cliente insatisfecho.
  5. Organizar tu escritorio y archivar documentos.

Si decides priorizar, podrías hacer lo siguiente:

  1. Preparar un informe para una reunión importante.
  2. Hacer una llamada de seguimiento a un cliente insatisfecho.
  3. Responder correos electrónicos pendientes.
  4. Llevar a cabo una tarea de investigación para un proyecto a largo plazo.
  5. Organizar tu escritorio y archivar documentos.

Aquí, has ordenado las tareas basándote únicamente en la importancia y urgencia. Pero, ¿qué pasa si hay dependencias o restricciones de tiempo? ¿Y si la llamada con el cliente solo puede hacerse a cierta hora? La prioridad cambia.

Si decides ordenar, podrías hacerlo así:

  1. Preparar un informe para una reunión importante.
  2. Hacer una llamada de seguimiento a un cliente insatisfecho a la hora acordada.
  3. Organizar tu escritorio mientras esperas la hora de la llamada.
  4. Responder correos electrónicos mientras esperas respuesta del informe.
  5. Llevar a cabo la investigación cuando tengas tiempo concentrado disponible.

Aquí, has tenido en cuenta no solo la importancia, sino también la disponibilidad de tiempo, las dependencias y el contexto.

Ordenar el Backlog: Un Ejercicio Complejo

Llevemos esto al mundo de Scrum. Imaginemos un backlog con los siguientes ítems:

  1. Corregir un bug crítico que afecta a muchos usuarios.
  2. Implementar una nueva funcionalidad solicitada por un cliente clave.
  3. Actualizar la documentación técnica del proyecto.
  4. Realizar pruebas de carga en el sistema.
  5. Mejorar la interfaz de usuario en la pantalla de inicio.

Priorizar el Backlog:

  1. Corregir un bug crítico (Alta prioridad por impacto).
  2. Implementar nueva funcionalidad (Importante para la satisfacción del cliente).
  3. Realizar pruebas de carga (Esencial para la estabilidad).
  4. Mejorar interfaz (Mejora la experiencia, no urgente).
  5. Actualizar documentación (Baja prioridad).

En este caso, hemos asignado prioridades basadas en urgencia e impacto. Pero, ¿qué pasa si el equipo necesita mejorar la documentación antes de implementar la nueva funcionalidad para evitar errores? La prioridad cambia.

Ordenar el Backlog:

  1. Corregir un bug crítico.
  2. Actualizar la documentación técnica (necesario para implementar correctamente la nueva funcionalidad).
  3. Implementar nueva funcionalidad.
  4. Realizar pruebas de carga después de la nueva funcionalidad.
  5. Mejorar la interfaz de usuario.

En este ejemplo, hemos considerado no solo la importancia, sino también las dependencias y el contexto. Esto es lo que realmente significa ordenar un backlog.

¿Por Qué es Importante Comprender la Diferencia?

Cuando el Product Owner ordena el backlog, no se limita a clasificar ítems por prioridad, sino que considera factores como:

  • Dependencias Técnicas y Funcionales: Un ítem podría ser más prioritario, pero si no se cumplen ciertas condiciones previas, no puede abordarse.
  • Riesgos: Un ítem con menor prioridad podría tener un riesgo elevado que lo convierta en un foco de atención temprano.
  • Impacto Estratégico: Hay ítems que, aunque no parezcan urgentes, son esenciales para el crecimiento del negocio a largo plazo.

Por lo tanto, existen varios criterios que puedes utilizar para ordenar los ítems del backlog. La elección de los criterios dependerá de los objetivos, contexto y momentos específicos. Aquí algunos de los más comunes:

  • Urgencia: Priorizar según plazos o fechas límite.
  • Importancia: Relevancia de la tarea para los objetivos a largo plazo.
  • Impacto: Qué tan significativa es la tarea en los resultados finales.
  • Complejidad: Ordenar tareas más simples antes para liberar recursos.
  • Riesgo: Considerar tareas que podrían tener consecuencias negativas significativas si no se completan a tiempo.
  • Dependencia: Priorizar tareas que desbloquearán o permitirán el progreso en otras.
  • Retorno de Inversión (ROI): Evaluar qué tareas ofrecen mayor retorno de inversión en tiempo, esfuerzo o recursos.
  • Valor percibido: Dar prioridad a las tareas que se consideran más valiosas desde una perspectiva personal o de equipo
  • Recursos disponibles: Considerar los recursos, como tiempo y presupuesto, disponibles para cada tarea. Priorizar tareas que se pueden completar con los recursos disponibles.
  • Capacidad personal: Considerar tu propia capacidad y disponibilidad para realizar las tareas. Priorizar tareas según tu habilidad y disponibilidad en un momento dado.

La combinación y ordenamiento de estos criterios o la elección de uno sobre otro dependerá de la naturaleza específica de las tareas y metas; y por lo tanto, se pueden ajustar y personalizar estos criterios según tus necesidades y circunstancias particulares.

Pasos para un Ordenamiento Efectivo del Backlog

Para realizar correctamente el ordenamiento del Product Backlog en Scrum, es fundamental seguir una secuencia estructurada que tenga en cuenta varios factores y criterios. Aquí te presento una secuencia de pasos recomendada:

1. Definir el Contexto y Objetivos del Producto

  • Antes de ordenar, asegúrate de tener claros los objetivos del producto, la visión y la estrategia general. Esto te ayudará a tomar decisiones alineadas con el valor esperado del producto.

2. Identificar los Criterios de Ordenamiento

  • Define los criterios que usarás para ordenar el backlog. Estos pueden incluir:
    • Valor de negocio: ¿Qué tanto contribuye el ítem al valor del producto?
    • Riesgo y complejidad: ¿Cuáles son los riesgos asociados al ítem? ¿Es un ítem técnicamente complejo?
    • Dependencias: ¿Existen dependencias con otros ítems o equipos?
    • Urgencia o necesidad regulatoria: ¿Existen fechas límite o requerimientos regulatorios?

3. Evaluar y Categorizar los Ítems del Backlog

  • Revisa cada ítem del backlog y asígnale una categoría basada en los criterios definidos. Por ejemplo, puedes clasificar los ítems como:
    • Bugs: Problemas críticos que afectan la experiencia del usuario.
    • Deuda técnica: Elementos que necesitan ser resueltos para mejorar la calidad del código.
    • Funcionalidades nuevas: Mejoras o nuevas capacidades del producto.
    • Requerimientos regulatorios: Obligaciones legales o normativas.

4. Considerar las Dependencias

  • Asegúrate de que los ítems con dependencias necesarias se ordenen de manera que no bloqueen el trabajo posterior. Esto es crucial para mantener el flujo de trabajo.

5. Asignar una Puntuación de Valor

  • Usa técnicas como el valor ponderado (Weighted Shortest Job First - WSJF o la relacion Valor/Duración) para asignar un puntaje a cada ítem basado en su valor relativo, el esfuerzo requerido y el impacto en la entrega del producto.

6. Organizar el Backlog en Función del Contexto

  • Con los criterios y puntajes, organiza el backlog considerando el contexto actual del proyecto. Esto puede implicar mover hacia arriba ciertos ítems que, aunque no tienen el mayor valor, desbloquean otros ítems críticos.

7. Revisar y Ajustar Regularmente

  • El Product Backlog no es estático. Revisa y ajusta el orden regularmente en las reuniones de refinamiento del backlog, o cada vez que cambien las condiciones del proyecto o del mercado.

8. Comunicar el Ordenamiento al Equipo

  • Es fundamental que el equipo de desarrollo y los stakeholders entiendan el orden del backlog y las razones detrás de él. Esto mejora la transparencia y alinea a todos en cuanto a las prioridades del producto.

9. Validar con el Equipo

  • Antes de finalizar, valida el orden del backlog con el equipo de desarrollo. Pueden surgir consideraciones técnicas o de implementación que afecten la viabilidad del orden propuesto.

10. Monitorear el Impacto y Adaptar

  • Observa cómo el ordenamiento del backlog afecta el desempeño del equipo y la entrega de valor. Ajusta el orden si es necesario para asegurar que se maximiza el valor entregado al cliente.

Este enfoque permite que el Product Owner tome decisiones informadas y estratégicas al ordenar el backlog, asegurando que el equipo trabaje en lo que realmente aporta valor y minimizando el desperdicio de tiempo y recursos.

Conclusiones

  1. No Todo Puede Ser Priorizado Igual: Un solo criterio de priorización no es suficiente, existen muchos criterios. Es necesario un enfoque integral para gestionar el backlog de manera efectiva.
  2. El Product Owner Debe Comprender el Contexto: Ordenar el backlog implica entender el entorno, las necesidades del negocio, las dependencias y riesgos de cada ítem.
  3. Evangelización sobre Ordenamiento: Tanto el equipo Scrum como la organización deben entender esta diferencia. El Scrum Master juega un papel crucial en facilitar esta comprensión hacia todos los que están impactados con el ordenamiento del Product Backlog.
  4. Aplicabilidad a Portafolios Empresariales: A nivel de portafolio, no todos los proyectos se gestionan con los mismos criterios. Algunos son estratégicos, otros operativos; ordenar significa encontrar un equilibrio que maximice el valor global (esto será material para otro artículo).

Cerrando, ordenar un backlog no es una tarea sencilla, pero es crucial para que el equipo pueda entregar el máximo valor posible. No se trata solo de qué hacer primero, sino de entender por qué y cómo hacerlo en el contexto adecuado.

Saludos ágiles,

Jorge Abad.

domingo, marzo 29, 2020

Product Owner's Views - Explicación

Hola a todos

Generalmente vemos al Dueño de Producto (Product Owner - PO ) trabajando en dos frentes, en el frente de la definición del producto y en el frente de la construcción del mismo, por medio de este artículo quiero compartir que la visual del PO debe considerar tres frentes(1)(2) para realizar una correcta construcción del producto.
  • Vista 1 - Descubrimiento (Discovery):
    • En este frente el PO trabaja con el Equipo del Producto (Product Team), que puede estar compuesto por:
      • expertos del negocio
      • arquitectos de software y arquitectos empresariales
      • Expertos en UX / UI
      • clientes
      • posibles suarios
      • expertos en Seguridad y Riesgos
      • expertos en Procesos
      • gerentes de Producto (Product Managers
      • otros PO e interesados claves
    • Para definir:
      • el producto,
      • la visión del producto
      • la lista ordenada del producto (Product Backlog)
      • el producto minimo viable (Minimum Viable Product - MVP
      • las versiones, 
      • los prototípos,
      • los indicadores,
      • los esquemas de ROI
      • las hipótesis, etc.
    • Para esto se vale de:
      • visitas a clientes y usuarios
      • conocer donde va a ser usado el producto (gemba walks)
      • investigaciones de mercado
      • análisis de la compentencia (benchmarks)
      • estrategias de construcción del producto
      • dependencia de otros productos o soluciones, etc.
  • Vista 2 - Desarrollo (Development): 
    • En esta vista el PO proporciona y explica del Product Backlog priorizado y refinado al Equipo de Desarrollo (Development Team) para que el producto sea creado según su conocimiento y capacidades, y basado en los lineamientos del Equipo del Producto.
  • Vista 3 - Producción (Production): 
    • En esta vista el PO observa si el producto esta siendo usado según las expectativas para las que fue creado y valida la generación de valor del mismo.
De cada uno de estos frentes el Product Owner obtiene valiosa retroalimentación sobre el Producto que debe considerar y balancear de acuerdo a los tiempos y propósitos que tenga identificados con las versiones a liberar; estas retroalimentaciones le sirven para generar una próxima mejor versión y por ende un mejor producto, estas son:
  • Retroalimentación 1 (Feedback 1) del ambiente producción y los usuarios, al Equipo de Desarrollo:
    • Uso del producto
      • funcionalidades más usadas
      • funcionalidades menos usadas
      • estadisticas basadas en uso
      • hipótesis que funcionaron y las que no
      • Funcionamiento del producto
      • incidentes y bugs a ser priorizados
      • problemas de rendimiento y funcionamiento
      • estadisticas de desempeño
      • problemas de seguridad
      • deuda técnica identificada y que debe ser priorizada
  • Retroalimentación 2 (Feedback 2) del Equipo de Desarrollo al Equipo del Producto. 
    • El equipo de desarrollo comienza a conocer tanto el producto, que se convierte en otro interesado clave (key stakeholder), proporcionando información para la construcción del mismo. Dentro de la retroalimentación brindada pueden estar las siguientes:
      • funcionalidades innecesarias
      • funcionalidades a adicionar
      • estrategias de implementación
      • deuda técnica identificada a ser priorizada
      • incidentes y bugs a ser priorizados
      • retos técnicos
      • estimaciones
      • nuevas dependencias técnicas
      • nuevas dependencias funcionales con otros productos o equipos de trabajo
  • Retroalimentación 3 (Feedback 3) del ambiente de producción y los usuarios al Equipo del Producto:
    • Uso del producto
      • funcionalidades más usadas
      • funcionalidades menos usadas
      • estadisticas basadas en uso
      • hipótesis que funcionaron y las que no
      • valor o ROI generado vs. el esperado
      • datos que se obtienen de la validación de hipótesis
    • Funcionamiento del producto
      • incidentes y bugs a ser priorizados
      • estadisticas de desempeño
      • problemas de seguridad identificados
      • problemas de experiencia de usuario identificados
      • deuda técnica identificada y que debe ser priorizada
      • estadísticas basadas en experiencia de usuario

Bienvenidos sus comentarios

Saludos ágiles
Jorge Abad


Notas, Referencias, Aclaraciones, Comentarios y Observaciones

  1. El análisis acá presentado esta pensado está formulado para productos basados en software, para otro tipo de productos se sugiere realizar análisis similar y reemplazar roles, actividades y fuentes según sea la industria de solución.
  2. Este diagrama fue resultado del análisis del dual-track, algunas interesantes referencias a continuación:
  3. Gracias a mis amigos Jaime Icaza y Daniel Ramirez por sus valiosos comentarios para mejorar este artículo.


jueves, abril 25, 2019

De Colección: 51 frases motivadoras para trabajar en equipo

Hola a todos

Buscando información para una presentación me encontré con esta selección de frases, realmente es una joya (la copié para que no se me perdiera la referencia):

1. “No hay reto que no podamos alcanzar trabajando unidos con claridad de los objetivos y conociendo los instrumentos”. -Carlos Slim.
2. “La fuerza está en la unidad. Con la colaboración y el trabajo en equipo es posible conseguir cosas maravillosas”. -Mattie Stepanek.
3. “Nadie puede silbar una sinfonía. Se necesita una orquesta completa para tocarla”. -HE Luccock.
4. “Este mundo no es un campo de batalla. Algún día te darás cuenta de cómo tu éxito depende de un montón de otras personas y ese día serás más sabio. Tú sabrás que todos estamos conectados. O lo hacemos todos o ninguno de nosotros lo hace”.-Jasleen Kaur Gumber.
5. “Ten presente que el destino de todos depende de la conducta de cada uno”. -Alejandro Magno.
6. “Jamás pongas en duda que un pequeño grupo de personas comprometidas pueden cambiar el mundo. En efecto, es lo único capaz de lograrlo”. -Margaret Meade.
7. “Ninguno de nosotros es tan bueno como todos nosotros juntos”. -Ray Kroc.
8. “El talento gana partidos, pero el trabajo en equipo y la inteligencia ganan campeonatos”. -Michael Jordan.
9. “Cuando las arañas tejen juntas, pueden atar a un león”.-Proverbio Etíope.
10. “La fortaleza del equipo está en cada miembro por separado. La fortaleza de cada miembro es el equipo”. -Phil Jackson.
11. “El trabajo en equipo es el secreto que hace que la gente común logre resultados increíbles”. – Ifeanyi Onuoha.
12. “El trabajo en equipo es la capacidad de trabajar juntos hacia una visión común. La capacidad de dirigir los logros individuales hacia los objetivos de la organización. Es el combustible que permite que la gente normal logre resultados poco comunes”. –Andrew Carnegie.
13. “El trabajo en equipo permite que los sueños se cumplan”. –Bang Gae.
14. “Si un equipo quiere alcanzar su potencial, cada miembro debe estar dispuesto a doblegar sus metas personales para el bien de todos”. -Bud Wilkinson.
15. “Si estamos juntos no hay nada imposible. Si estamos divididos todo fallará”. -Winston Churchill.
16. “Con un equipo lleno de entusiasmo puedes conseguir casi cualquier cosa”. -Tahir Shah.
17. “Un barco no avanza si cada uno está remando en una dirección”. – Proverbio Swahili.
18. “El espíritu de equipo es lo que da a muchas empresas una ventaja sobre sus competidores”. -George Clements.
19. “Mejor perder con el equipo adecuado que ganar con el equipo equivocado”. Ogwo David Emenike.
20. “Los cinco dedos separados son cinco unidades independientes. Ciérralos y el puño multiplica la fuerza. Ésta es la organización”. -James Cash Penney.
21. “No existe un hombre hecho a sí mismo. Alcanzarás tus metas con la ayuda de los demás”. -George Shinn.
22. “No hay equipo sin los miembros individuales; un individuo nunca puede ser un equipo”. -Michael Joling.
23. “Es mucho más gratificante llegar a la cima de la montaña y compartir tu experiencia con otros que mostrarte tu solo exhausto”. -Shandel Slaten.
24. “Solos podemos hacer muy poco; unidos podemos hacer mucho”. -Hellen Keller.
25. “Llegar juntos es el principio. Mantenerse juntos, es el progreso. Trabajar juntos es el éxito”. -Henry Ford.
26. “Trabaja en equipo. Unos inofensivos copos de nieve juntos pueden desatar una avalancha de destrucción.” – Justin Sewell.
27. “Si podéis reír juntos, podéis trabajar juntos”. – Robert Orben.
28. “Nadie puede conseguir el éxito solo”. -Ifeanyi Enoch Onuoha.
29. “Sólo llegando a estar unidos, como una sola fuerza, nos mantendremos fuertes e inconquistables”. –Chris Bradford.
30. “El ego es el asesino definitivo en un equipo”. – Patrick Lencioni.
31. “El mejor trabajo en equipo proviene de aquellos hombres que trabajan de forma independiente para conseguir una meta en conjunto”. –James Cash Penney.
32. “Tienes que ser consciente de lo que están haciendo los otros, aplaudir sus esfuerzos, reconocer sus éxitos, y animarlos en sus metas. Cuando todo el mundo se ayuda, todo el mundo gana”. – Jim Stovall.
33. “El trabajo en equipo comienza por crear confianza. La única forma de hacerlo es superar nuestra necesidad de invulnerabilidad”. –Patrick Lencioni.
34. “Construye en tu equipo un sentimiento de unidad, de dependencia de uno para el otro, de fortaleza derivada de la unidad”. -Vince Lombardi.
35. “Yo hago lo que tú no puedes, y tú haces lo que yo no puedo. Juntos podemos hacer grandes cosas”. -Madre Teresa de Calcuta.
36. “Hay que unirse, no para estar juntos, sino para hacer algo juntos”. – Donoso Cortes.
37. “Algunas veces, el mayor desafío de un jugador viene en relación con su papel en el equipo”. -Scottie Pippen.
38. “Los equipos comparten la carga y dividen el dolor”. -Doug Smith.
39. “Es increíble lo que se puede conseguir cuando a nadie le importa quién se lleva el crédito”. -Robert Yates.
40. “Es literalmente verdad que puedes tener éxito mejor y más rápido al ayudar a otros a tener éxito”. -Napoleon Hill.
41. “Un equipo es una combinación de miles de factores humanos y psicológicos encaminados hacia el mismo objetivo: La victoria”. -Manuel Gomez Brufal.
42. “No importan cuantos logros hayas conseguido, alguien te ayudó”. -Althea Gibson.
43. “No hay problema que no podamos resolver juntos, y muy pocos que podamos resolver por nosotros mismos”. -Lyndon Johnson.
44. “Invito a todos a elegir el perdón en lugar de la división, el trabajo en equipo en lugar de la ambición personal”. -Jean-Francois Cope.
45. “El talento gana juegos, pero el trabajo en equipo y la inteligencia ganan campeonatos”. -Michael Jordan.
46. “Con un equipo entusiasta se puede lograr casi cualquier cosa”. -Tahir Shah.
47. “El trabajo en equipo es el secreto que hace que la gente común logre resultados poco comunes”. -Ifeanyi Onuoha.
48. “La velocidad del jefe es la velocidad del equipo”. -Lee Iacocca.
49. “La colaboración no tiene jerarquía. El Sol colabora con el suelo para traer flores a la tierra”. -Amit Ray.
50. “Mi trabajo es hacer a todo el equipo ejecutivo lo suficientemente bueno como para que sean mis sucesores”. –Steve Jobs.

51 (Bonus) . "Si quieres ir rápido camina solo, si quieres llegar lejos ve acompañado". Proverbio Africano




Tomada de: https://gananci.com/frases-para-trabajar-en-equipo/

lunes, abril 01, 2019

El Equipo Oculto de Scrum: El Equipo del Product Owner o Equipo del Producto




Hola a todos

Este corresponde a uno de esos post que tengo en mi lista de pendientes que por fin salen a la luz después de presionarme internamente una y otra vez por ser escritos.

Definitivamente el título del artículo es el "spoiler", pero aunque saben para donde voy, vamos a conocer las razones de esta afirmación.

Un Product Owner con Pleno Conocimiento

En primer lugar, tenemos equipos scrum, con esquemas muy simples de trabajo donde el Product Owner (PO), es alguien que tiene todo el conocimiento sobre el producto y le es fácil tomar decisiones sobre lo que se esta construyendo.

Desde mi punto de vista esta es la configuración más simple pero muy escasa, principalmente en espacios corporativos, pues muchas veces para diseñar un Producto un PO debe interactuar con muchos interesados; y eso nos lleva a la siguiente configuración.


Un PO Interactuando un Grupo de Interesados

En este caso el PO, posible que tenga conocimiento de una parte del universo del problema pero requiere de áreas adicionales para diseñar el producto correcto.
En este caso, cada una de esas áreas proporciona conocimiento y decisiones claves sobre el mismo, y le ayuda a entender al PO, como gestionar las dependencias, y diseñar estrategias para hacer exitosa la construcción del producto.


El Equipo del Producto

Bajo el contexto anterior en la medida que los productos son más complejos, los PO deben interactuar con más áreas y esas áreas son de contacto frecuente, adicionalmente estas terminan volviéndose lo que en muchos entornos se denomina "El Equipo del Producto".

Este Equipo del producto, debido al rol que desempeñan se podrían definir como son un grupo de personas que  proporcionan información estratégica, táctica, operativa y técnica sobre el producto y que debe ser considerada para la elaboración y refinamiento del Product Backlog.




Este Equipo del producto,es muy probable que:
  • sea con el que se realice el Inception y el continuo refinamiento del producto
  • tenga un ciclo de reuniones para hablar sobre el producto, su presente y futuro.
  • algunos de sus integrantes hagan parte de los stakeholders a los cuales después de cada sprint se presenta incremento del producto cada sprint
  • se presenten conflictos entre ellos, pues donde donde hay restricciones y diferentes intereses, lo más natural es que aparezca el conflicto
  • tengan necesidades de un facilitador, es decir,  de alguien que les ayude a coordinarse, resolver sus conflictos para no perder su foco. 

El Equipo del Producto ¿Es realmente un equipo?

Lo cierto, es que este Equipo del Producto permanece oculto a la vista de todos, pero es frecuente escuchar por parte del PO, del SM y hasta del Equipo de Desarrollo, quejarse de problemas de:falta de coordinación
  • involucramientos tardíos
  • falta de compromiso
  • conflicto de intereses
  • entre otros
Y aunque este grupo de personas tengan un interés común, no implica que se vean como un equipo, pero esto no los exime de las necesidades de que exista un facilitador entre ellos que permita la fluencia de los diferentes temas que ellos tratan. Este rol de facilitador podría ser ejercido por:

  • El Product Owner (aunque sería viable por su ubicación estratégica entre el equipo Scrum y los Stakeholders, es probable que no cuente con las habilidades de facilitación)
  • El Scrum Master
  • El Agile Coach del ecosistema ágil al que pertenece el producto
Este facilitador, determinará si avanza a formarlos como equipo, o los sigue gestionando como un grupo con un interés común.








Unos consejos: Al menos una Sincronización Semanal y una Retrospectiva Mensual

Ahora, sea que ellos se vean o no como equipo, es altamente recomendado:
  • Ejecutar al menos una sincronización semanal para identificar avance de pendientes y necesidades de ayuda, esto podría ser apoyado por la gestión visual que proporciona un tablero kanban.  
  • Realizar una retrospectiva cíclica, al menos una vez al mes que busque mejorar tanto las interacciones al interior como con el Equipo Scrum.
Estas dos dinámicas serán de gran valor y sumarán bastante a la dinámica de la construcción del producto.



Cerrando

Por último unas preguntas:

  • ¿tienes un "equipo del producto"?¿realmente son un equipo?¿les interesa serlo?
  • ¿ya lo identificaste?¿o justo ahora te haces consciente de el?
  • ¿necesita facilitador?
  • ¿podría ser el scrum master del equipo scrum?
  • ¿podría ser otro scrum master?¿o un agile coach?
  • ¿que cadencia de sesiones tienen?
  • ¿sería útil una sicronización diaria, semanal?
  • ¿sería valioso tener al menos una retrospectiva mensual para corregir problemas y lograr responder a a las necesidades del equipo scrum?

Hasta acá este compartir, bienvenido el feedback.

Saludos ágiles
Jorge Abad.





Saludos Ágiles
Jorge Abad