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.

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.