El término «value stream mapping» (algo así como mapeo del flujo de valor) viene de Lean, de Toyota (aunque hay referencias previas, ya en 1918), y tiene como objetivo describir la secuencia de actividades por las que pasa una organización para aportar valor a sus cliente, usuarios, negocio, etc.
El objetivo de hacer el «value stream mapping», obviamente, más viniendo de Lean, es detectar las actividades que, en el «flujo», aportan y las que son… desperdicio (para eliminarlas).
Yéndonos al mundo del software (no hay que olvidar que el «value stream mapping» viene de la industria), donde esta técnica puede usarse para reflexionar sobre por «donde» hay que pasar para llevar una idea de negocio a producción.
Y viene a ser, también, un detector de silos. Y un detector de workflows oscuros. Y de paradas, esperas, tiempos perdidos en aprobaciones, tiempos perdidos en extrañas maneras para salir a producción.
El «value stream mapping», al que, curiosamente, aun no le había dedicado un post, es otra de esas cosas antiguas que, de repente, se vuelve a poner de moda, algo que pasa mucho en lo nuestro.
También puede ser que esté de moda porque el oscuro, y dudosamente Ágil, framework de SAFe (ten cuidado y no estés tan seguro con #SAFe) lo cita entre sus prácticas (que pintaza de cascada tienen siempre los dibujos del «value stream mapping»).
Y también vas a ver los «value stream mapping» rondando por PMI-ACP. Ufff.
Creo que lo mejor que te puede pasar es que, por la obviedad de su resultado, de «dibujarlo», no le veas sentido a hacer un «value stream mapping», eso es lo que debería pasar. Esta técnica mola cuando no hay que usarla.
Porque aquellas organizaciones que andan liadas con «value stream mapping» (muchos de ellos son mapas gigantes y los he visto hasta pegados en posters en la pared) son las que tienen un lío tremendo de departamentos, silos, equipos no multifuncionales (te dejo post), externalizaciones (que no equipos en los que hay externos), workflows, aprobaciones, tableros supuestamente Ágiles con un montón de columnas, difíciles intentos de llegar a un DevOps, etc.
Desperdicio en general, y que buscan, de alguna manera, minimizar el lío en lo que puedan y, en otras, medio mantenerlo condimentándolo con un poco de «agilidad».
Que la Agilidad te acompañe.
Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.
También soy profe de la Universidad Rey Juan Carlos.
- Más allá del Management 3.0: 12 prácticas (de muchas) que no están en M 3.0 - 25 enero, 2024
- Más allá del Management 3.0: Otros muchos patrones para equipos Ágiles - 18 enero, 2024
- Años 30, Ohio (EE.UU.) y el Agile Product Management - 11 enero, 2024