Hamburg Flow Days

Tiempo aproximado: 4 min.

Escribo hoy desde Hamburgo (Alemania). Me he quedado un poco más para turistear después de asistir a los Hamburg Flow Days y confraternizar con una nueva Agile coach que espero que se una pronto a nuestro equipo en eDreams ODIGEO. Quizás debería etiquetar esta entrada como bitácora y así compensar que esta semana no he escrito nada. O:)

El evento en realidad se trataba de dos talleres más o menos experimentales facilitados por Patrick Steyaert y Mike Burrows (bien conocidos en la comunidad Kanban internacional) respectivamente.

Jueves, Patrick Steyaert

El jueves, Patrick nos acompañó por una experiencia basada en simulaciones que nos llevaba desde una gestión orientada a la eficiencia de los recursos hasta una gestión del flujo de trabajo, presentándonos además su metáfora de los sistemas de flujo (flow systems).

Las simulaciones que nos trajo Patrick son bastante más sencillas que getKanban y, en mi opinión, muy apropiadas para trabajar con personas cuyo trabajo está más orientado a la gestión de proyectos que realmente a tareas en el contexto de un equipo de desarrollo de software. Estoy totalmente de acuerdo con él en que, para cambiar la mentalidad de la gente, no sólo debemos acudir a argumentos racionales sino también emocionales, y que la vivencia que aportan las simulaciones permiten conectar con esta parte intuitiva de nuestro cerebro que habilitará el cambio de mentalidad. 

Al final del día llegamos a la parte que más me interesaba: cómo gestionar el flujo en lo que llamamos upstream (la parte de nuestro flujo de trabajo que sucede antes de que una tarea “entra en la cocina”, por ejemplo, mientras hacemos los refinamientos de las historias de usuario). Tras una intensa conversación, ya acabado el taller, en la que yo hacía la pregunta equivocada “¿Cómo puedo medir la eficiencia en el upstream?”, Patrick me ayudó a entender con qué tres técnicas podemos controlar el flujo, que al fin y al cabo era lo que realmente me interesaba.

  1. Establecer un limite de WIP compartido (CONWIP) entre upstream y downstream, es decir, para todo el sistema. Así, hasta que no hayamos desplegado una funcionalidad no aceptaremos una nueva funcionalidad para empezar su refinamiento. Con esto buscamos que las personas involucradas en ambos flujos tengan que colaborar. Esto se be muy bien con las simulaciones diseñadas por Patrick.
  2. Establecer un nivel mínimo de WIP en la cola que alimenta el downstream. De esta manera evitamos “que la cocina se quede sin pedidos”.
  3. Finalmente, para que la impedancia entre ambos flujos sea la menor posible, Patrick recomienda el uso de algún triaje (clasificación rápida) para el trabajo a hacer en el downstream. Es esencial que podamos descartar temprano toda aquella funcionalidad que realmente no vaya a ser valiosa.

Esta última técnica ya la estamos aplicando en los equipos a los que acompaño en eDreams ODIGEO. Lo llamamos Revisión y, en general, consiste en comprobar que la funcionalidad en cuestión encaja con la misión y los objetivos del equipo (usando Impact Mapping) y luego hacer un Perfil de la funcionalidad (lo que David Anderson y otros llaman Risk Profile) para que haya una idea compartida y se pueda priorizar adecuadamente.

Sin embargo, incluso esta Revisión puede ser una actividad más complicada que simplemente una conversación entre todo el equipo y podriamos estar hablando de tener que hacer una Inception o un User Story Map, por ejemplo.

No me quiero extender más, así que dejo aquí unas diapositivas de la LKCE16 en las que Patrick explica la mayoría de estos conceptos.

Viernes, Mike Burrows

Al día siguiente, Mike nos llevó por una serie de ejercicios que forman parte de su Agendashift, un framework para gestionar la estrategia de transformación de una organización. Debo confesar que la mayoría del taller anduve bastante desorientado, pero durante todo el día encontré bastantes conexiones con lo que ya estoy haciendo con mis equipos. Sin ir más lejos, el taller al que me refería la semana pasada encaja bastante con lo que Mike nos proponía al final del día: un story map cocreado en base a una serie de áreas de inspiración. En su caso, Mike propone:

  1. Refinar el trabajo existente
  2. Mejorar la experiencia del servicio 
  3. Gestionar el descubrimiento de conocimiento 
  4. Balancear capacidad y demanda 
  5. Abordar las fuentes de insatisfacción y otros motivadores de cambio
  6. Perseguir encajar en un propósito 

Áreas que, por cierto, él es capaz de mapear con las prácticas de Kanban. No sé, a mí me parecieron poco intuitivas y demasiado ambiguas. Quizás es la intención. En cualquier caso, me costó seguirle el hilo de esta dinámica. Sin embargo, un par de ejercicios me llamaron la atención. Uno está basado en Cynefin y ayuda a priorizar oportunidades de mejora. Si lo pongo en práctica, ya contaré qué tal. El otro fue el uso de un conjunto de preguntas abiertas (muy de coach) para ayudar en la indagación de los problemas y llegar así a identificar consecuencias o resultados (outcomes) de los cambios perseguidos. De esta manera ayudamos a alinear a todo el mundo y gestionar mejor las expectativas. Creo que a los ingenieros nos causa una cierta adicción pues se trata de un patrón que podemos ejercitar muy fácilmente y que no tiene graves consecuencias si no funciona pues su verdadero valor es el de desatascar las conversaciones en busca de esos outcomes.

Hamburgo

El sábado estuve “turisteando” por la ciudad. Sospecho que es una ciudad bonita cuando sale el sol. Mientras tanto, nubes y frío, mucho frío. 🙂

LA FOTO: En el evento coincidimos con Sabrina Hauptman que, si todo va como esperamos, se unirá pronto a nuestro equipo de Agile coaches, y con ella traerá megawatios-hora de energía positiva y unicornios.