Curso relacionados
| Fecha | Ciudad | Curso |
|---|---|---|
| 26/06 | Remoto | Professional Scrum Master II |
| 25/09 | Remoto | Professional Scrum Product Owner – Advanced (PSPO-A) |
| 15/09 | Remoto | Professional Scrum Product Owner (PSPO) – Immersion Program |
| 10/07 | Remoto | Professional Scrum Product Owner (PSPO) |
| 11/07 | Barcelona | Professional Scrum Master (Presencial BCN) |
En el artículo anterior introduje el Value Stream Mapping como técnica para analizar la eficiencia de una organización en la entrega de valor a sus clientes, concretamente en las innovaciones en sus productos y servicios.
En este artículo voy a añadir una herramienta paralela de Lean: las 7 fuentes de desperdicio, y en el siguiente pondré un ejemplo práctico de aplicación de ambas herramientas.
Los principios de Lean Thinking
La filosofía de Lean Manufacturing introducida por Toyota, se ha estudiado en diferentes libros, p.e. [2], [3] y [4] y fue adaptada al mundo del software por Mary y Tom Poppendiek [1] en 2003.
El objetivo de Lean es llevar el máximo valor al cliente de la manera más rápida y barata (¡se dice pronto!). En la siguiente figura se ven los 5 principios de Lean que dan soporte a este objetivo.
En primer lugar está identificar y definir el valor. Quien percibe y decide el valor es el cliente, por ello los equipos deben colaborar frecuentemente con este para entender progresivamente mejor cuales son sus problemas y qué soluciones son las mejores.
Las actividades de product discovery nos facilitan entender y filtrar las mejores soluciones viables a los problemas del cliente, evitando construir cosas innecesarias, quizás la manera más barata de ahorrar tiempo y dinero.
En segundo lugar está el mapeo de la corriente de valor, que vimos en el artículo anterior.
En tercer lugar está la optimización del flujo, eliminando los impedimentos organizativos como p.e.
- Retraso por aprobaciones de gobierno corporativo (p.e. presupuesto, priorizaciones, etc.).
- Bloqueos por dependencias dentro del equipo y fuera (p.e. clientes, otros equipos u otras especialidades como seguridad, sistemas, etc.).
- Esperas por otros desperdicios (ver el siguiente apartado).
El uso de un sistema como Flight Levels puede ayudar a identificar y gestionar las dependencias y esperas identificadas en el Value Stream Map.
En cuarto lugar está la gestión del trabajo según la demanda (pull). Una vez que sabemos qué le aporta valor al cliente y tenemos un flujo de producción de valor optimizado, podemos producir bajo demanda.
En el desarrollo de productos y servicios digitales, significa iniciar las actividades de desarrollo cuando tenemos una certeza que el cliente necesita una solución a algún problema.
Aunque no suene intuitivo, esto quiere decir que NO construiremos rápidamente cualquier cosa que se nos pida, porque eso es un riesgo de desperdiciar el tiempo y dinero en cosas innecesarias. Las actividades de product discovery nos filtrarán dichas peticiones innecesarias y nos permitirán también entender mejor qué se necesita construir (principio 1 de Lean).
Además, utilizar métricas de uso del producto o de feedback de los clientes nos ayuda a saber qué partes del producto son más prioritarias, por un lado las funcionalidades que se usan poco o nada (sea por mal diseño o por innecesarias), y por el otro lado las que se usan mucho y proporcionarán mayor impacto.
En quinto y último lugar tenemos la mejora continua. Lean ofrece dos estilos de mejora alternativos:
- Kaizen: mejoras pequeñas propuestas habitualmente por los trabajadores. Un ejemplo son las retrospectivas donde el equipo de desarrollo puede identificar mejoras a su trabajo o impedimentos de otras partes de la empresa.
- Kaikaku: mejoras más radicales a los procesos, que deben ser autorizadas por la dirección.
A menudo el análisis del Value Stream Mapping identifica ineficiencias propias del diseño organizativo funcional y los controles del gobierno corporativo.
Como ejemplo de ineficiencias por diseño organizativo tenemos que las personas que colaboran habitualmente con el equipo de desarrollo están en grupos diferentes, con prioridades gestionadas por managers diferentes, p.e. especialistas de negocio y grupos de UX o QA.
Como ejemplo de ineficiencias por controles de gobierno tenemos los presupuestos anuales que deciden las inversiones, que significan a veces muchos meses de espera para aprobar y comenzar las iniciativas.
Como vimos en el artículo anterior, la mayoría del margen de mejora está en esperas sobre las que el equipo de desarrollo no puede decidir. Por ello suelen ser decisiones de tipo Kaikaku que deben ser entendidas e impulsadas por la dirección.
🤔 ¿Cuáles son las 7 fuentes de desperdicio de Lean en desarrollo de software?
En el centro del gráfico de la sección anterior aparecían 7 palabras (overproduction…), que son las 7 fuentes de desperdicio que identifica Lean.
Son aspectos del trabajo que causan ineficiencias y que podemos descubrir durante las 5 fases de la optimización del valor que hemos visto en la sección anterior.
La adaptación de las fuentes de desperdicio del mundo industrial al desarrollo de software la hicieron el matrimonio Poppendieck en su libro Lean Software Development [1].
En el siguiente artículo explicaré un ejemplo de aplicación conjunta de VSM y 7 fuentes de desperdicio GymTonic, en mi caso de estudio estándar.
Veamos ahora estos tipos de desperdicio.
- Defectos. Introducir un defecto de cualquier tipo (p.e. funcional, de estilo gráfico, usabilidad, técnico, etc.) obliga a repararlo cuando se encuentra, y siempre cuesta más repararlo que hacerlo bien al principio.
- Funcionalidades Extra. En esta categoría entraría todo el esfuerzo dedicado a desarrollar cosas que no se necesitan, p.e. problemas del cliente que no hemos validado, o funcionalidades que no solucionan sus problemas, o funcionalidades innecesariamente sofisticadas.
- Multitarea. Cuando los ingenieros tienen demasiadas tareas en paralelo, ya sea por una planificación deficiente, porque no saben centrarse en acabar las cosas antes de comenzar otras, o por presiones excesivas de clientes o managers, se generan muchos cambios de contexto.
Cada cambio de contexto requiere cambiar de herramientas, documentos o interlocutores, y eso requiere un tiempo adicional hasta que se es productivo de nuevo. Además esto puede generar estrés y potenciales defectos.
- Retrasos. No es lo mismo completar todas las actividades de la identificación de una necesidad y el desarrollo/entrega de la solución en un corto espacio de tiempo, que pase mucho tiempo entre actividades. Esto suele pasar por procesos burocráticos (p.e. aprobaciones) o porque las personas están saturadas y el trabajo debe esperar. En cualquier caso, esto provoca un desperdicio parecido al de la multitarea: no tenemos el contexto del trabajo fresco y hemos de refrescarlo.
- Trabajo completado a medias. Cuando el trabajo se entrega incompleto, habitualmente se debe completar más tarde y cuesta más que completarlo a la primera. Esto deriva también en los problemas del retraso y de la multitarea.
- Intercambios. El intercambio de trabajo entre personas suele generar una carga adicional de trabajo, para recibirlo, entenderlo y continuar el trabajo.
Esta sobrecarga puede ser pequeña si las personas que se intercambian el trabajo se conocen y comparten el proceso de trabajo, o ser grande si tienen poco contexto en común y se comunican únicamente via herramientas (p.e. un ticket de Jira).
- Procesos innecesarios. Por último, los procesos orientados al control o a la calidad que no aporten un beneficio real, sino que sean burocráticos, generan un coste adicional e innecesario.
Además estos tipos de errores se retroalimentan. P.e. los cambios de manos innecesarios o no poder completar el mismo trabajo de una vez, provoca el riesgo de introducir errores. Y los errores provocan p.e. multitarea (Task Switching) al resolverlos.
¿Cómo mejorar y difundir este artículo en 20 segundos?
¿Qué te ha parecido este artículo? ¿Te gustaría que profundice en algún aspecto?
Si os ha gustado este artículo, os pido dos cosas a cambio:
- Añadid comentarios de vuestra experiencia y punto de vista , haced “like” y compartirlo con vuestros conocidos.
- Completad esta encuesta que ¡os tomará solo 20 segundos!
Referencias
- Lean Software Development, Poppendieck (2003)
- The machine that changed the world, Womack & Jones (2007)
- Toyota Kata, Rother (2009)
- Lean Thinking, Womack & Jones (2017)
