miércoles, 17 de abril de 2024

Equipo Ágil: Constitución de equipo

La constitución de un equipo o la realización de dinámicas de formación de equipo al inicio de un proyecto o producto son prácticas esenciales en metodologías ágiles y en la gestión de equipos en general. Estas actividades ayudan a sentar las bases para una colaboración efectiva y una configuración inicial para constituir un equipo que se vaya transformando en uno de alto rendimiento.

Algunas dinámicas que sirven a este fin son las siguientes: Team Canvas, Team Agreements (Working Agreements), Team Manifesto, Team Purpose, Definition of Done y Definition of Ready.

Team canvas

Se puede utilizar un lienzo de equipo al crear un equipo nuevo o con un equipo existente cuya cohesión se ha perdido. Este ejercicio ayuda a resolver conflictos y ayuda a crear alineación entre los miembros del equipo. De esta manera podrá construir rápidamente una cultura productiva.

La creación de un lienzo de equipo da como resultado un póster en el que se puede ver lo que representa el equipo, quiénes lo integran y qué pueden esperar los miembros del equipo unos de otros.


Team Purpose

Como equipo, defiendes algo. Hay una razón por la que existe este equipo, el impacto que se espera de él y lo que te hace querer contribuir a él: el propósito del equipo. Este ejercicio te ayuda a concretarlo y desarrollarlo junto con el equipo.

Con este ejercicio, el equipo crea una declaración de lo que representa y cuál es su valor agregado para la organización. Puede compartir esa afirmación con otras personas de la organización y utilizarla como prueba diaria de si el trabajo que realiza el equipo contribuye al propósito del equipo.


We stand for... [focus area] ... 

We do this by... [type of work] ... 

So that... [who]... 

can... [benefit from value/ impact] ...


Team Manifesto

Un manifiesto de equipo es un cartel con los principales acuerdos que ha tomado un equipo sobre actitud y comportamiento. Este ejercicio contribuye a la formación de equipos y fortalece la cultura de equipo.

Un cartel, que se vuelve transparente colocándolo en una pared, con acuerdos dentro de un equipo sobre comportamientos (no)deseados, que se utiliza para establecer expectativas claras entre sí sobre quién quiere ser el equipo. Esto aumenta los vínculos del equipo, evita la confusión causada por expectativas tácitas y ayuda al equipo a crear y fortalecer su cultura de manera explícita.


Team Agreements (Working Agreements)

Este ejercicio consta de llegar a acuerdos que son importantes para un equipo. Se busca claridad sobre los acuerdos respecto a los eventos de scrum y cómo el equipo quiere trabajar en conjunto.


Definition of Done

Para equipos que tienen un flujo de trabajo claro o equipos que practican Scrum o Kanban en desarrollo de software debería definir inicialmente una definición de terminado o hecho. Con una Definición de Hecho (DoD), un equipo crea un entendimiento común de lo que significa estar hecho: que un trabajo esté terminado. El DoD es un conjunto genérico de requisitos que se aplica a todos los elementos de la cartera de productos.


Definition of Ready

Para equipos que tienen un flujo de trabajo claro o equipos que practican Scrum o Kanban en desarrollo de software podría definir inicialmente una definición delisto o Definition of Ready (DoR). Con una DoR, un equipo crea un entendimiento común de lo que significa que una solicitud o requerimiento está lista para poder ser abordada o comprometida para trabajarse. El DoR es un conjunto genérico de requisitos que se aplica a todos los elementos de la cartera de productos.


Referencias:





Retrospectiva: M&M GTKY (checkin)

 M&M retrospectiva & checkin



¿Está buscando inspiración para una introducción concisa que sea ligeramente diferente a la de todos turnándose en un círculo? ¿Estás buscanto una actividad de inicio rompehielo o checkin para tu retropsectiva o reunión de team building?

Aquí tienes la dinámica "M&M GTKY"


Paso 1: Escriba preguntas.

Preguntas ejemplo (chackin):

  1. Rojo: ¿Qué historia siempre cuentan tus amigos sobre ti? 
  2. Naranja: ¿Qué sellos le gustaría tener en su pasaporte? 
  3. Amarillo: ¿Cuál es el mejor viaje que has hecho en tu vida? 
  4. Verde: ¿Qué le dirías a tu yo más joven? 
  5. Marrón (pregunta al azar): Si te tocara la lotería, ¿qué harías?

Otras preguntas ejemplo:

  1. Rojo: ¿Cuál fue uno de tus momentos más vergonzosos en el trabajo? 
  2. Naranja: ¿Cuál es uno de tus momentos de mayor orgullo en el trabajo? 
  3. Amarillo: ¿Qué te hizo reír la última semana? 
  4. Verde: ¿Cuál es tu lugar favorito para estar al aire libre? 
  5. Azul: Si pudieras ir a cualquier parte del mundo hoy, ¿adónde irías? 
  6. Marrón: ¿Qué haces para tranquilizarte cuando estás frustrado?

Más preguntas (retrospectiva):

  1. Rojo: ¿Qué error hemos cometido?
  2. Naranja: ¿Qué refactor harías de lo que hemos hecho?
  3. Amarillo: ¿Cómo encuentras la paz en un día estresante?
  4. Verde: ¿Quién ha hecho un gran trabajo en este sprint?
  5. Azul: ¿Qué podemos mejorar la próxima vez?
  6. Marrón: ¿A qué miembro del equipo quieres dar las gracias?


Paso 2: Distribuya un M&M por persona 

Deje que un tazón lleno de M&M recorra el grupo y deje que todos elijan un solo M&M. Dígales que no lo coman todavía. 


Paso 3: Preguntas y respuestas.

Presenta las preguntas al grupo para que todos puedan ver qué pregunta se aplica a ellas, según el color del M&M que eligieron. Deje que todos compartan su respuesta con el grupo hasta que todos hayan tenido su turno. Dependiendo del tiempo disponible, es posible que desees establecer un cuadro de tiempo para cada respuesta.




Referencias:









martes, 6 de febrero de 2024

Product Owner: Configuración de equipos según tipo de PO, PM y antipatrones

Las diferentes maneras de adoptar Agile y la distinción y diferentes interpretaciones entre los roles de Product Owner (PO) y Product Manager (PM) es de hecho uno de esos temas donde la teoría tiene sus límites y la práctica sus descarrilamientos. 

A la hora de adoptar agilidad y marcos de trabajo como Scrum nos podemos preguntar... ¿entonces solo un PO? ¿Solo un MP? ¿Varios PO y un jefe de PO? ¿Un PO y un PM? ¿Con o sin Business Owner? ¿Cuál es la mejor manera? Los invito a ganar un poco de perspectiva sobre el tema y revisar diferentes formas de implementar el rol PO, equipos Scrum y PM.


En este post revisaremos las siguientes opciones:

Opción n.º 1: Product Owner = Product Manager



En Scrum, el Product Owner, es responsable de maximizar el valor del producto, el representante del cliente, los usuarios y todos los stakeholders. Como tal, es el contacto preferido del equipo de desarrollo. El Product Owner es un Product Manager ágil que trabaja con el equipo haciendo Scrum. Este es el marco de Scrum tal como se describe en la Guía Scrum y, más precisamente, tal como fue diseñado por el propio Jeff Sutherland. ¿Perfil de este primer PO completo? el mejor Program Manager a los ojos de Sutherland a quien se le dio la oportunidad de trabajar el 50% de su tiempo directamente con los equipos de ingeniería.

Está ubicado en el equipo, trabajando mano a mano con TECH, el PO que trabaja en este tipo de contexto está, por lo tanto, fuertemente influenciado por la Gestión de Producto. Algunas empresas prefieren utilizar la etiqueta Product Manager (ágil) en lugar de Product Owner para describir este rol dentro del equipo de Producto. Este PO es táctico y estratégico, con autoridad de negocio, habla con los líderes y gerentes del negocio, gestiona stakeholders, se encarga de la estrategia, visión y rentabilidad del producto. Tiene la responsabilidad de maximizar el valor de todo el producto, porque es dueño del producto. 


Esta es la implementación ideal del rol, donde el Product Owner es realmente dueño del producto y la organización respeta sus deciciones y autoridad plena sobre el producto.

Aquí el riesgo es que el PO pueda verse sobrecargado por la cantidad de trabajo a realizar.


Opción n.º 2: Product Owner + Feature (Product) Owner


El producto ha crecido, es complejo y las características que lo componen requieren una subdivisión cohesiva en dos subproductos o en la necesidad de que alguien lleve más el trabajo táctico del PO. Una persona PO dedicada al producto estratégico y otras dedicadas a lo táctico (Feature Owner, BA, etc). Desde el punto de vista operativo, el número de funciones trabajadas en paralelo sigue siendo limitado y el equipo de producto en su conjunto permanece a escala humana, formando un solo equipo.

El propietario de la características se asegura de la hazaña técnica/táctica (analista), logrado los resultados esperados. Él tiene control sobre la priorización de su backlog en colaboración con el propietario del producto, quien mantiene una vista y la decisión sobre todo el producto. El propietario de la características  es el contacto preferido de los desarrolladores, escribe las historias de usuario y hace tareas de analista.

Este modo de organización es exigente y requiere una gran coordinación entre el propietario de la función y el propietario del producto, particularmente con respecto a los desarrolladores. Hay que considerar que aunque existan dos roles complementarios de PO, ambos trabajan dentro del equipo.

Aquí el riesgo es que el PO cada vez se sienta más alejado del equipo y termine delegando todo el trabajo al equipo como una fábrica de software.

Option #3 : Chief Product Owner + Product Owners

El producto es grande y complejo, ha entrado en una fase de crecimiento y requiere que varios equipos dedicados trabajen en paralelo. Un paso más allá, este también es el caso de un buen número de organizaciones de productos que han integrado plenamente el “Producto” en su organigrama, ya que su producto estaba en el centro de la creación de valor para la empresa. El CPO se convierte entonces en un verdadero “Jefe de Producto”, sentado en la mesa de las más altas autoridades, combinando experiencia y visión del producto con una postura de gerente ágil.

La modalidad CPO + PO también representa el contexto cada vez más frecuente de Programas de creciente complejidad que se encuentran con frecuencia esta vez en grandes empresas.

Como habrás comprendido, estamos en un contexto multiequipo en el que los equipos de Producto deben coordinar sus acciones con, en primer lugar, los Product Owners que deben sincronizar sus backlogs. Este modo CPO/PO es defendido notablemente por Jeff Sutherland en su marco Scrum@Scale y lo he aplicado en contextos inspirados en LeSS (el marco de Craig Larman y Bas Vodde).

Se llevará a cabo un evento de “Sincronización de productos” o “Comité de productos” 1 o 2 veces por sprint para respaldar que es necesario “trabajar juntos”, garantizar la coherencia y, más precisamente:

  • Sincronizar los Product Backlogs de los diferentes equipos en cuanto a priorización y dependencias (obviamente)
  • Saber qué está pasando con cada Equipo desde la perspectiva del producto (idealmente frente al Radiador de Información)
  • Tome nota de los comentarios de marketing, comentarios de campo (pruebas de usuarios, entrevistas con clientes), validación de hipótesis y ajustes...
  • Anticípese a N+2 sprints; n+3 en términos de necesidades funcionales, comerciales o arquitectónicas, y discutir más ampliamente el futuro del producto.
  • Actualizar la gestión visual

Los propietarios de productos mantienen un control total sobre su producto. El Chief Product Owner tiene una visión general, trabaja en la visión a largo plazo, garantiza la coherencia general del producto, toma las decisiones necesarias y se centra más en la relación con las partes interesadas.

El riesgo aquí es que los PO se transforme en "Proxy PO" y/o "Feature Owner", tácticos y aislados de los stakeholders y con poco contacto con los clientes, generando cuellos de botella y retrasos porque todas las decisiones tienen que pasar por el CPO. También el riesgo de que los equipos se transformen en "Feature Factory" y los PO en "tomadores de pedido".

Option #4 : Product Owner + Product Manager


Otro método de organización de productos que se está desarrollando en algunas compañías donde se propone el papel de "primer ministro".

Como Gerente de Producto, es responsable de evaluar oportunidades (Oportunity Assessment, Business Case, etc.) y determinar qué se construye y se entrega a los clientes de manera estratégica. Se asegura de que lo que se produzca sea viable y una fuente de valor.

Los dos roles de propietario de producto y gerente de producto coexisten para atender mejor las necesidades de los usuarios, clientes y partes interesadas y, al mismo tiempo, cumplir con los requisitos de eficiencia operativa y calidad de entrega. En última instancia, se trata de una distribución y una amplificación aún mayor de las actividades y responsabilidades del propietario del producto (o gerente de producto) presentadas en la opción n.° 1. Es una manera de compensar skills y repartir trabajo.

De hecho, el trabajo por hacer puede ser colosal para un producto en movimiento y una empresa que busca innovación. También requiere experiencia avanzada y una capacidad de respuesta inquebrantable hacia todos los involucrados que sirven o sirven el producto. Por tanto, esta coexistencia de ambos roles parece ser una necesidad real en bastantes situaciones.

Con esta opción, el Product Manager tiende (pero no solo) a especializarse en Discovery, research y/o actividades más estratégicas mientras que el Product Owner, más cercano al equipo de Delivery, forma parte de una gestión del product backlog más táctica y más operativa. Este último se posiciona dentro del equipo de producto, a diferencia del primer ministro. Para que funcione, aunque tengan responsabilidades divididas, deben trabajar juntos y en equipo en todas las definiciones de producto (visión, requerimientos de alto nivel, roadmap, etc.). En cualquier caso, una estrecha colaboración entre estos dos roles y actores es esencial para que el modelo funcione.

El riesgo aquí es que los PO se transforme, nuevamente, en "Proxy PO" y/o "Feature Owner", tácticos y aislados de los stakeholders y con poco contacto con los clientes, generando cuellos de botella y retrasos porque todas las decisiones tienen que pasar por el PM. También el riesgo de que los equipos se transformen en "Feature Factory" y los PO en "tomadores de pedido". Donde el PM define roadmap y el PO debe cumplirlos. O el riesgo de que el PM esté más orientado a proyecto (menos ágil) y el PO más orientado a producto (más ágil).

Option #5 : Product Owner + Product Manager + Business Owner


La última opción es una extensión de la anterior, nuevamente en una dinámica de agilidad a escala y en particular SAFe, que es el único marco que enfatiza un papel dedicado entre las partes interesadas, el de propietario de negocio o business owner (BO).

El propietario del negocio, tal como lo describe SAFe, es quien tiene la responsabilidad comercial principal de la gobernanza, el cumplimiento y el ROI (retorno de la inversión) de la solución desarrollada como parte del Agile Release Train.

Una lectura de este rol en SAFe y la forma en la que introdujo el concepto en algunas empresas empujan a considerar al Business Owner como el stakeholders que tiene mayor interés en el producto desarrollado pero también el mayor poder de influencia o decisión. Por tanto, es un jugador clave.

La ventaja de esta última opción es que hace que este actor clave sea visible para todos, aclarando así muchas situaciones. Le da un lugar de elección en esta dinámica de roles. También invita a reflexionar sobre los derechos y deberes de estos últimos, sobre sus actividades y su alcance de responsabilidades.

En este modo de organización del producto, además de su poder de toma de decisiones, su trabajo de alineación en torno a los objetivos comerciales que ha establecido, sus contribuciones para establecer la visión y la hoja de ruta del producto (colaborativa con el PO y PM), también se espera que el propietario del negocio ayude a coordinar los esfuerzos dentro de su entidad o entre departamentos de la empresa y ayudar a eliminar posibles obstáculos organizativos. El Product Manager se convierte en el brazo derecho del BO.

El gran riesgo con esta opción, instanciada con SAFe, empuja aún más la separación PM/PO, relegando el rol de Product Owner lejos de las preocupaciones estratégicas y el contacto con las partes interesadas (gerentes) y los usuarios. Un extremo claramente perjudicial. Al final queda el negocio por un lado (BO + PM) y tecnología por otro (equipo + PO proxy). Termina generando grandes disfuncionalidades que impiden el desarrollo ágil.



Referencias:

A propos de jc-Qualitystreet (Jean Claude Grosjean)  445 Articles
Jean Claude GROSJEAN - COACH d’Organisation. Coach d'Equipes - Coach Agile. J’accompagne la transformation des organisations et coach les PERSONNES, les EQUIPES dans leur nouveau parcours. La facilitation & la formation font aussi partie de mes activités. Me contacter: 06.20.98.58.40




Otras referencias: