martes, 31 de agosto de 2021

¿Cuál es el Manifiesto para un líder al servicio ágil?

Todos sabemos que en última instancia una transformación ágil es una transformación de la cultura de la compañía. Iniciamos una transformación mediante la implantación de nuevas prácticas y procesos que planten la semilla para que, en caso de que la compañía permita el cambio cultural, se implante la Agilidad.

El Manifiesto Ágil para el desarrollo ágil nació para dotar a los equipos de la cultura necesaria para que Scrum y otros métodos ágiles puedan dar sus frutos en cuanto a la entrega de valor. Hoy en día hablamos de escalado y de transformaciones de grandes compañías para las que el Manifiesto Ágil es necesario pero no suficiente.

Los directivos y líderes de una gran compañía son todos ellos responsables del éxito de una transformación ágil, ya que solo ellos tienen la autoridad para cambiar los sistemas que gobiernan cómo se realiza el trabajo. Solo ellos pueden crear un entorno que aliente a los equipos a prosperar y a producir valor.

Necesitamos líderes que apoyen la mentalidad ágil ejemplificando comportamientos, y que inspiren y motiven a los equipos a buscar mejores forma de trabajar. Líderes que lideren activamente el cambio participando y guiando las actividades necesarias para comprender y optimizar continuamente los flujos de valor de la compañía.

Es por ello que quiero presentar el Manifiesto del líder ágil que ha creado Agile Cooking; en él encontraréis la mentalidad necesaria para aquellos lideres que quieran implantar Agilidad en sus compañías tengan éxito.
Manifiesto del líder ágil de Agile Cooking

miércoles, 11 de agosto de 2021

¿Qué tienen en común los tomates y las consultoras de transformación?

Tomate commodity donde compites por precio
Cortesía de Engin Akyurt en Pexels
¿Alguna vez habéis comido esos tomates que tienen un sabor intenso, jugoso y que no puedes dejar de comer? Yo si, y desde entonces voy loco por saborear de nuevo esos tomates, y lo importante para este post es que no me importa el precio, ¡pago gustosamente de 6 a 10 eur por kilo!

Por otro lado es muy fácil encontrar tomates commodity, por ejemplo en el Carrefour a 1,35 y 1,45 eur el kilo, tomates buenos sin duda, pero que no me generan placer al comerlos.

Estamos ante dos modelos de negocio muy distintos, el commodity, donde compites al precio más bajo, donde un décimo de céntimo puede marcar la diferencia y donde impera la industrialización; y el gourmet, que va a microsegmentos de clientes donde importa la calidad y no el precio, y que se basa en recursos locales, tanto en la agricultura como en la distribución.

¿Y qué tienen que ver las consultoras de transformación con todo esto? Hoy en día prácticamente todas las grandes empresas internacionales están haciendo esfuerzos en su transformación ágil. Estas empresas prefieren un proveedor de consultoría grande e internacional ya que les inspiran seguridad y llevan a creer que así garantizan una transformación exitosa.

Para transformar una empresa empezamos incorporando nuevos procesos y nuevas prácticas, y así crear el entorno en el que se fomente la responsabilidad compartida y la colaboración, pero muchas veces nos olvidamos de que una transformación ágil es en el fondo una transformación en el comportamiento de las personas. 

No hay transformación si las personas no aprenden a comportarse acorde con lo que nos trae la Agilidad, por ejemplo los mandos y directivos deberán de aprender a comportarse como lideres al servicio. Y esa transformación ha de hacerse partiendo de la realidad del momento, incluida la cultural de personas y empresa.
Tomates gourmet donde te diferencias por la calidad
Cortesía de Son Tung Tran en Pexels
Una gran transformación liderada por una consultora internacional probablemente no sea la más potente, no se trata de formar en Agilidad y luego acompañar en procesos y prácticas e irse. Es crítico transformar a las personas, y eso requiere a expertos locales, coaches ágiles locales inmersos en la cultura local con suficiente libertad y pasión como para llevar a cabo un acompañamiento exitoso. Es muy diferente unir y crear puentes entre españoles que entre alemanes por ejemplo... y de eso sé un rato, jajaja.

Y ahí es donde entran los tomates gourmet; para basar nuestro negocio en tomates con sabor y que deleiten la transformación en nuestros grandes clientes necesitamos soluciones locales, agricultores y distribuidores locales, a la vez que cobertura internacional.

Una solución excelente a esta necesidad se basa en la colaboración internacional y a largo plazo de consultoras locales, ser partners de multitud de consultoras a lo largo y ancho del globo para adquirir esa diversidad y multifuncionalidad necesaria para poder transformar en su máxima potencia a compañías internacionales.

Si por ejemplo trabajamos con equipos localizados en España, la mejor solución es una consultora con coaches ágiles nativos españoles, y si en un momento dado necesitamos dar servicios de formación o de Scrum Master en la India, la solución ideal es que colaboremos con una empresa en la India que se encargue de dar esos servicios.

Esta solución requiere mucha transparencia y hay que dejar de lado la competencia, necesitamos colaborar entre los que fueran nuestra competencia en otros países para poder sobrevivir en este mundo global VUCA.

viernes, 23 de julio de 2021

¿Cómo revisamos de forma sistemática la demanda versus la capacidad del sistema del sistemas Kanban?

Revisión de un sistema Kanban - cortesía de cottonbro
Para revisar como está funcionando nuestro sistema Kanban, el modelo de madurez Kanban (KMM) introduce en el nivel 3 la Improvement Suggestions Review, o revisión de sugerencias de mejoras, uno de los eventos del ciclo de eventos Kanban donde se revisan las sugerencias de mejora identificadas por los miembros del equipo.

El evento se establece con periodicidad, habitualmente 1 vez al mes y con una duración máxima de 1 hora, y al que asisten representantes del flujo de trabajo o prestación del servicio y opcionalmente un facilitador.

En ella se tratan las sugerencias de mejora identificadas por los miembros del equipo, mejoras sobre el tablero Kanban e ideas, para decidir cómo abordarlas y cuáles implementar ahora, más tarde o nunca.



En el nivel 4 del modelo de madurez Kanban (KMM) la Improvement Suggestions Review se sustituye por la Operations Review, o revisión de operaciones, para revisar como los sistemas Kanban individuales funcionan juntos y de cómo sus dependencias están siendo equilibradas por la organización respecto a la demanda y a la capacidad del "sistema de sistemas" general.

El desempeño de la organización se basa en optimizar cada equipo y la organización como un sistema completo, y este evento proporciona la visión sistémica (holística). Analizamos la eficiencia de los diferentes equipos y de la organización en su conjunto. Luego revisamos la demanda y la capacidad de cada equipo Kanban, enfocándonos en las dependencias y sus efectos.

Su periodicidad se establece habitualmente 1 vez al mes y con una duración máxima de 2-2,5 horas, y a la que asisten SDM y SRM de cada sistema, gerentes, colaboradores individuales, representantes de clientes por sistema Kanban y opcionalmente un facilitador.

Se circunscribe a un producto o unidad de negocio y sus inputs son:
En base a las dependencias encontradas y efectos interdependientes expuestos se sugieren eventos Kaizen y se asignan oportunidades de mejora.

Las sugerencias de mejora, decisiones, cambios y acciones de esta reunión se comunican de vuelta en los eventos de las Service Delivery Reviews, la Statregy Review y las Risk Reviews.

domingo, 18 de julio de 2021

¿El Scrum Master es responsable de las métricas?

Lo que no se mide no se puede mejorar
Cortesía de Pixabay
Recientemente asistí al meetup "Stand Up Agile - Aprendiendo con Humor" en el que Rogger Bravo intervino con lo la idea del Agile Hippie; un coach ágil focalizado en personas y que obvia las métricas de negocio. Cuenta que, como muchos de nosotros, ha sido un Agile Hippie hasta que un día le preguntaron:
  • ¿Qué tipos de indicadores de negocio manejas?
  • ¿Cómo te anticipas estadísticamente con pronósticos de resultados?
  • ¿Cómo manejas un flujo de Kanban para que esté apto para su propósito y no enfocado al equipo?
  • ¿Cómo sabes que estás entregando valor al cliente?
Aprendió que la mayoría de coaches ágiles estamos principalmente orientados en el rendimiento de los equipos en lugar de negocio, y el negocio ha de ser rentable. Lo que no se mide no se puede mejorar, por tanto las métricas de negocio han de medirse.

Obtenemos aquello que medimos, por tanto necesitamos métricas que fomenten la entrega de valor (flujo), una mentalidad y buen comportamiento ágil (competencia) y también resultados adecuados:
  • Flujo: ¿Qué tan eficiente es la organización en la entrega de valor al cliente?
  • Competencia: ¿Cuán competente es la organización en las prácticas que permitan Business Agility?
  • Resultados: ¿Nuestras soluciones satisfacen las necesidades de nuestros clientes y del negocio?
Esta métricas requieren una comprensión fundamental de la economía de los sistemas de construcción y nos permiten estar alineados con el objetivo de Lean/Agile: ofrecer el mejor valor y calidad para las personas y la sociedad en el menor tiempo de entrega sostenible.

Por tanto los coaches ágiles y los Scrum Masters somos los responsable de que se tomen las métricas que aporten valor. Participan en la definición de las mismas, directamente en las de flujo y competencia, y en las de resultados entendiendo las necesidades de quiénes las solicitan. En lugar de simplemente producir métricas e informes a ciegas, lo mejor que puede hacer un Scrum Master es comprender el problema y trabajar con quienquiera que esté solicitando las métricas para obtener la mejor información posible que pueda ayudarlos a resolver sus problemas con la menor cantidad de trabajo innecesario o adicional.

viernes, 16 de julio de 2021

¿Qué especialistas pueden formar un equipo multidisciplinar enfocado a procesos?

Equipo de procesos - cortesía de Pixabay
Una de las experiencias más interesantes que he vivido fue el acompañamiento de una tribu dedicada a la mejora y refinamiento de los procesos del área de Servicio al Cliente.

En este post quiero exponer con qué especialistas diseñamos los equipos multifuncionales de procesos que integraban la tribu.

Process Owner - Es el responsable de la pila con las mejoras y deficiencias a resolver, de su priorización y tiene autoridad de decisión para aprobar las modificaciones en los procesos que recomiende el equipo. Actúa de Propietario del Producto/Proceso y establece los objetivos generales del equipo. Hace de interfaz con el área operativa y de negocio para asegurar la implantación de las mejoras y modificaciones de los procesos resultantes de los proyectos de mejora. También es el interfaz principal con las áreas para el seguimiento operativo de objetivos y KPIs.

Process Expert - Tiene un conocimiento profundo del funcionamiento actual de los procesos existentes, sus diagramas de flujo, cuales son las distintas acciones y actividades que los forman, además del orden en el que se llevan a cabo. Entiende lo que es importante y aquello que ocasiona cierta repercusión en la satisfacción del cliente o en la operatividad de la organización.

Customer Journey Expert - Experto en el customer journey, las fases por las que pasa un cliente desde que identifica que tiene una necesidad hasta que adquiere un producto o servicio para solucionarla. Se asegura de una buena experiencia de cliente creando una conexión emocional con estos.

IT/Sistemas - Realiza una evaluación preliminar de los impactos en IT de las modificaciones que se identifiquen. También participa en la definición de las mejoras para asegurar la mejor solución técnica en cuanto a funcionamiento, coste y plazos. Es el interfaz con el área de sistemas para realizar análisis de viabilidad de manera ágil. Hace seguimiento del estado de los desarrollos en curso con el área de sistemas para asegurar que se ponen en producción en los plazos previstos.

Front Liner - Persona de la primera línea (comercial, tienda, agente televenta, agente de servicio al cliente, etc…) que proporciona feedback de primera mano sobre el funcionamiento de los procesos, sistemas, ergonomía, facilidad de uso y feedback de los clientes. Asegura que las soluciones y mejoras propuestas sean operables fácilmente por la primera línea. Sirve de enlace con la primera línea para dar feedback de cómo sus puntos de vista son tenidos en cuenta y de las soluciones y mejoras que el equipo haya identificado.

sábado, 3 de julio de 2021

¿Cómo planificamos y gestionamos las entregas a los clientes en Kanban?

Delivery Planning Meeting
El evento que sirve para planificar/replanificar la entregas de valor a clientes se denomina Delivery Planning Meeting, o reunión de planificación de entregas. Esta es una de las reuniones del ciclo de eventos de Kanban y solo aparece en el nivel 3 del modelo de madurez Kanban (KMM).  

Nuestros clientes desean previsibilidad y no encontrarse con un montón de trabajo a intervalos aleatorios. En esta reunión se revisa el trabajo realizado y se decide cómo, cuándo y qué entregar, y preferiblemente con la participación del cliente.

La duración máxima de la reunión es de 1 a 2 horas dependiendo de la cadencia de entregas. Su frecuencia debe ser la suficiente para garantizar que el sistema Kanban atienda adecuadamente las necesidades del cliente.

La reunión la facilita el SDM (Service Delivery Manager) y asisten todos los responsables en la toma de decisiones sobre entrega y cambios, así como cualquier interesado o persona involucrada en la logística de entregas.

Se hace ante el tablero Kanban y se empieza revisando el resultado de las reuniones diarias para dar respuesta a las siguientes cuestiones:
  • ¿Qué elementos se incluirán en la próxima entrega programada?
  • ¿Qué se requiere para entregar cada elemento?
  • ¿Qué riesgos hemos de mitigar?
Los puntos principales a tratar son:
  • Información sobre qué elementos están potencialmente disponibles para entregar: qué está listo para entregar, y qué es probable que esté listo para entregar pronto.
  • Consideraciones de riesgo que puedan afectar a las decisiones de entrega.
  • Decisiones sobre qué artículos entregar teniendo en cuenta la opinión de las personas que recibirán la entrega.
  • Actividades de capacitación o transferencia requeridas para garantizar una transferencia fluida.
  • Cambios en la clase de servicio de algún elemento: por ejemplo si un elemento se ha de entregar a corto plazo la clase de servicio de ese elemento puede cambiar de "estándar" a "fecha fija".
  • Generar compromiso de entrega.

miércoles, 23 de junio de 2021

¿Cómo gestionar riesgos con ROAM?

Tablero para ROAM - Thanks to Philippe Garin
El objetivo de la gestión de riesgos con ROAM es ayudar a los equipos y trenes (ARTs) a asegurarse de que todos los riesgos potenciales se aborden de forma adecuada. Se trata de una técnica muy simple para identificar y gestionar los riesgos de forma transparente, eficaz y proactiva.

Es una gestión esencial que puede marcar la diferencia entre el éxito y el fracaso; la falta de una gestión de riesgos puede hacer descarrilar a los equipos y trenes aún habiendo efectuado excelentes planificaciones.

ROAM es el acrónimo de Resolved, Owned, Accepted y Mitigated y se refiere a los cuatro tipos de acciones sobre cómo manejar un riesgo potencial.

La técnica comienza por agrupar riesgos de acuerdo con las cuatro acciones:
  • RESOLVED riesgos detectados pero que no son una amenaza, no necesitan una acción
  • OWNED: riesgos sobre los que alguien toma la responsabilidad de gestionarlos a posteriori
  • ACCEPTED riesgos que simplemente se asumen y se traten según vaya siendo necesario
  • MITIGATED: riesgos para los que se ha decidido un plan de acciones mitigantes concretas
Una vez organizados los riesgos en estas categorías se realiza una votación para decidir en qué riesgos vale la pena trabajar y cuales no, y con cuales empezar. Habrá responsables de ejecutar acciones de mitigado y de gestión cuyos resultados se trataran de forma periódica en el foro correspondiente.

Los riesgos más pequeños se gestionan a nivel de equipo mientras que los riesgos más grandes, que afecten a los trenes, se tratan a nivel de programa. Cada equipo debe tener un foro regular para tratar los riesgos ante un tablero a tal efecto, una excelente solución es incluir la gestión de los riesgos en la daily.

Para el tren tenemos un tablero a nivel del programa, donde recogemos los riesgos y que permite discutir abiertamente todos los factores que pueden obstaculizar el progreso del tren. El tablero se informa por primera vez durante la PI Planning, cuando equipos individuales descubren riesgos potenciales que pueden afectar al tren. La responsabilidad de asegurar que los riesgos se gestionen es del RTE, quien conoce quién es responsable de mitigarlo o quién es dueño de gestionar qué riesgo.

El foro donde se gestionan los riesgos a lo largo del PI es la PO-Sync; se mueven riesgos de un área a otro en función de los que haya ocurrido, por ejemplo si acciones de mitigado han resuelto el riesgo este se mueve a resolved. Resaltar que a lo largo del PI pueden surgir nuevos riesgos que haya que gestionar y que se incorporan al tablero.

Mis agradecimientos a Philippe Garin y os invito a leer su post sobre ROAM "Gestion des risques: Le tableau ROAM"

jueves, 17 de junio de 2021

¿Introducir elementos de proyectos en una PI Planning tiene algún beneficio?

En algunas realidades de compañías que vivo seguimos intentando conciliar dos mundos con objetivos divergentes: los proyectos cerrados, que se focalizan en cumplir con el alcance, coste y tiempo, y la entrega incremental de valor con Scrum.

Llegada la PI Planning les pedimos a los equipos crear un plan a partir de una mezcla de requisitos de proyectos cerrados y elementos de una pila de producto.

La regla que definimos para ello parecía simple y de sentido común:
  1. Planificar todo el trabajo proveniente de los proyectos
  2. Rellenar con elementos de la pila de producto hasta que se haya agotado la capacidad
Sobrecarga en cada una de los sprints
Los beneficios esperados eran:
  • Un equilibro de lo planificado con la capacidad del tren (ART)
  • Identificación y resolución inicial de dependencias entre equipos
  • Una visión sistémica y factible de todo el trimestre, visión que antes no teníamos
  • Al conocer los requisitos de los proyectos antes podíamos efectuar una mejor preparación previa
Esperábamos que si hubiera más carga que la capacidad del tren proveniente de los proyectos, el plan se limitara a los elementos de los proyectos que fuera posible construir.

La realidad fue muy distinta. Las personas nos comportamos como nos miden; los equipos, aunque tuvieron la consigna de no sobrecargase, se sobrecargaron con el ánimo tradicional de "que hay que trabajar en todo lo que nos piden en un proyecto". En la imagen de la derecha vemos un ejemplo real, todos los sprints están sobreacargados, por ejemplo una carga de 55 puntos de historia cuando la capacidad es 46, ¡179 cuando la capacidad es 33!...

Las disfunciones que detectamos en la "PI Planning" fueron:
En conclusión no podemos dar objetivos divergentes (la de los proyectos cerrados y la de entrega de valor) a los equipos. Quizá podamos incluir algún proyecto menor en la PI Planning, quizá sea inevitable, pero la mentalidad de una compañía que quiera ser competitiva en el mercado y focalizarse en la entrega de valor, tiene que basarse en los valores y principios Lean-Agile.

Para cerrar el post quiero añadir que el segundo día de la PI Planning fue un infierno. La consigna de no sobrecargarse siguió siendo válida, aunque la de terminar los proyectos también... con lo que los equipos replanificaron para sobrecargarse de nuevo. Al cabo de tres meses tuvimos una lectura interesante y positiva: el hecho de haber realizado una PI Planning y haber "implementado SAFe®" provocó que con solo una entrega del 43% de los puntos de historias planificados, entregamos un ¡91% de valor!

viernes, 4 de junio de 2021

¿En la planificación de sprint se limita la carga al 80% de la capacidad?

80% gracias a Pixabay
Hay algo de confusión cuando en Scrum decimos que se recomienda que los equipos no se carguen más allá del 80%, pero ¿del 80% de qué?

Si fuera de la carga (la cantidad de puntos de historia que un equipo pone en su pila de sprint) con respecto a la capacidad (la cantidad de puntos de historia que el equipo puede acometer en un sprint) algo no encaja... Al fin y al cabo la capacidad se basa en la velocidad (media de puntos de historia finalizados/entregados en los últimos sprints), que es una métrica objetiva a final de sprint que incluye todo lo que sea singular en ese equipo.

Para quién le interese podéis encontrar en mi post "Cuál es la diferencia entre velocidad, capacidad y carga en Scrum?" la definición de estos conceptos.

En otras palabras, si hemos medido en los tres últimos sprints que el equipo ha entregado digamos 31, 29 y 32 puntos de historia, podemos llenar el siguiente sprint con alrededor de 30 puntos de historia y estar razonablemente seguros de la entrega de todo lo planificado. Aquí no aplica el 80%...

Dónde si aplica este 80% es en el nivel más alto de desempeño de los equipos, desempeño que éstos alcanzan cuando la ocupación es del 80% de su tiempo.

En project management los jefes de proyecto aplican algo llamado factor de enfoque o Focus Factor; generalmente no planifican más de entre 6 y 6,5 horas diarias (de las 8) de cada persona para ejecutar un proyecto. Por tanto el factor de enfoque no es más que la capacidad de los equipos para mantenerse enfocados sin ningún impedimento en los objetivos del sprint.

Cuando trabajamos con horas se obtiene la "capacidad real" multiplicando la capacidad total, en horas, por el factor de enfoque. Por ejemplo, con un factor de enfoque de 80%, la capacidad real en horas de una persona por semana es de 40*80% = 32 horas.

Por tanto planificar una pila de sprint, teniendo en cuenta que no supere el 80% del tiempo disponible del equipo, es un excelente punto de partida. Una vez que el punto de historia se haya interiorizado y hayamos obtenido la velocidad hemos de obviar ese 80%, ya que la experiencia de sprints anteriores permite planificar con mucho más acierto.

domingo, 30 de mayo de 2021

¿Hay alguna dinámica para experimentar la creación de equipos según Team Topologies?

Team Topologies de Skelton y Pais
Para Agility Tres60 2021 Alex y yo preparamos una sesión de Team Topologies; dimos una breve introducción y luego efectuamos una dinámica que queremos compartir en este post.

Primero hablemos de Team Topologies; se trata de una guía práctica para formar equipos de software y permitir que superen sus retos, o para ayudar a equipos existentes a ser más efectivos en la entrega de valor. Describe los patrones organizacionales para la estructura de equipos y sus formas de interacción.

Recordemos las estructuras de equipos:
  • Stream-Aligned Team: Es el tipo de equipo fundamental. Está alineado con parte del flujo de valor de negocio y tiene la responsabilidad de principio a fin del diseño, desarrollo, despliegue, soporte y retirada del producto o servicio, así como de los ciclos de feedback asociados.
  • Platform Team: Su función es reducir la carga cognitiva de los Stream-Aligned Teams a través de, por ejemplo, ofrecer IaaS o PaaS.
  • Enabling Team: Es un proveedor de servicios, por lo general de carácter temporal, y sirve para hacer más efectivos y mejorar las habilidades de los Stream-Aligned Teams, y también detectar si hay brechas en la plataforma o en lo que se espera que hagan estos equipos.
  • Complicated-Subsystem Team: Equipo especializado que reduce la carga cognitiva de los Stream-Aligned Teams. Hacen cosas que requieren conocimiento, experiencia o habilidades muy específicas o sofisticadas, por ejemplo modelos matemáticos, simulaciones, etc.
Y las diferentes formas de interacción:
  • Collaboration: Consiste en trabajar o colaborar muy cercanamente a otro equipo.
  • X as a Service: Proveer algo como un servicio con una mínima colaboración. Los roles involucrados en este tipo de interacción son: Proveer algo y Consumir algo.
  • Facilitating: Ayudar (o hacer coaching) o ser ayudado por otro equipo para eliminar impedimentos.
Team Topologies trata de gestionar la carga cognitiva limitando el tamaño de los servicios y/o productos de software que los equipos puedan manejar. Adopta "Team-First Approach" para establecer los límites del software. Cada servicio o producto debe de ser "propiedad" de un equipo con suficiente capacidad cognitiva para construirlo y operarlo. Trata de equipos pequeños multifuncionales, entre 3 y 9 miembros, cohesionados y longevos que trabajan sobre el mismo conjunto de problemas de negocio durante largo tiempo. Esto se materializa:
  • Limitando los dominios de responsabilidad
  • Limitando el numero de aplicaciones que operan
  • Limitando el número de herramientas que necesitan manejar
Para asignar equipos a dominios:
  • Asignar cada dominio a un único equipo, si de dominio es muy grande para un solo equipo, dividirlo en subdominios y asignar cada uno a un solo equipo
  • Un equipo debe ser capaz de trabajar con dos o tres dominios simples
  • Un equipo que es responsable de un dominio complejo no debe tener otros dominios asignados
  • Evitar que un único equipo sea responsable de dos dominios complicados
Para quién quiera saber un poco más aquí os dejamos una ficha de referencia rápida que Henry Portman ha diseñado y comparte con todos:
Quick Reference Card de Henny Portman traducida por Emiliano Sutil - Thank you!!!
Para la dinámica partimos de un contexto "tradicional" con el objetivo de estructurar equipos e interacciones de forma alineada con Team Topologies. El contexto es el que sigue, también lo podéis descargar en pdf.

La empresa "Conoce el mundo con Gertru y Alex" es una plataforma online de viajes y aventuras que provee los siguientes servicios:
  • Vacaciones en con niños en resorts familiares
  • Viajes exóticos a países lejanos
  • Aventuras con mascotas
  • Rutas gastronómicas
Tiene un área de IT cuya misión es desarrollar y mantener los sistemas y aplicaciones que permiten la operación de la empresa, y está organizado de la siguiente manera:
  • Departamento de Análisis
  • Departamento de Desarrollo
  • Departamento de QA
  • Departamento de Operaciones
Una de sus realidades complejas que tiene que enfrentar son las interfaces con las aerolíneas y los hoteles.

Este departamento tiene entre otros, los siguientes problemas:
  • Tiempos de desarrollo muy largos con muchos bugs
  • Su frecuencia de despliegue es muy baja
  • El nivel de satisfacción de los usuarios es muy bajo
Por esto la empresa ha decidido iniciar una transformación ágil incorporando un equipo de Agile Coaches para, entre otras cosas, reorganizar el área con base en la propuesta de Team Topologies.
La dinámica se efectúa sobre un tablero, en nuestro caso utilizamos Miro, en el que en la parte izquierda se muestra la organización por áreas (silos) tal como se describe en el contexto, y en la parte derecha tenemos un área en la que los asistentes trabajan la reorganización. Para los 4 tipos de equipos hay preparados rectángulos con los colores correspondientes, así como elementos de dibujo para los 3 tipos de interacciones. También hemos puesto una chuleta para tipos de equipos e interacciones.
Tablero listo para ser usado
Leyenda perfiles
Las personas las hemos representado con emoticonos, algunos de ellos para poner una nota de humor en la dinámica. :-)

En la situación inicial las personas están distribuidas y organizadas en sus áreas correspondientes, excepto los Agile Coaches que son nuevos y van a ser los responsables de implantar la reorganización.

La misión de los participantes en la dinámica es reestructurar equipos e interacciones mediante la aplicación de Team Topologies.

Algunas pistas para el facilitador:
  • Cada servicio debería de tener al menos un Stream-Aligned Team
  • Si el software corriera en la nube tendríamos un Platform Team de cloud
  • La complejidad de los interfaces con las aerolíneas y los hoteles podría requerir un Complicated-Subsystem Team
  • Los Agile Coaches que impulsan la reorganización serían un Enabling Team
Dinámica en acción en Agility Tres60, gracias a los participantes

viernes, 14 de mayo de 2021

¿Cómo gestionar bloqueos y riesgos en Kanban?

Equipo ante el tablero de riesgos
Uno de los eventos de revisión del ciclo de eventos de Kanban que se introduce en el nivel 2 del modelo de madurez Kanban (KMM) es la Blocker Clustering, o agrupación de bloqueos. Su propósito es analizar los principales motivos de los bloqueos y su impacto en términos de retrasos, para comprender y mitigar los riesgos que hay detrás de éstos.

El evento se establece con una periodicidad mensual con una duración máxima de 1 hora, y al que asisten representantes y la dirección del equipo, y opcionalmente un facilitador.

Los bloqueos que se tratan en el evento se recopilan a lo largo del periodo en tarjetas a tal efecto, incluyen al menos fecha de inicio y finalización, así como el motivo.

Estos se clasifican en un tablero por fuente/motivo de bloqueo y se analiza de cada categoría el intervalo de tiempo que ha llevado resolverlos:
  • Identificar riesgos
  • Identificar probabilidad e impacto
  • Análisis de causas raíz
  • Identificar acciones de resolución, gestión, mitigación o aceptar el riesgo (ROAM)



En el nivel 4 del modelo de madurez Kanban (KMM) la Blocker Clustering se sustituye por la Risk Review, o revisión de riesgos, cuyo objetivo es comprender y responder a los riesgos para una planificación de entregas de productos y servicios eficaz.
  • Analizar cada riesgo
  • Agrupar riesgos de acuerdo con las acciones: resolución, gestión, mitigación o aceptar el riesgo (ROAM)
  • Definir acciones que posiblemente afecten a las políticas y las clases de servicio
El evento se establece con una periodicidad mensual con una duración máxima de 1 a 2 horas, y al que asisten SDMs (Service Delivery Managers) de diferentes sistemas Kanban, opcionalmente un facilitador y cualquiera de los equipos con información sobre los bloqueos recientes.

Temas a cubrir en la Risk Review:
  • Revisar clases de servicio
    • ¿Siguen siendo apropiados? ¿Están siendo utilizados? ¿Hemos hecho excepciones?
    • ¿Hay un nuevo patrón? ¿Necesitamos una nueva clase de servicio?
  • Revisar bloqueos
    • Priorizar las acciones de mitigación y reducción basadas en el análisis de grupos de bloqueos
    • Revisar las políticas de cobertura de riesgos
    • Considerar si la demanda observada recientemente se ajusta a los patrones históricos, y si la asignación de capacidad sigue siendo apropiada
  • Revisar las políticas de modelado de la demanda
    • ¿Deberíamos ajustar las políticas que dividen la demanda en servicios dependientes o compartidos?

jueves, 13 de mayo de 2021

¿Qué icebreaker virtual se puede utilizar en época de COVID-19?

Los icebreakers virtuales interactivos son divertidos y una forma poderosa para que las personas conectemos, tanto si nos conocemos bien como si acabamos de conocernos. También hacen movernos, nos despegan por un momento de la silla y el ordenador y hacen que corra la sangre, despertándonos y energizándonos.

Preparando una PI Planning María la RTE propuso un icebreaker que es ideal para la época que vivimos y en la que muchos hemos estado fuera de la oficina durante más de un año. Me ha encantado la idea: Reconoce ruidos de la oficina
¿A qué ruido corresponde este sonido? - Cortesía de Pixabay

¿Sabrías distinguir entre el ruido de la máquina de café y el de la secadora de manos del baño? Ambos son ruidos familiares en tiempos de presencialidad, pero ¿y un año después?
Pantallazo del Kahoot con los ruidos de la oficina

Los ruidos habituales en las oficinas, y habitualmente los más molestos, en los que podemos basar el icebreaker son:
  • Teléfonos
  • Impresoras
  • Conversaciones de los compañeros de trabajo
  • Tecleo en los ordenadores
  • El aire acondicionado
Una buena forma para ejecutarlo es mediante un Kahoot con tres láminas con sonidos, convirtiendo el icebreaker en un concurso energizante. Kahoot fomenta la competividad sana recompensando a quienes respondan antes y correctamente para obtener una mayor puntuación y situarles alto en el ranking final. Eso provoca bromas y risas.

La dinámica debe durar como máximo 10 minutos, sino los participantes pueden sentir que pierden el tiempo y perder el interés. ¡A energizar a vuestros equipos! :)

jueves, 29 de abril de 2021

¿Es Agile Coach el trabajo más difícil que existe?

Meme sobre como a veces nos sentimos los coaches ágiles
Me reí mucho cuando vi este meme de la imagen a la izquierda, sobre todo porque es exactamente así como me siento a veces... y parece que esté en un sótano donde el trabajo del coach ágil no es visible, jajaja.

En conversaciones al respecto hablábamos que quizás el trabajo más difícil sea el de médico, ya que a veces se mueren personas, y eso es muy duro. Luego caímos en la cuenta que la cuestión del post es sobre la dificultad de desempeño y, aunque ser médico es emocionalmente duro, sus intervenciones se basan procesos muy probados y siempre están "arropados" en las decisiones difíciles por un comité médico.

La dificultad en el desempeño de un coach ágil es que lidia con la resistencia al cambio. Como expertos en Agilidad traemos cambios a las rutinas y hábitos de los profesionales, y las personas nos negamos de forma natural, por miedo o dificultad, a realizar algo nuevo o diferente. El ser humano es un animal de hábitos y le agrada tener todo bajo control, en consecuencia las situaciones nuevas pueden generar caos, incertidumbre y descontrol.

Resistencia al cambio - from Torbenrick
Las personas están más dispuestas a cambiar cuando ven que sus líderes están cambiando de forma activa, que estos actúan dando ejemplo de cambio. Hay muchas razones de resistencia por parte de los líderes al cambio organizacional:
  • Miedo a lo nuevo
  • Temor al fracaso
  • La gran inversión económica que representa una transformación ágil
  • Pérdida de dinero, trabajadores, clientes o proveedores.
  • Cambios en los beneficios/bonus que ofrece la organización
  • Desconocimiento o desinformación del porqué se realizan los cambios y sus aspectos positivos y/o negativos
Y ahí estamos los coaches ágiles promoviendo el cambio, nadando a contracorriente, sacando a la gente de su zona de confort en una situación en la que no hay un peligro inminente. Algunos líderes ven en el cambio una oportunidad de mejorar, aprender y superarse, y dan permiso a sus equipos a fallar para aprender. Otros se dejan llevar por sus miedos, o tienen otros intereses, así que no escuchan al coach ágil y toman decisiones o ponen restricciones no alineadas con la Agilidad.

Y esa es la razón por la que coach ágil es uno de trabajos más difíciles que existen, su foco está en aquellos que por ahora son un impedimento para la transformación ágil y no sienten la necesidad de cambiar y liderar el cambio.

Un coach ágil sabe que su propio crecimiento es resultado de facilitar el crecimiento en la entrega de valor de otros. Ser coach ágil es una gran oportunidad para servir a los demás, de hacer trascender más allá del logro de un resultado puntual de una actividad o el cumplimiento de un objetivo. Se nos ponen por delante cada día nuevos y apasionantes retos para mejorar la forma de trabajar de equipos y líderes. En mi experiencia es uno de los trabajos más difíciles que existen y a la vez uno de los trabajos más motivantes y apasionados.

martes, 27 de abril de 2021

¿En qué consiste el rol de SAFe® Program Consultant (SPC)?

Responsabilidades del SPC - gracias por la ilustración María Mira

El SPC (SAFe Program Consultant) es un rol fundamental en un proceso de transformación ágil basado en SAFe© (Scaled Agile Framework).

Es el rol experto agente de cambio que combina su conocimiento técnico de SAFe con una motivación intrínseca para mejorar los procesos de desarrollo de software y sistemas de una compañía. Apoya y lidera los primeros pasos, desde la decisión estratégica y el lanzamiento de los trenes (ARTs) a la implantación de un Portfolio Lean. También ayuda a evitar errores habituales en el proceso de transformación acelerando el aprendizaje organizacional y la mejora continua.

Las principales funciones de un SPC son:

Es fundamental que una organización que inicia su transformación ágil tenga el soporte de un equipo de SPCs con un sólido conocimiento del marco de trabajo SAFe, una gran experiencia en implantaciones SAFe y en la formación de los distintos roles que precisa SAFe para su consolidación.

Es habitual, y muy efectivo, que las organizaciones que quieran iniciar su transformación con SAFe contraten equipos de SPCs de empresas dedicadas a apoyar procesos de transformación SAFe, como los son lo es el equipo de profesionales de Estratecno, formado por SPCs que acreditan una especialización de varios años en formación certificada SAFe y en consultoría y acompañamiento de transformaciones SAFe.

jueves, 22 de abril de 2021

¿Cuál es la diferencia entre OKRs y KPIs?

Uno de los puntos que genera muchas dudas es al respecto de estos dos términos; de lo que muchos no son conscientes es que ambos forman un ciclo de feedback cerrado entre estrategia y ejecución. Veamos como se definen los dos conceptos:
  • OKR (Objectives and Key Results o Objetivos y Resultados Clave): representan objetivos que se marcan desde la estrategia para lograr crecimiento y mejora, y cuyo éxito se mide a través de los Key Results. Éstos representan una advertencia temprana, son una brújula, para saber si vamos en la dirección adecuada. Recordar que alcanzar un 60% de los Key Results ya representa éxito.
  • KPI (Key Performance Indicator o Indicador Clave de Rendimiento): se aplican en la ejecución y representan una medida del nivel del rendimiento y progreso de la construcción del producto. Ejemplos son margen bruto, participación de mercado, métricas de calidad, satisfacción del cliente, previsibilidad, NPS, tiempo de ciclo, calidad... en Agilidad los KPIs incluyen entre otras satisfacción de los empleados y desempeño de los equipos ágiles (velocidad).
Ambos forman un ciclo cerrado, los KPIs son las medidas cuantificables que nos permiten evaluar si estamos listos para ir en dirección de los OKRs, y cómo se está desempeñando en comparación con los resultados comerciales pronosticados. Los KPIs dan feedback de realidades a los OKRs, e influyen en la revisión y ajustes de éstos. En el fondo estamos hablando de un ciclo que alinea estrategia con ejecución de forma continuada.
Los OKRs y los KPIs forman un ciclo de feedback cerrado
Imágenes PixaBay: OKR, Equipo Scrum, ART y Incremento, KPI de freepik yTribu de Henrik Kniberg & Anders Ivarsson y KPI