One piece flow: De uno en uno por favor

Os voy a contar un secreto a voces para lograr que un equipo entregue más, más rápido y mejor. “One piece Flow”.

Trabajar sobre un objetivo a la vez. No os digo que sea fácil, pero sí que es mejor. Es uno de los patrones Lean más infravalorados y con mayor impacto en la productividad de un equipo.

Autoengañarnos pensando que cuanto antes empecemos una iniciativa, antes terminamos y que cuanto más iniciativas empecemos, más trabajo sacamos, es uno de los mayores males de un equipo de desarrollo de producto. Y no solo a nivel productivo.

Me atrevería a decir que “One Piece flow” junto con una correcta integración continua, son las dos prácticas que tienen un mayor impacto en un equipo de desarrollo.

Trabajar con un flujo de una iniciativa cada vez, es básicamente NO paralelizar iniciativas, pensar en un equipo como una unidad mínima de trabajo, y no pensar en “si somos 6, 3 a esto y 3 a lo otro”. Paralelizar es autoengañarnos creyendo que duplicamos o triplicamos de forma mágica la capacidad de trabajo de un equipo.

Subestimamos el mal que genera el cambio de contexto en un equipo

Hay estudios donde nos advierten que la perdida de productividad es de un 20% con dos iniciativas en marcha y de casi un 50% con tres proyectos a la vez.

Y no es solo es la pérdida de tiempo individual por cada cambio de tarea. Con respecto al equipo, tener trabajo sin terminar, implica indirectamente, varios de los 7 “wastes” de Lean Software Development.

“Trabajo no terminado” es el origen de todo el desperdicio

Ese código que no terminamos de integrar de la iniciativa 1 porque está a medias y se encuentra ahora perdido en algún entorno. Ese bug que no hemos descubierto antes, pero que aparecerá en cuanto esté en producción y cómo hemos empezado otra de las iniciativas, pues “ya lo subiremos todo junto después”.

Pero hay muchos más wastes, ¿Os suena tener que re-entender aquel código de hace 1 mes?. Era de la iniciativa A, pero no está terminada porque ahora estamos trabajando en la B. Volver a refinar algo que refinamos hace tan solo 4 semanas, pero que ahora no nos acordamos del contexto ni el porqué de las decisiones, es “relearning” o re-processing, desperdicio.

Y esa tarea de la iniciativa B que solo sabe “Fulanito” xq el resto estabamos con la iniciativa A, pero ahora “Fulanito” está con la iniciativa C. Y resulta que hay algo que no está del todo correcto y lo descubrimos después de 2 semanas, cuando “Fulanito” ha podido volver a trabajar en A. Otra vez relearning y volver a reprocesar algo.

“Pero tranquilo porque esto, lo solucionamos con una sesión de revisión técnica explicando que hemos hecho cada uno. DevA nos explica la iniciativa A, DevB la B y DevC la C y así compartimos conocimiento”. Esto se llama Hand-off y es otro de los wastes fomentados por los silos.

Una sesión para explicarnos que hemos hecho puede parecernos útil y necesario, pero pensad que es un parche de no aplicar One piece flow y seguir paralelizando iniciativas. Fomenta los silos de conocimiento e implica pérdida de información en el traspaso de conocimiento. Luego, todo esto nos llevará al relearning y a reprocesar las soluciones otra vez.

En mi experiencia, con solo intentar aproximarnos a un verdadero One piece flow, eliminamos gran parte de los “wastes” del proceso y conseguimos 2,3 y 4 veces mejor Cycle Time y Throughput.

Además nos aporta algo más intangible, pero diferencial, el compartir un mismo objetivo. Nos permite crear ownership del producto en el equipo, ya que es un problema en común que estamos solucionando juntos y no es un proyecto de DevA o de DevB, sino de todos.

En resumen, fomentamos la Co-elaboración (lo hacemos juntos) por encima de la co-ordinación (tú antes, yo después) o la co-operación (tú y yo separados sin chocarnos).

“En nuestro contexto no se puede”

Nadie ha dicho que sea fácil, sino que es mucho mejor. Para acercarnos a trabajar en flujos de una iniciativa a la vez, necesitamos generar cambios en el contexto y trabajar para conseguirlo. No olvidemos que el contexto es algo que en parte hemos establecido nosotros.

Vamos a ver que problemas me suelo encontrar en los equipos que hacen imposible aplicar esta práctica y donde es necesario meter energía para conseguir el cambio que buscamos:

“Nos llegan muchas peticiones de muchos sitios”

Existe un rol/patrón que ayuda a esto, un P.O. con capacidad y autonomía para priorizar y decidir ayuda a poder saber que es lo primero y que lo segundo.

“Tenemos muchos proyectos que no pueden esperar”

Hacer más cosas a la vez ya está demostrado que no va a conseguir que entreguemos antes, sino que además va a retrasar todos estos proyectos que tenemos en marcha. Como he comentado, mi experiencia es del orden de 2, 3 y 4 veces mejor CycleTime de las iniciativas o proyectos.

“Todo es prioritario”:

Pues ya tenemos algo que mejorar en la compañía. Todo lo que conozco y sigo aprendiendo sobre product management y gestión de la demanda, empieza por priorizar bien.

“Las prioridades cambian rápido, y hay que hacerlo todo”

No veo, como tener muchos proyectos en marcha a la vez da más agilidad para terminar más rápido y pivotar entre iniciativas sin tener problemas. Cuanto más tardes en entregar una iniciativa, más coste tendrá el cambio. Prioriza, haz iniciativas pequeñas y obtén feedback rápido para volver a priorizar.

“No podemos estar todos en la misma tarea!!!”, “Habrá gente que esté parada”

Nadie ha dicho estar todos en la misma línea de código. Aunque recordemos que hacer pair y mob programming ayuda muchísimo en tareas complejas y tiene grandes ventajas.

Si, por ejemplo sois un equipo de 6, ¿de verdad en una iniciativa de, digamos, unos 2 meses, no sois capaces de trabajar los 6 juntos? ¿Vais a estar 2 meses con dependencias que os impidan colaborar? Entonces, a lo mejor, esa iniciativa está mal dividida, mal iterada o no tenemos aún los skills necesarios para poder colaborar.

Puede que existan dependencias técnicas por un mal diseño, desarrolladores trabajando sobre la misma parte del código o la necesidad de implementar una parte antes que otra. Os dejo un par de prácticas conocidísimas, que aparte de necesarias para conseguir otras muchas ventajas, he comprobado que aportan mucho también en conseguir trabajar de forma mucho más colaborativa en equipos:

1. Vertical Slicing: eliminar dependencias entre tareas. Dejar de hacer tareas horizontales que no aportan, y centrarnos en algo que dé feedback respecto a si vamos por buen camino o que nos descubra impedimentos lo antes posible.
2. Continuos Integration, o mejor aún, Continuos Deployment: solo integrando el código de forma frecuente (minutos) y sabiendo que no rompemos nada (TDD, testing automatizado) somos capaces de trabajar varios desarrolladores en partes del código más acopladas de lo que nos gustaría. De esta forma podremos avanzar juntos en la solución y con menos problemas de bloqueos o dependencias.

“Estoy bloqueado por otro equipo, mejor avanzaré otro proyecto”

Todo lo que nos “ayude” a tomar decisiones más cercanas a cambiar de foco en vez de continuar con lo más prioritario, es un impedimento para que el sistema fluya mejor

Así que, si esto nos ocurre, ya tenemos identificado el problema del sistema y tendríamos que empezar a trabajar en cómo solucionarlo. ¿Tal vez con una organización de equipos distinta?

Una dependencia fuerte de un equipo suele ser un problema de diseño organizacional, de diseño de software, o ambos, como nos enseña la Ley de Conway.

Pero a veces suceden estas dependencias sí o sí y trabajar sobre la solución más sistémica nos lleva tiempo. Las acciones a corto plazo, pasan por co-elaborar por encima de co-ordinarse o co-operar entre los equipos.

Existen soluciones colaborativas, como internal open source o crear pequeños squads de corta duración y con los skills y conocimientos necesarios para cerrar una iniciativa de una sola vez.

Mientras, a más largo plazo y para poder tener un sistema más sostenible en el tiempo, deberíamos empezar a pensar en cambiar el diseño organizacional para atender mejor el propósito de la organización.

¿Qué contexto habéis creado para vuestros equipos?

¿Habéis trabajado de verdad con un flujo de un proyecto cada vez? ¿Alguna de estas frases suelen escucharse en vuestros equipos? ¿Habéis intentado cambiar algo del contexto que rodea al equipo para poder aplicar estas buenas prácticas? ¿Habéis aplicado de verdad One Piece Flow y CI/CD y no habéis logrado grandes cambios?