¿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

¿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.

¿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.

¿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