sábado, 16 de octubre de 2021

¿Cuáles son las ventajas de hacer una PI Planning presencial?

PI Planning presencial - cortesía de Christina Morillo
La primera PI Planning es crítica; estamos aprendiendo una nueva forma de trabajar y necesitamos hacerlo lo más rápidamente posible, así como también establecer buenas conexiones con todos los miembros del ART y crear un sentimiento de pertenencia tribal.

Por otro lado si queremos crear un buen plan que sea factible es necesario tomar decisiones críticas rápidamente y crear alineamiento entre todos los asistentes.

Las reuniones on-line nos ayudan a navegar en un mundo socialmente distanciado, pero es difícil reemplazar los beneficios de una buena PI Planning presencial:
  • Generan una mejor comunicación: las palabras son solo una pequeña parte de la forma en que nos comunicamos, son alrededor del 15-20%, el resto es gestual y corporal.
  • Fomentan relaciones significativas: una buena PI Planning, donde la colaboración es esencial, requiere generar confianza, lo que es mucho más fácil en persona.
  • Crean una atención mejorada: pensemos en cuantas veces estando en una reunión on-line hemos hecho multitarea leyendo el correo electrónico por o ejemplo, e incluso puede que hayamos asistido a más de una reunión a la vez...
  • Generan ideas innovadoras: las conversaciones en un entorno virtual son menos fluidas y conducen a generar muchas menos ideas innovadoras. La serendipia, esos descubrimientos afortunados y valiosos que se producen de manera casual, solo ocurre en un ambiente presencial.

jueves, 30 de septiembre de 2021

¿Cómo es una agenda y el juego de tableros para una Pre-PI Planning?

Solution Train, del tema Solution Train cortesía de © Scaled Agile, Inc.
En este post quiero compartiros como ejecutamos las Pre-PI Plannings en nuestro contexto de un Solution Train con nueve trenes (ARTs). SAFe® nos da una guía muy general sobre este evento ya que, dada complejidad a este nivel, cada organización ha de encontrar su solución, siempre alineada con los 10 principios.

Recordemos que la Pre-PI Planning ayuda a construir un plan alineado entre ARTs para el próximo PI, adaptando la demanda de la solución a las capacidades de los ARTs individuales. También es la ocasión ideal para identificar dependencias, para aclarar qué ART necesita qué de quién y para cuando. Alinea a los Product Managers, arquitectos de sistemas y otras partes interesadas de los trenes (ARTs) alrededor de una visión común. Su objetivo principal es:
  • Informar sobre los resultados de las planificaciones e iniciativas de negocio
  • Informar sobre la visión y habilitadores (enablers) del Solution Train
  • Discutir objetivos derivados del Solution Train
  • Aclarar dependencias y su manejo para el siguiente PI
  • Alinear las prioridades del Solution Train para el próximo PI

La agenda que nosotros manejamos es como sigue:

7:30 a 8:00 - Bienvenida
El momento ideal para una taza de café y socializar :-)

8:00 a 10:00 - Contexto de negocio y visión del Solution Train
  • El CEO o ejecutivo senior describe el estado actual de la empresa, comparte la visión empresarial y presenta el estado actual de la solución y el portfolio
  • STE presenta:
    • Resultados de la ejecución del PI anterior
    • Resultados de la Solution Demo
    • Agregación de las medidas de predictibidad a nivel de solución
  • Solution Managment presenta la visión actual de la solución
  • El Solution Architect proporciona la cantidad justa de orientación de arquitectura y experiencia del usuario

10:00 a 10:45 - Solution Backlog
El Solution Manager, junto con los Product Managers, presentan las capabilities principales y les asignan ART para el próximo PI.

10:45 a 11:00 - Descanso

11:00 a 13:00 - Breakouts
Previamente a la Pre-PI Planning habremos efectuado un taller para identificar a grandes rasgos qué breakouts son necesarios. En éstos breakouts aquellos ARTs que tengan dependencias se reúnen para:
  • Identificar, discutir, acordar, documentar dependencias significativas
  • Rellenar el tablero de objetivos por ART

13:00 a 14:00 - Comida

14:00 a 15:00 - Revisión del Solution Planning Board
Product Management presenta los resultados de la planificación con foco principalmente en:

15:00 a 15:45 - Identificación de objetivos principales
En base al Solution Planning Board identificamos los objetivos preliminares del Solution Train. Son preliminares ya que en Post-PI Planning confirmaremos o ajustaremos éstos objetivos en base a los resultados de las PI Plannings individuales.

15:45 a 16:39 - Cierre y retrospectiva
Cerramos con una retrospectiva para recoger feedback del evento, por ejemplo un tablero con "qué ha ido bien", "qué no ha ido bien" e "ideas".

Tablero Pre-PI Planning (Solution Planning del tema Pre- and Post-PI Planning cortesía de © Scaled Agile, Inc.)

SAFe and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.

martes, 21 de septiembre de 2021

¿Cómo entender la diferencia entre criterios de aceptación y definición de hecho?

Para considerar una historia terminada
Los que estamos familiarizados con la Agilidad sabemos que las cosas están terminadas o no terminadas, no hay término medio... un 99% terminado en esencia es NO terminado. Si tenemos cosas grandes las dividimos en partes menores de manera que cada una de ellas aporte valor, y éstas las vamos terminando al 100% para agregar valor de forma paulatina.

Esas cosas pequeñas las conocemos como historias de usuario. La manera de medir si están terminadas es utilizando los criterios de aceptación, que responden a la pregunta ¿cuál es comportamiento que ha de mostrar la historia de usuario específica?, y la definición de hecho (DoD), que responde a ¿qué tiene que cumplir cualquier historia para que se considere terminada?

Definition of Done vs. Acceptance Criteria
Los criterios de aceptación describen comportamientos que hace el producto cuando se complete la historia de usuario, por tanto no son cosas que el equipo de desarrollo haga sobre producto. La definición de hecho es un conjunto de actividades obligatorias que el equipo ha de efectuar para cada historia de usuario.

La imagen de la derecha, que inicialmente encontré en un post en LinkedIn, y que luego descubrí que proviene del artículo "Definition of Done vs. Acceptance Criteria" de Michael Küsters, arroja muchísima claridad sobre la diferencia entre criterios de aceptación y la definición de hecho.

Criterio de aceptación
Definición de hecho
Describe...
lo que el producto hacelo que el equipo hace
Calidad del...
producto desde el punto de vista del usuariotrabajo desde la perspectiva del proceso
Aplica a...
a una historia de usuario específicageneralmente a todos los elementos de la pila de producto
Se cumple cuando...
se verifica los testacuerdo del equipo

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.