One piece flow: De uno en uno por favor

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.

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.

“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”.

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

  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?

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

--

--

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store