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

domingo, 21 de febrero de 2021

¿Cuál es el valor de las certificaciones ágiles?

¿Cúal es el valor de mi certificación? - cortesía de Pixabay
Actualmente hay una moda en LinkedIn de publicar certificaciones recién obtenidas, yo no lo hago, pero si vais a la página del blog "Sobre mi" parezco un General Ágil con todas las certificaciones que he obtenido. El caso es que este tema genera muchos debate en las redes sociales sobre si las certificaciones valen para algo.

Desde la perspectiva de la búsqueda de empleo, y especialmente en España donde impera la titulitis, las certificaciones aumentan las posibilidades para pasar una entrevista con Recursos Humanos, generan confianza y permiten diferenciarnos de otros en el proceso de selección laboral. Por otro lado poder aportar una certificación de renombre, por ejemplo de la Scrum Alliance o Scrum Manager, o una certificación avanzada como Lean Portfolio Management, permite negociar un nivel del sueldo más alto. Pero, ¿es ese el valor de las certificaciones?

Hoy en día la importancia de introducir métodos ágiles en las compañías es evidente, estamos en un punto de inflexión donde ocurren muchas transformaciones ágiles y la demanda de profesionales competentes supera la oferta. Claro que los años de experiencia en roles y desarrollos ágiles son los que crean el entendimiento de los métodos ágiles y por tanto la competencia y habilidades necesarias, pero hay que incorporar nuevos profesionales y al fin y al cabo todos hemos empezado desde cero.

Una certificación no asegura la competencia de la persona certificada, una certificación no nos convierte en maestros de Scrum o Kanban, pero si garantiza nuestro nivel de conocimiento y nos dota del lenguaje necesario para ayudar a introducir la Agilidad en las compañías.

El valor de las certificaciones está en entender que son un punto de partida, no un destino

Las certificaciones ágiles más potentes son aquellas que llevan un curso asociado, aquellas que para poder sacártelas has de pasar forzosamente por un curso. Las entidades certificadores que requieren un curso suelen filtrar, dotarse y formar trainers excelentes cuyas enseñanzas son transformacionales e impregnan a los alumnos de una verdadera mentalidad ágil.

A partir de aquí los grandes profesionales se forman en base al aprendizaje (microaprendizaje continuo) y a la mejora continua, y de hecho a lo largo de toda la vida profesional. Su desarrollo vendrá determinado por la actitud de búsqueda continua para seguir formándose y validar sus conocimientos, así como de la disposición de su compañía a apoyar la formación y aprendizaje continuo de sus empleados.

viernes, 12 de febrero de 2021

¿Qué ceremonias podrían servir dentro del chapter?

Chapter Meeting :-D
En mi post sobre el Chapter Lead, en los comentarios, David lanzó esta pregunta que me pareció muy interesante y a la que quiero dedicar este post.

Recordemos que un chapter es un foro para compartir conocimiento y fomentar la innovación. Los mejores resultados siempre se logran en colaboración, el todo siempre es más que la suma de las partes, así que, permitiendo que los expertos de una disciplina incorporen diferentes opiniones y perspectivas en las decisiones del chapter, hace que los resultados sean excepcionales y estén alineado con la tribu y la empresa.

Quiero exponer en este post los tres tipos de eventos/reuniones que utilizamos y nos funcionaron muy bien. Los dos primeros fomentan el pensamiento sistémico (System Thinking) para que el chapter siempre piense y actúe de forma holística, y el tercero el desarrollo de las personas miembros del chapter.

Chapter Meeting (Chapter-Sync): reunión a nivel de la tribu en la que se sincroniza y alinea el chapter; donde los miembros de diferentes squads tratan desde su expertise cómo se deben hacer las cosas. Se comparten problemas, dudas, prácticas, conocimientos, definición de estándares de trabajo, herramientas, se busca y da ayuda, se identifican puntos de mejora y se establecen temas en los que deben mejorar o formarse.

Los temas se recogen en el chapter backlog que se gestiona de la misma manera que una típica pila de producto. Estos temas se priorizan por votación de los miembros del chapter, luego son analizados y presentados en próximos chapter meetings o, dependiendo de tamaño e importancia, en reuniones específicas. El Chapter Lead es responsable de la transparencia del backlog y de la coordinación de temas que tengan que ver con otros chapters o squads.

La cadencia que aplicamos al evento es con cada sprint (cada 2 semanas). Hacerlo con cadencia semanal o mensual también está bien, aunque como mínimo debe de ser mensual. La duración es de 1h a 1h30min y deben de asistir todos los miembros del chapter, incluido Chapter Lead. La agenda del evento es variable, puntos que son usuales:
Comunidad de prácticas - cortesía de Pixabay
Comunidad de prácticas: otro mecanismo para fomentar chapters excelentes es proporcionar CoPs a modo de gremio transversal, o guild, a todas las tribus dentro del ámbito del chapter. Los gremios tienen un carácter más formal e institucional que otras CoPs, por tanto tienen un papel más relevante que los Chapter Leads deben impulsar.

El evento lo moderan voluntarios que facilitan las sesiones según las reglas que el gremio haya establecido:
  • Intercambio de información sobre últimas novedades y desarrollos
  • Compartición de tendencias, experiencias, mejores prácticas,
  • Realización de formaciones internas, hackatons, entrenamientos, experimentos
  • ...
Los miembros del gremio se reúnen preferiblemente de forma regular, una buena cadencia es entre mensual y trimestral. Es de asistencia libre, pueden unirse y contribuir libremente todos los interesados, sean o no del chapter.
Reunión uno a uno - cortesía de Pixabay
Reuniones uno a uno en base trimestral el Chapter Lead, que lidera el desarrollo y madurez de los profesionales del chapter, mantiene una reunión con cada miembro del chapter.

En esta reunión se tratan temas sobre como evaluar el desempeño individual, dar feedback, tratar iniciativas para desarrollar las capacidades adecuadas según las necesidades de la tribu, establecer los objetivos de desarrollo profesional contando con la persona y actividades de coaching y mentorización.

Aunque el Chapter Lead no sea un jefe sino un líder al servicio, también trata en esta reunión temas laborales: vacaciones, aumentos de salario, permisos etc.

martes, 9 de febrero de 2021

¿Cómo funciona una retrospectiva en Kanban?

Equipo trabajando acciones de mejora - cortesía de Pixabay
La Team Retrospective, o retrospectiva de equipo, es uno de los eventos de revisión del ciclo de eventos de Kanban que se introduce en el nivel 1 del modelo de madurez Kanban (KMM), y es una de esas prácticas ágiles que nos lleva a mejorar colaborativamente y evolucionar de forma continua, y que no se puede omitir si queremos la mejora continua y mantener el rendimiento en el mejor nivel.

El propósito del evento es que el equipo reflexione sobre cómo está gestionando su trabajo y cómo puede mejorar.

El evento se establece con periodicidad semanal o cada 2 semanas, con una duración máxima de 1 hora, que se realiza frente al tablero Kanban y asisten los miembros de equipo y opcionalmente un facilitador.

Un guion ejemplo de la revisión seria:
  • Repasar resultados de acciones de mejora recientes anteriores (las que se hayan puesto en marcha).
  • Repasar los elementos de trabajo completados.
  • Recopilar observaciones y ocurrencias respondiéndo a preguntas como:
    • ¿Qué nos falta?
    • ¿Qué deberiamos de hacer además?
    • ¿Qué ideas vale la pena explorar?
    • ¿Tenemos problemas relacionados con las políticas actuales?
    • ¿Algún otro probelema o impedimento?
  • Categorizar los elementos recopilados y definir acciones de mejora.



En el nivel 2 del modelo de madurez Kanban (KMM) la Team Restrospective se sustituye por la Flow Review, o revisión del flujo, cuyo propósito es desarrollar una comprensión cuantitativa inicial del servicio prestado por los equipos involucrados en el servicio, para después facilitar la planificación del trabajo y así mejorar la previsibilidad..

El evento se establece con periodicidad mensual o cada 2 semanas, con una duración máxima de 30 minutos y asisten los miembros de los equipos de prestación de servicios, o parte del mismo, SDM (Service Delivery manager) y opcionalmente Team Leaders y facilitador.

Tiene una parte cuantitativa en la que el equipo desarrolla una comprensión inicial del servicio prestado, que va seguida de una segunda parte que es cualitativa. Los equipos tratan cualquier problema con el que se hayan enfrentado con los elementos de trabajo y comparten cualquier conocimiento valioso que haya adquirido mientras los procesa.

Un guion ejemplo para el facilitador de la revisión seria:
  • Repasar resultados de acciones de mejora recientes anteriores (las que se hayan puesto en marcha).
  • Inspeccionar al detalle el tablero Kanban de derecha a izquierda (demanda por tipo de servicio, bloqueos, retrasos, edad de los elementos, riesgos, ...).
  • Comparar el desempeño actual con los objetivos marcados (SLA's) usando métricas centradas en el cliente, calidad, Lead Time/Cycle Time, tasa de llegada, throughput por clases de servicio (CFD, run charts, control charts, ...).
  • Sobre el trabajo terminado compartir problemas que hayan acecido y difundir nuevos conocimientos aprendidos.
  • Analizar el progreso de los elementos en los que el equipo está trabajando actualmente.
  • Identificar el acciones de mejora para el flujo de trabajo a través de sus causa raíz aplicando técnicas Lean como 5 whys y el diagrama de Ishikawa, y finamente planificar como llevarlas a cabo.



En el nivel 3 del modelo de madurez Kanban (KMM) la Flow Review se sustituye por la Service Delivery Review, o revisión de entrega del servicio, cuyo propósito es examinar y mejorar la eficacia del servicio seleccionado tomando la perspectiva del cliente externo del servicio.

El evento se establece con periodicidad cada 2 semanas, con una duración máxima de 30 minutos y asisten representantes de los equipo de prestación de servicios, SDM (Service Delivery Manager), SRM (Service Request Manager) y opcionalmente clientes, interesados y facilitador.

Con un guion similar a la Flow Review trata de inspeccionar el flujo de trabajo, reflejar el estado actual y el comportamiento pasado de las decisiones del equipo con respecto a las expectativas del cliente, para discutir y decidir sobre mejoras que el equipo pueda emprender para abordar las variaciones o el mantenimiento de la idoneidad del sistema Kanban con el que operan para servir a ese mismo cliente.

En caso de nivel de madurez 4 del sistema Kanban de los equipos se toman inputs de la Risk Review y de la Operational Review; y de vuelta se informan las acciones y hallazgos a la Operations Review.

sábado, 6 de febrero de 2021

¿Cómo reabastecemos nuestro tablero Kanban?

Team Replenishment Meeting remota - gracias Javi, Sara y María
El evento en el que los equipos de servicio seleccionan nuevas peticiones o elementos de trabajo para el siguiente periodo y reabastecen su tablero Kanban se denomina Replenishment/Commitment Meeting.

Es una de las reuniones del ciclo de eventos de Kanban que en el nivel 1 del modelo de madurez Kanban (KMM), a nivel de equipo, se denomina Team Replenishment Meeting, o reunión de reposición del equipo.

En esta reunión, y con base a un sistema de arrastre en función de la disponibilidad de las opciones y la capacidad del sistema Kanban, el equipo determina con qué elementos de trabajo se compromete y los lleva a la columna "Ready" del tablero.

La duración máxima de la reunión son 30 minutos y la cadencia habitual del evento es semanal, aunque dependiendo de la tasa de llegada de peticiones esta puede producirse bajo demanda. Las organizaciones menos maduras suelen tener problemas con el reabastecimiento bajo demanda y prefieren la cadencia de eventos predecibles. El reabastecimiento bajo demanda es posible cuando el esfuerzo de coordinación es bajo y los Business Owners tienen alta disponibilidad y cercanía con el equipo.

Asisten los miembros del equipo, o parte del mismo, y los Business Owners que estén involucrados en el flujo de trabajo. Dado que los elementos de trabajo se comprometen es importante que estos estén claramente definidos, tanto la funcionalidad, los aspectos técnicos y posibles dependencias con otros equipos; se produce:
  • Toma de decisión colaborativa sobre qué elementos de trabajo llevar a cabo y comprometerse a entregarlos con éxito al cliente final.
  • Identificación y análisis de dependencias y/o riesgos que el equipo debe conocer antes comenzar a trabajar en los nuevos elementos de trabajo.
La naturaleza del trabajo de los equipos que operan bajo Kanban, como por ejemplo los equipos de mantenimiento y los de sistemas, suele ser más reactiva que la de los equipos que usan Scrum. También para éstos es beneficioso expresar una meta para el siguiente periodo, esta les permite entender el propósito y estar seguros de que esta es alcanzable, y así poder comprometerse con los elementos de trabajo y los acuerdos de nivel de servicio (tiempos de respuesta).

Para asegurar que todo el equipo cree que la meta sea alcanzable se puede hacer el siguiente chequeo:
  • ¿Creéis que se puede alcanzar la meta? Puntuad levantando los dedos de una mano del 1 al 5 (1=no lo creo, 2=probablemente no, 3=tal vez no, 4=probablemente sí, 5=definitivamente)
  • Si la puntuación mayoritaria está en 1 o 2 discutir qué se precisa para mejorar:
    • Eliminar un impedimento
    • Aliviar un cuello de botella
    • Reducir el alcance
    • Ajustar la meta
El evento puede llevar a cambios de comportamiento como:



En el nivel 2 del modelo de madurez Kanban (KMM) la Team Replenishment Meeting se sustituye por la Workflow Replenishment Meeting, o reunión de reposición del flujo de trabajo, donde colaboran los diversos equipos involucrados en el flujo de trabajo del servicio. Su propósito es que los equipos relacionados con un servicio seleccionen las peticiones a llevar a la columna "Ready".

De forma similar a la reunión de reabastecimiento de equipo, los equipos del servicio determinan en base a un sistema de arrastre con qué elementos de trabajo se comprometen y los lleva a la columna "Ready" del tablero. Con ello se proporciona claridad al flujo de trabajo y se crea un entendimiento compartido sobre en qué se está trabajando y cuándo.

La duración máxima de la reunión son 30 minutos y la cadencia habitual del evento es semanal, asisten representantes de los equipos y los Business Owners que estén involucrados en el flujo de trabajo.



En el nivel 3 del modelo de madurez Kanban (KMM) la Workflow Replenishment Meeting se sustituye por la Replenishment Meeting, o simplemente reunión de reposición, cuyo propósito es decidir junto con el cliente y los interesados de negocio las solicitudes de trabajo para el próximo período.

Se tratan las solicitudes disponibles que cumplen los criterios de selección y se llevan a "Ready", lo que representa dos compromisos:
  • Del cliente con respecto a no cambiar las solicitudes seleccionadas
  • Del equipo para entregar dentro de las expectativas
La duración máxima de la reunión es de 1 hora y la cadencia habitual del evento es entre semanal y mensual. Asisten representantes de los equipos, SDM (Service Delivery Manager), SRM (Service Request Manager) y los Business Owners que estén involucrados en el flujo de trabajo.

Pueden llevarse observaciones de la reunión a la Service Delivery Review para un análisis adicional del sistema Kanban.

martes, 2 de febrero de 2021

¿Cómo asegurarnos que nuestro MPV realmente lo es?

Imagen del artículo de Sugoi Labs "Framework to build an MVP"
En algún momento me crucé con la imagen de la derecha en la que se muestra qué es y qué no es un MPV (Mínimo Producto Viable).

¡Me chocó! Estaba convencido de que el MPV del ejemplo es el patinete. Siempre pensé que si nuestro cliente tiene una necesidad de movilidad no sabemos de entrada si la solución ideal es un coche, en este caso un 2CV, como nos sugiere esta imagen.

Así que quise averiguar qué es lo que nos quería enseñar y busqué el artículo con la imagen. Se trata de "Framework to build an MVP" en el que Amar Saurabh comparte un marco para productos digitales que podemos usar para cualquier idea de producto que podamos tener.

En su artículo nos cuenta que primero hemos de decidir las características mínimas que debe tener nuestro producto en su MPV, para luego iterar rápidamente sobre el producto en función del feedback recibido por nuestros clientes. Debemos crear un MVP e iterar cuando la idea sea relativamente nueva y esta no haya sido validada por usuarios o clientes reales. Pero en los casos en los que ya tenemos un número suficiente de interacciones de usuario con el producto que demuestren que los usuarios finales lo desean, no necesitamos crear un MVP.

¿Qué hacer entonces para saber cual es MPV? Adrian Solca preparó un diagrama que ha compartido recientemente en LinkedIn que ayuda a identificar si lo que necesitamos es un Prototipo, un Piloto o un MPV. El diagrama de paso también nos ayuda a entender si nuestro MPV lo es.

He aplicado el diagrama para averiguar si el MPV es el que dice que es.
Diagrama de flujo de Adrián Solca para saber si un MPV lo es realmente
El razonamiento que emplee para aplicar el diagrama de Adrián es el siguiente:
  • ¿Sabes QUÉ NECESITAN los usuarios para los que estás construyendo una solución?
    • Si: Necesitan una solución de movilidad.
  • ¿Sabes CÓMO necesitan que sea la solución para que les sirva?
    • Si: La solución ha de poder transportar a personas y circular por carretera.
  • ¿Tienes identificado un mercado meta claro que está interesado en tu solución?
    • Si: Familias.
  • ¿Necesitas empezar a recibir feedback "real" para comenzar a crecer la idea?
    • Si: Tengo un 2CV mínimo y no sé si cubre todas la necesidades básicas de los usuarios.
Eric Ries, quien introdujo el concepto, define MPV como "la versión de un nuevo producto que permite a un equipo recopilar la máxima cantidad de aprendizaje validado sobre los clientes con el menor esfuerzo".

Si consideramos un MPV aquél que solo tiene las características básicas suficientes para lanzar el producto, y no más, parece ser que si aplicamos el diagrama a la tercera opción de la imagen descubrimos que efectivamente se trata de uno.

Este caso trata del proceso con MPV basado en la construcción de un producto, un 2 CV es nuestro caso:
  • MPV: una cabina sobre ruedas para personas.
  • Iteración 2: el usuario nos dice que además necesita transportar cosas, con lo que le añadimos una cajonera atrás.
  • Iteración 3: el usuario nos dice que debería de ir cubierto, con lo que creamos una carrocería que cubra todo el coche.
  • Iteración 4: finalmente perfilamos detalles y embellecimientos para hacer el coche atractivo.
Proceso de MPV basado en la construcción de un producto
Según la Wikipedia los propósitos de un MPV son:
  • Ser capaz de probar una hipótesis de producto con recursos mínimos.
  • Acelerar el aprendizaje.
  • Reducir el desperdicio de horas de ingeniería.
  • Presentar el producto a los "primeros seguidores" tan pronto como sea posible.
  • Como base para otros productos.
  • Para demostrar las habilidades de un constructor en la elaboración del producto requerido.
Eric Ries también nos dice "Enamórate del problema, no de la solución".

Todo eso arroja una luz algo diferente sobre la cuestión, en nuestro ejemplo se trata de encontrar la mejor solución a la movilidad, y esa no tiene que ser un coche, y además puede ocurrir a través de varios productos.

La respuesta a la última pregunta del diagrama podría ser:
  • ¿Necesitas empezar a recibir feedback "real" para comenzar a crecer la idea?
    • Si: Tengo un patinete que da solución a la movilidad, es una solución de inversión mínima que, aunque no es utilizable por una familia, me permite obtener información sobre otras necesidades reales de los usuarios.
En este caso se trataría de proceso de MPV basado en las necesidades del usuario y en nuestra propuesta de valor:
  • MPV: un patinete que nos validará si la solución deseada es algo sobre ruedas.
  • Iteración 2: el usuario nos dice que además necesita poder sentarse, con lo que pivotamos la solución hacia una bicicleta.
  • Iteración 3: el usuario nos dice que quiere que sea autopropulsada, con lo que pivotamos hacia una motocicleta.
  • Iteración 4: el usuario nos dice que quiere más seguridad y protección, con lo que pivotamos hacia un coche 2 CV.
Proceso de MPV basado en la propuesta de valor
Pienso que ambos son MPVs, en el primer caso enfocado a un proceso de construcción de un producto cuya visión está definida, y en el segundo caso enfocado a descubrir un producto que responde a nuestra propuesta de valor; fijémonos que este segundo caso cada iteración resulta en un producto funcional terminado.

La madurez en Agilidad y la naturaleza del producto determinarán cual es proceso adecuado: una empresa startup sin duda se basará en el proceso de propuesta de valor, y una compañía con un producto grande probablemente se basará en el proceso de construcción.

jueves, 21 de enero de 2021

¿Si un equipo llega limpio a la iteración IP puede incorporar nuevo trabajo?

Imagen del tema Innovation and Planning Iteration cortesía de © Scaled Agile, Inc.
La pregunta del titulo del post la hizo recientemente un equipo cuyo avance hacia sus objetivos del PI era excelente. Básicamente estaban diciéndome que terminarían en las iteraciones previstas todas sus historias de usuario a tiempo y cubrirían todos los objetivos, tanto los comprometidos como los no comprometidos. Entonces, ¿porqué no incorporar nuevo trabajo en la iteración IP (Innovation and Planning)?

La respuesta está en System Thinking: la entrega de valor, y en definitiva la predictibilidad, está a nivel de tren (ART), no a nivel de equipo, por tanto esa situación de "todo terminado" debe de producirse en todo caso a nivel del tren. Así que mi recomendación final, no la inicial porque no estaba preparado para esta pregunta, fue que se informaran sobre la situación del resto de equipos, y quizá descubrieran que otro equipo podría necesitar su ayuda. Así que nos preparamos para tratar el tema en el siguiente Scrum de Scrums (SoS).

El entendimiento que el tren es la unidad, y que lo equipos son los que lo componen, es un concepto que tarda en calar. En un equipo que era cuello de botella por las dependencias de otros con ellos, usaron la expresión "corriendo detrás del tren", expresión que es muy ilustrativa y que muestra de nuevo la dificultad que entraña incorporar la perspectiva sistémica en las personas de los trenes.

Otra perspectiva que trae claridad es la teoría de flujo; donde lo que se conoce como slack time, tiempo sobrante, puede ser lo mejor que le puede pasar al flujo, ya que lo equilibra y lo hace más predecible. En caso de un PI este tiempo proporciona suficiente margen de capacidad para permitir la cadencia. En otras palabras, para que el tren esté optimizado a veces es necesario que alguna de sus partes esté suboptimizada. Si pretendemos llenar de trabajo al 100% cada hueco de tiempo sobrante aparecerán bloqueos y cuellos de botella que penalizarán fuertemente al flujo; incorporar nuevo trabajo puede hacer descarrilar el tren.

Lo que propone Lean es utilizar este tiempo sobrante como herramienta para aumentar la eficiencia de equipos y tren, y mejorar los procesos subyacentes. Ese es justamente una de las intenciones en la parte de innovación propuesta en la iteración IP. Por tanto la respuesta es "no", por mucha tentación de incluir más trabajo que pueda haber.

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

domingo, 17 de enero de 2021

¿Qué dinámica utilizar para definir acuerdos o principios que rijan el comportamiento de un equipo?

TRIZ
Para definir los principios de la Comunidad de Práctica de Liberating Structures en España preparamos una sesión basada en una estructura liberadora llamada TRIZ.

Esta estructura esta concebida para frenar actividades y comportamientos contraproducentes y abrir espacio a la innovación. La hackeamos (la modificamos) para producir nuestros principios y fue todo un éxito. Este hack, que quiero presentar en este post, permite definir principios y acuerdos en una situación de partida en la que un equipo o grupo no tiene historia previa y no ha colaborado apenas.

Meetup con la comunidad efectuando TRIZ, gracias a todos
Lo interesante de esta estructura liberadora es que parte de una situación que no queremos, aquella que es la peor situación posible a la que pudiéramos llegar, y eso resulta que nos resulta muy fácil de imaginar y representar.

El ser humano hace muchas asunciones y se engaña fácilmente a si mismo, con lo que buscar directamente aquello que quiere no siempre es fácil. Pero el ser humano es muy creativo describiendo lo que no quiere, así como para imaginar acciones que llevarían a esa situación. TRIZ define las acciones, en nuestro caso principios y acuerdos, como contramedida a las acciones no deseadas.

Visual recording de la sesión
¡Gracias Fco.Javier Pecci!
La preparación requiere 4 tableros:
  1. Peor resultado no deseado
  2. Todo lo que podemos hacer para lograr el resultado no deseado
  3. Elementos más relevantes del tablero anterior
  4. Acuerdos o acciones que nos lleven a evitar los elementos del tablero anterior
Y estos son los pasos y tiempos a ejecutar:
  1. Introducción al TRIZ hackeado e identificación de un resultado no deseado en un primer tablero. Los grupos pueden hacer una lluvia de ideas y escoger el resultado más indeseable (5 min).
  2. Cada grupo usa 1-2-4-All para hacer una primera lista de todo lo que puede hacer para asegurarse de lograr este resultado no deseado en el segundo tablero (10 min).
  3. Cada grupo usa 1-2-4-All para hacer una segunda lista en el tercer tablero con todo aquello de su primera lista que sea relevante. Una excelente opción es hacer una votación de hasta 3 elementos de la lista del segundo tablero y solo llevarnos los que se repitan (10 min).
  4. Cada grupo usa 1-2-4-All para determinar para cada elemento del tercer tablero qué acciones ayudarán a evitar esa situación no deseada y las recogerán en el cuarto tablero (10 min).
Finalmente los tableros 4 y 3 representan los principios o acuerdos, los que son y los que no respectivamente. Podéis encontrar aquí la información sobre TRIZ en inglés, y aquí TRIZ traducido.
Así quedó nuestra actividad, con un tablero inicial con los resultados y los 4 mencionados en el post
Quiero dar mis agradecimientos a Fede, Naty y Rogger por impulsar la comunidad y a Male y Gertru por compartir el diseño y la facilitación del evento conmigo :-)