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:









lunes, 11 de diciembre de 2023

Retrospective: Retro Improvement Kata

El Improvement Kata es una forma sistemática de establecer objetivos de mejora medibles y trabajar de manera iterativa para lograrlos a través de bucles cortos de aprendizaje. Para aplicar el Improvement Kata, necesitas saber dónde estás y hacia dónde quieres ir. Las iteraciones pueden ser tus Sprints si trabajas con Scrum y las planeaciones de mejoras las realizarías en las sesiones de retrospectiva. Es una manera de mezclar retrospectivas con Improvement Kata.

Los pasos de una retrospectiva tipo Kata pueden ser los siguientes:

  1. VISIÓN: alineación (formalizar una visión). inicia con la visión que nos guía..
  2. DESAFÍO: desafíos o estado actual (AS IS): define las condiciones actuales o desafío.
    1. Utiliza visualizaciones simples y claras para representar el estado actual del equipo o del proceso.
    2. Identifica desafíos (Challange) como áreas de mejora y oportunidades basadas en la realidad actual.
  3. META: meta o estado siguiente (TO BE): elige tu próximo objetivo o meta..
    1. Establecer objetivo siguiente (Target Condition): define un objetivo específico y alcanzable para el próximo periodo o sprint; y asegúrate de que el objetivo esté alineado con la visión y las metas a largo plazo.
  4. OBSTÁCULOS: Detecta obstácules (Obstacle) que impiden alcanzar los desafíos.
  5. EXPERIMENTOS: Idea experimentos accionables (Experiment): con el objetivo en mente, realiza brainstorming sobre posibles acciones y experimentos concretos; y prioriza estos experimentos según su impacto y viabilidad.
    1. Cierre de retrospectiva.
  6. Ejecutar experimentos (luego de la retrospectiva): 
    1. Implementa los experimentos planificados durante el periodo especificado.
    2. Documenta los resultados y observaciones cuidadosamente.
Lienzo:




Recomendaciones


La mejora continua con Improvement Kata requiere más de una retrospectiva, ya que es un proceso continuo. Algunas recomendaciones son las siguientes:


  1. La visión (Vision): la visión proporciona la dirección y los límites para la mejora. A menudo eso significa definir una visión que contenga las capacidades centrales que la definen.

  2. Un Desafío (Challenge) es un subconjunto de la Visión:

    1. Plazo de 2 a 6 meses.

    2. Solo trabajas en un desafío a la vez.

  3. Meta o una condición objetivo (Target Condition) es un subconjunto del desafío:

    1. Plazo de 4 semanas.

    2. Simplemente trabaja en una condición objetivo a la vez.

  4. Obstáculos (Obstacles) es una cuestión específica que no nos permite alcanzar la Condición Objetivo:

    1. Cronograma de varios experimentos.

    2. Simplemente trabajas en un obstáculo a la vez.

  5. Experimentos para superar obstáculos:

    1. Plazo de uno a diez días.

    2. Simplemente ejecuta un experimento a la vez.






Ejemplo de visión

La visión puede ser algo simple o algo más sofisticado.
Por ejemplo, para definir una visión para buscar mejoras conducentes hacia un ecosistema Agile, podemos definir una que contenga las capacidades centrales que definen lo ágil para la organización. Jesper Boeg define, en su libro (Level Up Agile With Toyota Kata), ocho capacidades que las organizaciones ágiles deberían esforzarse por establecer:
  1. Alineación estratégica.
  2. Equipos empoderados y autoorganizados.
  3. Equipos estables de extremo a extremo con una asignación del 100%.
  4. Siempre lanzable: todo el trabajo, en cualquier momento, completamente automatizado a pedido.
  5. Pequeños lotes (MVP, MVF), siempre con un enfoque de afuera hacia adentro (desde la perspectiva del cliente).
  6. Gestión visual: plena transparencia.
  7. Retroalimentación continua cualitativa y cuantitativa del cliente y del usuario final.
  8. Flujo uno a uno (Limitar el trabajo en progreso).
Una visión más simple es como la del siguiente ejemplo.

Ejemplo de resultado de retrospectiva


Visión: 
  • Mejora Continua basada en Datos: En nuestra incansable búsqueda de excelencia técnica, nos comprometemos a mejorar continuamente basada en datos de nuestro desarrollo de software, reconociendo que el rendimiento de nuestros equipos es la esencia de nuestro éxito, y que las Four Keys Metrics, son nuestro faro guía para medir y perfeccionar nuestras prácticas.

Desafíos: 
  • Transparencia y Medición Efectiva: La falta de visibilidad, datos, métricas significativas y la incapacidad para medir 4KM, dificultan saber cómo estamos basados en datos.

Metas (Target Condition)
  • Paneles de Métricas: Disponer de Paneles de Métricas basadas en 4KM y paneles de métricas de equipo, usando como fuente de datos Jira y GitHub.

Obstáculos:
  • Necesidades de Educación y Capacitación: Los miembros del equipo pueden no estar familiarizados con la interpretación y uso efectivo de métricas como 4KM.
  • Ausencia de Una Cultura de Transparencia: En entornos donde la cultura de transparencia no está arraigada, los equipos pueden ser reacios a compartir métricas públicamente.
  • Malas prácticas en el uso de GitHub y Jira: Los equipos no tienen acuerdos comunes relacionados a flujos de trabajo, prácticas de actualización de Jira, integración de Jira con GitHub y mensajes en los commit a repositorios.
  • Consenso en la Definición de Métricas Relevantes: Puede ser desafiante identificar las métricas más relevantes y significativas para el rendimiento del equipo además de Capacidad: Capacidad (en esfuerzo/tiempo) de personas para invertir en desarrollar herramienta de reportería de 4KM.

Experimentos:
  • Capacitaciones 4KM y buenas prácticas Jira/GitHub.
  • Configuraciones Jira y GitHub.
  • Desarrollo de Dashboards de Jira basados en 4KM.


Referencias:


















jueves, 24 de agosto de 2023

Jira: Odiemos a Jira

 "¡Hey, parece que está de moda criticar a JIRA! 

Normalmente, no suelo ser el tipo de persona que defiende a capa y espada una tecnología en particular, ni siquiera si la adoro. Sin embargo, creo que es importante odiar las cosas por las razones correctas. Si es que, a fin de cuentas, JIRA sigue siendo simplemente la mejor herramienta para rastrear tareas personalizadas con flujos de trabajo a medida, y además permite realizar búsquedas y reportes súper potentes sobre ellas. Ahí está la clave: "a medida". Sí, hay un montón de plataformas que cobran lo mismo o menos que JIRA y te ofrecen un espacio chulo para tus proyectos, pero generalmente se les olvida una de las funciones de personalización o búsqueda que mencioné antes.

Pero, entonces… ¿Por qué se suele odiar a Jira?

Las razones más comunes que escucho para odiar a JIRA son:

  • Es demasiado complicado.
  • Paso más tiempo haciendo seguimiento de tickets que trabajando.


Odian al micromanagement

Si crees que JIRA es demasiado enredado, es porque alguien que lo configuró metió más estados en el flujo, más flujos, más validaciones, pos-funciones, pantallas y campos de los que realmente necesitas para tu trabajo. 

Una búsqueda rápida de "flujo de trabajo complicado en JIRA" nos da esta imagen de idalko.com, parece ser un grupo que ayuda a la gente con sus procesos empresariales. Esta es su manera de cómo NO se hace un flujo de trabajo.


Si tu flujo es así, no odias a JIRA, odias a tu gerente que metió todo eso para saber en qué están en cada momento del día o a tu organización que es muy burocrática y complicada, con procesos enredados y alguien configuró el enriedo de tu organización. 

A ver, JIRA es una herramienta genial para armar flujos como ese, pero no puede impedir que la gente lo use mal. JIRA es tan complicado como tú lo configures. Viene con flujos de trabajo bien sencillos y muy pocos campos en la página. En 5 minutos puedes estar listo para seguir tareas que van desde "Abierto" a "En progreso" y luego a "Cerrado". 

¡Vamos, eso no es pedir mucho! Cualquiera debería poder dar esa cantidad de información sobre su tarea. Aunque esto es útil para metodologías como GTD o para simples tareas, cuando trabajamos con software y con marcos de trabajo como Scrum o Kanban esa simplicidad es algo contraproducente y escueta. También he trabajado en empresas donde equipos tienen flujos y estados super simples y pasan un año y siguen sin hacer testing, demorándose en subir a producción meses y con pésimas prácticas de ingeniería de software. El flujo de trabajo debe servir para coordinarse y para entender el trabajo y mejorar. Según Scrum debe servir para transparencia, inspección, adaptación y mejorar. Y en Kanban debes reflejar tu flujo real de trabajo para encontrar cuellos de botella y mejorarlo. Lo difícil es encontrar un punto medio y simple.

Odian a sus no-gerente

El otro problema común es el no-gerente, el "gerente" que no habla contigo y no sabe mucho sobre lo que estás haciendo. Solo quieren echar un ojo a un tablero, ver todas las luces verdes y contarle a sus jefes que todo está bien. Este tipo de gerente te pide estimaciones detalladas de tiempo (deadline), 15 pasos en el flujo de trabajo y actualizaciones diarias. Claro, JIRA es una herramienta que puede hacer todo esto, pero no significa que deba hacerse. JIRA no reemplaza la necesidad de gerentes hábiles y líderes de equipo que realmente sepan qué está pasando, que confíen en sus equipos, que generen claridad, empoderamiento y faciliten el proceso.

Odian a cualquier gerente (a la transparencia)

Seamos sinceros: quizás no sea tu gerente, quizás seas tú. En algunos proyectos en los que he trabajado, el seguimiento de tareas no es precisamente bienvenido, pero también rechazan la agilidad (Agile).

Hay gente que prefiere que le asignen tareas, tener mucho tiempo para hacerlas, a su ritmo lento, y asegurarse de que nadie más sepa cómo hacer su trabajo, no sea que los reemplacen. 

Yo creo que siempre habrá trabajo para gente hábil y trabajadora. Las habilidades que necesitas pueden cambiar, pero siempre habrá trabajo por hacer. Enfoca tu tiempo en perfeccionar esas habilidades y en encontrar un buen lugar para trabajar, en lugar de tratar de proteger tu empleo actual escondiendo lo que haces.

Odian Aprender

Hay quienes odian a Jira porque no quieren aprender a usar herramientas nuevas. Probablemente esperaban que JIRA fuera como un botón mágico para manejar tus actividades o desarrollos. Quieren las funciones que ofrece, pero no quieren invertir tiempo en aprender a usar la herramienta. O peor aún, odian aprender y mejorar, y si tienen que dar transparencia de su trabajo y de cómo trabajan pueden quedar en evidencia, de que son persona de mentalidad fija y conformistas de su zona de confort, que puede ser desordenada y poco productiva. Entonces les molesta transparentar su forma de trabajar.

Buscar el equilibrio

Mi consejo es encontrar el punto medio: ni flujos muy simples que no sirven para mejorar ni coordinarse ni flujos super complicados; ni issues con descripción vacía y títulos que no dicen nada, ni issues que sean un documento de requerimiento detallado (exceso de documentación); tampoco ausencia de issues, ni el extremo de estar detallando toda tarea que se hace; ni NO reflejar esfuerzo, ni tampoco estar trackeando todos los días cada hora en que se ha consumido (micromanagement).

Pienso que un flujo de trabajo más simple que sirve para gestión, iniciativas, Scrum y Kanban es el siguiente: 

Para historias de trabajo de desarrollo de software me ha servido algo bien simple como: Backlog, Selected For Development, In Progress, Ready for Accept, Done, Closed. La separación de Done a Closed es para reflejar que puede haber un tiempo de incremento potenciablemente entregable (pasó una definición de terminado) a entregado (listo en producción). Sino el estado Closed es inecesario. O algún flujo semejante como el siguiente.


Cuando configures Jira y lo uses, piensa en lo siguiente:

  • Aplica los valores y principios del manifiesto ágil, de Scrum o Kanban.
  • Los flujos ni tan simples ni complicados, con estados grises al principio (pocos), estados azules en el medio y verdes al final (uno o pocos).
  • En los flujos no agregar validaciones, ni pantallas emergentes ni pos-funciones. Solo alguna si es necesaria.
  • No agregar muchso campos personalizados.

Jira es una plataforma inmensamente poderosa y, con un poco de trabajo y planificación, puedes asegurarte de que esté configurada exactamente como deseas. Como resultado, podrás desbloquear un enorme aumento en la productividad.

Referencia: 

https://jarvispowered.com/you-dont-hate-jira-you-hate-your-manager/

https://www.smartsheet.com/jira-workflow-best-practices




jueves, 3 de agosto de 2023

Retrospective: Check out o feedback final

 

Esta actividad permite identificar si nuestra reunión está causando el efecto esperado o si tiene puntos de mejora. Es una actividad de salida ocurre justo antes de que los participantes salgan de la reunión. Por lo general, recopila información sobre la reunión en sí: qué tan valiosa fue, cuánto se aprendió, qué tan valiosa fue la reunión, cualquier comentario específico o estado de ánimo de salida.

El resultado de la actividad de salida puede contener comentarios valiosos sobre la estructura y el contenido de la reunión. Considéralo cuando planifiques la próxima reunión.

Son actividades muy cortas. Piense en ello como un check-out de hotel efectivo, donde el huésped (participante) abandona el hotel rápidamente, con la sensación de ser escuchado y dando una valiosa retroalimentación al hotel.

A continuación te comparto algunos ejemplos:

¿Qué te pareció?




¿Cómo me voy?


Repeat/Avoid

Ejecutando la actividad:

Pida a los participantes que agreguen sus notas en consecuencia:

* ¿Qué debemos repetir?

* ¿Qué se debe evitar?

Agrupe las notas y discuta.

Esta es una actividad retrospectiva común para la recopilación de datos. Es una alternativa para mantener al equipo comprometido mientras cambia ligeramente el formato.






Referencias:






jueves, 18 de mayo de 2023

Agile Team: El rol Agile Team Leader o Líder de Equipo Ágil

Hay diferentes autores que proponen o hablan de "Agile Team Leader" como una idea de líder de equipo ágil más amplia que la figura de Scrum Master o roles semejantes que están atados a un framework en particular.

Por ejemplo Henrik Kniberg habla de "Líder de Equipos Ágiles" en el libro "The Agile Team Leader: A Practical Guide to Building High-Performing Teams", como un profesional que asume el rol de liderazgo en un equipo que trabaja bajo enfoques ágiles, como Scrum o Kanban. Este líder tiene la responsabilidad de guiar al equipo hacia la excelencia, promoviendo los valores y principios ágiles, y facilitando un entorno propicio para el alto rendimiento.

El líder de equipos ágiles no es un líder autoritario o jerárquico tradicional, sino alguien que actúa como un facilitador, un mentor y un defensor del equipo. Su objetivo principal es apoyar a los miembros del equipo en su desarrollo individual y colectivo, fomentando la colaboración, la autonomía y la mejora continua.

Este líder tiene la capacidad de influir en el equipo, pero su enfoque no es dar órdenes o imponer su voluntad, sino más bien empoderar a los miembros del equipo para que tomen decisiones y asuman responsabilidad. También se espera que el líder de equipos ágiles sea un ejemplo de los valores ágiles, como la transparencia, la adaptabilidad y el enfoque en el cliente.

En resumen, para Henrik Kniberg, un líder de equipos ágiles es alguien que dirige y guía al equipo de manera colaborativa y facilitadora, fomentando la autogestión, la innovación y la entrega de valor en un entorno ágil.

Por otro lado, la autora Lyssa Adkins habla de liderazgo ágil de equipos en su libro "Agile Team Leadership: A Practical Guide to Empowering Your Team and Achieving Results". Para ella un líder de equipos ágiles es alguien que se encarga de guiar, empoderar y apoyar a los equipos en la adopción y práctica de metodologías ágiles. Este líder se enfoca en fomentar un entorno de trabajo colaborativo, motivador y de alto rendimiento.

El líder de equipos ágiles es aquel que entiende y abraza los principios y valores ágiles, y los utiliza como base para influir positivamente en el equipo. Tiene la capacidad de inspirar y motivar a los miembros del equipo, ayudándolos a desarrollar su autogestión, toma de decisiones y colaboración efectiva.

Este tipo de líder se enfoca en facilitar la comunicación y la transparencia, promoviendo la confianza y la apertura en el equipo. Además, brinda soporte en la resolución de conflictos y en la gestión del cambio, asegurándose de que el equipo esté alineado con los objetivos del proyecto y de la organización.

Un líder de equipos ágiles también es un facilitador, coach y mentor para el equipo. Ayuda a identificar oportunidades de mejora, impulsa la experimentación y el aprendizaje continuo, y busca formas de optimizar el rendimiento y la productividad del equipo.

En resumen, Lyssa Adkins, un líder de equipos ágiles es aquel que se enfoca en liderar y empoderar a los equipos para que trabajen de manera efectiva, colaborativa y ágil, utilizando las prácticas y principios ágiles como guía para lograr resultados sobresalientes.

Líder de Equipo Ágil versus Agile frameworks

Cada marco de trabajo propone un rol que asume el liderazgo ágil de un equipo. El rol más conocido es el de Scrum Master, aunque también tenemos al Service Delivery Manager en Kanban, por ejemplo.


Si queremos abstraernos de la metodología ágil o marco de trabajo en particular, podemos usar el término Agile Team Leader (o Agile Team Lead). Es una buena opción para no inventar nombres nuevos. Ponerle nombre a los roles parece una tarea no trivial en los contextos de adopción ágil. Esta podría ser una opción.


Referencias:

  • The Agile Team Leader: A Practical Guide to Building High-Performing Teams by Henrik Kniberg and Mattias Skarin
  • Agile Team Leadership: A Practical Guide to Empowering Your Team and Achieving Results by Lyssa Adkins
  • Agile Leadership: The Team-Centric Approach to Software Development by Jeff Patterson