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

martes, 20 de abril de 2021

¿Cómo hacer que historias de usuario afectadas por más de un equipo funcionen?

Equipos coordinándose en una historia de usuario
Cortesía de Pixabay
Si miramos la técnica de calidad INVEST que aplicamos a las historias de usuario, sobre todo los criterios Independent y Small, veremos que éstas están pensadas para ser construidas por un solo equipo dentro de uno de sus sprints.

Una historia de usuario excelente cumple con los 6 criterios, y una buena historia de usuario puede que solo cumpla con la mayoría de ellos. A veces buenas historias de usuario no son independientes y requieren de más de un equipo.

Y es justamente en este punto donde, a través de este post quiero, arrojar algo de claridad sobre como tratar estas historias que Jann Thomas denomina cross-team-stories o historias que cruzan equipos.

Una historia que cruza equipos consta en realidad de dos partes: la parte de la historia de usuario que permanece con el equipo que la identificó, y la historia de usuario que va al equipo que la completa. La propiedad/responsabilidad de ambas historias recae en el equipo que la ha identificado. La propuesta del flujo de la historia entre equipos sería la siguiente:
  1. Durante una planificación del sprint, o una PI Planning, un equipo identifica una historia de usuario con una parte que debe realizar un equipo diferente.
  2. El equipo que la identifica la divide en dos, una historia de usuario para cada equipo.
  3. Representantes apoyados por, o directamente los Propietarios del Producto de los respectivos equipos, negocian la prioridad y el alcance de la historia que ha de construir el otro equipo.
  4. El equipo que construye la parte planifica la historia en su sprint. El equipo que la ha identificado planifica su historia en el sprint adecuado teniendo en cuenta la planificación del otro equipo, sea el siguiente sprint o uno posterior.
  5. Una vez finalizada la historia por parte del segundo equipo, el equipo que la ha identificado la integra y valida junto a la suya.
Lo que realmente estamos haciendo es una gestión de resolución de dependencias, que mientras no finalice deberemos de visitar en las reuniones de Scrum de Scrums.

martes, 6 de abril de 2021

¿Se puede escalar Agilidad añadiendo capas?

Versión de SAFe 6.0 como broma de 1 de abril
El 1 de abril me llegó por whatsapp una pretendida versión 6.0 del marco de SAFe©... En Estados Unidos, los países nórdicos de Europa y otros países más, el 1 de abril es el "April Fools' Day", que se puede traducir como día de las bromas de abril o día de los inocentes de abril.

Lo interesante de la imagen es lo que evoca, que el escalado se puede producir añadiendo nuevas capas, a semejanza de la forma tradicional de hacer crecer a las compañías.

En realidad la propuesta de SAFe es simplificar y desescalar a lo que funciona con personas, y por tanto alinearse con la naturaleza humana.

Como en Scrum, el bloque básico es el equipo, que sabemos que llega a niveles máximos de autoorganización y autogestión estando limitado de 5 a 11 miembros, incluidos Scrum Master y Propietario del Producto.

El siguiente nivel de escalado, el equipo de equipos, lo denomina tren o ART (Agile Release Train), y está limitado a ±125 individuos. Según el antropólogo Robin Dunbar la cantidad de individuos que se pueden relacionar plenamente en un sistema determinado y proporcionar un sentimiento tribal con un objetivo común es aproximadamente de 150. Este número está relacionado con el tamaño de la neocorteza cerebral y su capacidad de proceso, y es el que permite y limita la autoorganización y la mente colectiva al tren o ART.

Por encima de ese número los colectivos no son autoorganizados, son creaciones artificiales del ser humano y requieren reglas y coordinación. Ejemplos son la religión, la nacionalidad y por supuesto los trenes de trenes o Solution Trains de SAFe, que pueden ser necesarios cuando varios trenes trabajan en un mismo producto. Toda capa por encima del tren es un colectivo artificial.

Si pertenezco a un tren, donde tengo noción de quienes están a bordo y soy consciente de un objetivo común, estaré dispuesto y comprometido a colaborar, a ayudar y a pedir ayuda. En un colectivo artificial si alguien me pide ayuda, colaboraré o ayudaré en función de mi buena voluntad, quizá entienda que puede haber un objetivo sea común, pero no tendré ese sentimiento tribal de pertenencia. Por ejemplo si alguien me pide ayuda en Londres, no por ser de mi nacionalidad voy a ayudarlo.

En resumen, SAFe desescala agrupando a los individuos en trenes o ARTs, el bloque básico de escalado. La siguiente capa es una capa artificial que es deseable evitar. La idea es organizar trenes independientes alrededor de cadenas de valor, y solo en casos excepcionales formar un tren de trenes o Solution Train. Al organizar trenes alrededor de cadenas de valor no es necesario escalar más allá, ya que si cada tren es independiente diseñará, construirá, testeará y desplegará cosas de principio a fin por si solo.

jueves, 25 de marzo de 2021

¿Qué tipo de retrospectiva hacer a lo largo de un curso?

El ROTI del primer día de nuestro curso
Recientemente di un curso compartido con Michele Lanzinger en el que me enseñó una técnica para obtener feedback rápido día a día a lo largo de un curso, técnica que quiero compartir en este post.

Se denomina ROTI y responde a las siglas Return Of Time Investment (Retorno de la inversión del tiempo). Con esta técnica pretendemos obtener de una forma muy rápida, y al final de cada día, cual es el sentimiento del tiempo invertido de cada asistente.

Al final del día, justo antes de abandonar la sala, sea en modo presencial o virtual, los asistentes mueven 5 puntitos o gomets de un pool a un tablero con tabla con 4 dimensiones en horizontal:
  • Entorno: herramientas de videoconferencia / sala de formación, herramientas colaborativas como tableros físicos o virtuales, etc.
  • Curso: ritmo, contenido, etc.
  • Entrenadores: nivel de conocimientos y facilitación del/os profesor/es
  • Material: material didáctico, manuales, ejercicios, materiales adicionales, etc.
para puntuar cada una de ellas del 1 al 5:
  1. Una pérdida de tiempo
  2. Me ha aportado algo
  3. Ha sido correcto
  4. Buen aporte
  5. Excelente aporte
En base al resultado podemos iniciar al siguiente día una toma de feedback en las dimensiones con baja puntuación, ya que quién haya dejado una puntuación baja puede aportar mucho a la mejora continua del curso.
Tablero ROTI preparado en Miro listo para iniciar el curso

martes, 23 de marzo de 2021

¿Kanban no obliga a pensar?

Valor o Flujo - cortesía de Pixabay
Una de mis mayores sorpresas ocurrieron cuando comprendí que los objetivos de Scrum y Kanban no son el mismo: ambos ponen el foco en la entrega, pero desde perspectivas diferentes.
  • Scrum pretende maximizar la entrega de la valor a través de cada sprint, y entiende que para ello la pila de producto debe de ajustarse de forma continua incorporando cambios, cambios que siempre representan un incremento de valor. Los cambios que se introducen una vez arrancado el sprint también son bienvenidos, siempre que estén alineados con el objetivo del sprint y el equipo se sienta cómodo con ello. Por otro lado el Propietario del Producto tiene la autoridad para parar un sprint si considera que lo que se está construyendo ya no tiene valor de negocio.
  • Kanban pretende maximizar el throughput (flujo) minimizando el tiempo de entrega (lead time) y aplicando la mejora continua. Una vez el equipo se comprometa con un elemento de trabajo, y este por tanto pase el punto de compromiso, el objetivo es avanzar ese elemento, y los demás existentes en el sistema, de la forma más fluida hacia el punto de entrega.
En definitiva Kanban pone el foco en flujo, en mirar hacia adentro, hacia el proceso; y Scrum en el valor, en mirar hacia afuera, hacia nuestro cliente, y por supuesto también hacia adentro.

Es muchísimo más duro mirar hacía fuera, ya que todas las variables no las maneja el propio equipo, o la compañía, el guiado por valor de negocio requiere compromiso con las necesidades del cliente, una fuerte colaboración con este y mucha adaptación. Recordemos que Scrum no soluciona los problemas e impedimentos sistémicos de nadie, ayuda a que los problemas sean dolorosamente transparentes para que las personas puedan encontrar soluciones creativas. Además Scrum obliga a aprender a finalizar al 100% los incrementos para cada revisión de sprint, lo que de nuevo obliga a aprender a trabajar con ese ritmo, y en definitiva a pensar y a reflexionar.

La aproximación de Kanban es mirar hacia dentro, hacia el proceso y practicar el cambio evolutivo:
  • Comienza con lo que haces ahora.
  • Comprende los procesos actuales y cómo se están usando
  • Respeta los roles, responsabilidades y puestos existentes
  • Acuerda buscar la mejora a través del cambio evolutivo
Por supuesto eso obliga a pensar y a reflexionar, pero de una manera mucho más ligera. En mi experiencia observo que las compañías con las que he trabajado suelen estancarse entre el nivel de madurez 1 el y 2 del modelo de madurez de Kanban (KMM). Observo que la carencia de una función que fuerce el cambio no genera ese dolor y por tanto permite acomodarnos y por ende menguar la necesidad de pensar.

Podemos, y quizá debamos, incluir al cliente en nuestro proceso y guiarnos por valor, pero dado que no es el objetivo primario seguimos mirando hacia el proceso. Lo veo una y otra vez cuando los equipos que usan Kanban son incapaces de priorizar su trabajo, son muy eficientes pero desconocen si lo que están haciendo es importante o no.

Quiero resaltar que Kanban tiene el mismo impulso de creación de pensamiento que Scrum, pero al no doler explícitamente ocurre que en organizaciones poco maduras, como son la mayoría a las he acompañado, no se fomenta el pensar.

sábado, 6 de marzo de 2021

¿Cómo obtener una primera impresión de la madurez ágil de un equipo/compañía?

DoD - cortesía de Pixabay
Somos coach ágil en una nueva compañía ágil, o consultor al que le encomendaron la tarea de proponer mejoras para evolucionar la Agilidad de la compañía, y no tenemos oportunidad de realizar Gemba Walks e impregnarnos de la realidad de los equipos, y aún así queremos tener una primera impresión de la realidad actual. ¿Qué podemos hacer?

Una forma que arroja mucha luz sobre la realidad de la compañía es echar un vistazo a los checklists de definiciones de hecho (DoD), tanto a nivel de equipos, como de tribu o tren (ART) y de entrega, a como se consideran historias de usuario y funcionalidades (epics) finalizadas.

De la DoD podemos leer directamente la cultura sobre la calidad que tiene la compañía, así como el nivel de colaboración dentro de y entre los equipos. Con cada nuevo criterio agregado a la DoD la compañía aumenta su nivel de madurez. Como nos cuenta Pablo Ioro en su articulo "The evolution of Definition of Done (DoD) from zero to DevOps", la evolución de DoD alcanza su madurez con DevOps, cuyo objetivo principal es reducir la fricción en la Continuous Delivery Pipeline.

Podemos basarnos en el modelo de Pablo para tener una primera idea de madurez de la compañía:

Nivel 1. Sin DoD/regresivo

Cada desarrollador determina que la tarea o historia de usuario está terminada cuando cree que está terminada en base a su experiencia. Con suerte, el código se sube a un repositorio de código fuente.

DoD Maturity Levels de Pablo Iorio
Nivel 2. Repetible pero no todos son tratados por igual

Las expectativas están documentadas o parcialmente documentadas, por lo que a la mayoría de las historias de usuario se les aplica DoD. Sin embargo en una misma aplicación no se aplica por igual debido a diferentes circunstancias como código heredado, falta de tiempo para hacerlo correctamente, etc.

Nivel 3. Definido y consistente

Las expectativas están documentadas y bien definidas, por lo tanto a todas las historias de usuario se les aplica el mismo DoD.

Nivel 4. Capaz y medible

Se recogen métricas de la pipeline, se hacen visibles y fácilmente accesibles para todos y se actúa en consecuencia. La arquitectura es tratada como código y se despliega con la Continuos Delivery Pipeline. Los despliegues complejos están orquestados y el rollback está disponible.

Nivel 5. Eficiente y optimizador

Máximo nivel de madurez. Se han alcanzado todos los niveles anteriores y se mejoran los procesos, prácticas y herramientas de forma activa y continua.

En definitiva la capacidad de terminar cosas antes de empezar nuevas, a la que tanto cuesta llevar a las compañías, es la que nos dice mucho de la madurez de la misma.

jueves, 4 de marzo de 2021

¿Qué es el modelo de madurez Kanban (KMM)?

Los 7 niveles de evolución en madurez de las organizaciones
de "Mejora de procesos, Kanban y KMM" de BerriProcess
El modelo de madurez Kanban, Kanban Maturity Model (KMM), es el modelo Kanban que vincula las prácticas de gestión de trabajo, la cultura y los resultados de negocio de una compañía. KMM proporciona una guía pragmática, accionable y basada en evidencia que muestra cómo lograr una verdadera Agilidad organizacional.

En la página web de KMM podemos leer:

"El modelo de madurez Kanban codifica más de 10 años de experiencia en la implementación de Kanban en diversas industrias, desde empresas pequeñas a compañías extremadamente grandes. Desempeña un papel importante en la creación de unidad, alineamiento, sentido de propósito y buen gobierno. Úselo para obtener una mejor sensación de logro, proporcionar mejores productos y servicios, deleitar a sus clientes y obtener resultados comerciales superiores".

El modelo proporciona a los coaches ágiles y agentes/gerentes de transformación un playbook probado, así como una hoja de ruta de transformación basada en el cambio evolutivo. La segunda edición del modelo de madurez Kanban expone 150 prácticas en 7 niveles de madurez organizacional.

El propósito del modelo de madurez Kanban es apoyar el desarrollo de las siguientes capacidades organizativas:
  • Reducción de la sobrecarga
  • Cohesión de la fuerza laboral y satisfacción de los empleados
  • Cumplimiento con las expectativas del cliente
  • Satisfacción de los clientes
  • Identidad y propósito organizacionales
  • Resilencia a los reveses y las turbulencias del mercado
  • Rendimiento económico previsible y sostenible, y solidez financiera
  • Agilidad organizacional
  • Congruencia en la toma de decisiones top-down
  • Supervivencia a largo plazo
  • Cambio significativo e institucionalizado anclado en la cultura de la compañía
Mapa de prácticas KMM - descargable en la página de Kanban Maturity Model

jueves, 25 de febrero de 2021

¿Qué beneficios aporta la cadencia?

En Agilidad la cadencia representa el ritmo o repetición de determinados eventos, eventos que se repiten con regularidad por unidad de tiempo, y cada uno de ellos genera un incremento finalizado del producto.
En Scrum la cadencia está representada por los sprints
Podríamos decir que en cadencia trabajamos a cachitos, estos representan funcionalidades completas construidas dentro de periodos del mismo tamaño y que queremos finalizar al 100%. Digo "queremos" porque encontrar ese ritmo en el que finalizamos cosas al 100% requiere un aprendizaje por parte de equipos y compañía.

Cada equipo ha de aprender a estimar el tamaño de lo que le cabe y encontrar su capacidad media o velocidad, para después planificar en base a esa capacidad y jamás superarla; incluso deberán de planificar por debajo de la misma ya que entregar con cadencia requiere capacidad de reserva para imprevistos y accidentes. 

Por otro lado la compañía ha de aprender qué medios y recursos ha de poner a disposición de los equipos, así como demoler los impedimentos sistémicos que bloqueen o retrasen a estos.

Infografía The Sprint, cortesía de AgileGenesis
Se trata de un ritmo en el que se empiecen cosas y se acaben dentro de cada periodo. El periodo que representa los intervalos de la cadencia a nivel de equipo lo conocemos como sprint, que habitualmente suele ser entre 1 semana y un mes.

El aprendizaje más difícil para las personas es aprender a terminar cosas, y la cadencia va a fomentar ese aprendizaje. Quizá conozcáis el mantra de Kanban:

Stop starting and start finishing - Termina de empezar y empieza a terminar

Veamos los beneficios de la cadencia:
  • Permite focalizar a los equipos en las cosas de valor, ya que entre sprints podemos inspeccionar (tomar feedback del usuario/cliente) y adaptar la pila de producto a la nueva información.
  • Convierte eventos impredecibles en predecibles, sabemos de antemano, hasta a largo plazo, la agenda de eventos, lo que permite reservar agendas y reducir costes. 
  • Hace que los tiempos de espera para nuevas funcionalidades sean predecibles.
  • Apoya la planificación regular fomentando la colaboración en el equipo.
  • Limita el tamaño de los lotes de trabajo a lo que cabe en un sprint, con lo que aceleramos la entrega de valor y mantenemos al equipo focalizado en los elementos de la pila de sprint.
  • Controla la inyección de funcionalidades nuevas; dado que el tamaño del sprint es limitado  asegura que solo entra lo prioritario.
En definitiva la cadencia hace al equipo previsible. Si le preguntamos a un manager ejecutivo o a un cliente "puede tomar la pastilla roja para la productividad o la azul para la previsibilidad. ¿Cuál tomaría?", la respuesta siempre es "la azul, previsibilidad".

Si la pregunta tradicional es "¿a que fecha estará esto o esto otro?", lo que nos lleva a tirarnos a la piscina en base a estimaciones de bola de cristal y probablemente a una entrega mediocre, la pregunta con cadencia es ¿qué cabe en el siguiente sprint? para una vez aprendida la capacidad del equipo, lo que cabe en un sprint, ser previsibles y realizar buenas entregas.

La cadencia también es de importancia vital cuando escalamos, cuando varios equipos han de colaborar:
Equipos trabajando con la misma cadencia y de forma sincronizada