Cursos relacionados
| Fecha | Ciudad | Curso |
|---|---|---|
| 04/03 | Curso virtual | Professional Scrum Master – Advanced (PSM-A) |
| 31/03 | Curso virtual | Professional Scrum Master (PSM) |
| 01/04 | Curso virtual | Professional Scrum Product Owner (PSPO) |
En los dos últimos artículos sobre Lean hablé de 2 de sus herramientas más extendidas: el diagrama Value Stream Mapping y el modelo de 7 fuentes de desperdicio para el desarrollo de software.
¡Ahora vamos a ponerlos en práctica! Utilizaremos mi caso de estudio favorito de GymTonic, la cadena ficticia de gimnasios. 💪
Acelerando el proceso de mejora de la APP del cliente
GymTonic tiene una APP que utilizan los clientes para gestionar su relación con el gimnasio y su operativa diaria.
Dado que es el servicio estrella del ámbito digital, querían acelerar al máximo el lead time, o sea, el plazo desde que se detecta una necesidad de los clientes sobre la APP hasta éstos la una solución a esta necesidad disponible.
Para ello Geanina, la product owner de la APP y Artur, el Scrum Master de GymTonic, reunieron a todas las personas que podían aportar la información necesaria para diagramar un Value Stream Map.
- Un entrenador del gimnasio.
- Una persona de recepción.
- Una persona del equipo de desarrollo de producto, y
- Un cliente.
El resultado fue el siguiente:
Mediante este diagrama se descubrieron varias ineficiencias y a continuación se describe como se atacaron:
Espera 1 – Comité mensual de IT. Cualquier idea de mejora que no era una incidencia del servicio (p.e. la APP no funciona) se evaluaba en el comité mensual de dirección, para aprobar la inversión.
Se descubrió que el 80% de las mejoras eran pequeñas cosas que consumían pocos días de desarrollo, por lo que no merecían esperar a este comité y podían realizarse directamente en el siguiente sprint.
Ahorro: de 30 días se pasa a 7 días (½ sprint) en el 80% casos → 18,4 días.
Espera 2 – Siguiente Sprint. Los Sprints duraban 4 semanas, y su gestión del alcance del Sprint era muy rígida. Una vez comenzado el Sprint no se admitía absolutamente nada que no fuera una incidencia.
Se decidió que cualquier petición no planificada pero valiosa, y que se estimara en menos de 2 días de trabajo, se podía hacer en el Sprint actual mientras este tipo de peticiones no superaran el 25% del tamaño del backlog del Sprint. Además se decidió acortar los Sprints a 2 semanas para acelerar el tiempo de respuesta.
Ahorro: para el 75% de las peticiones la espera se reduciría en 14 días, y para el 25% lo haría en 21 días → 15,75 días.
Actividad ineficiente 1 – Piloto de 1 semana. Los pilotos se hacían de 1 semana para poder evaluarlos en la reunión de despliegues semanales, aunque se descubrió que el 80% eran cambios muy sencillos que no merecía la pena ser pilotados, y se podían desplegar inmediatamente tras la prueba.
Ahorro: el 80% de peticiones evitaban el piloto de 7 días → 5,6 días.
Espera 3 – Ventana de despliegue semanal. Los procesos de gestión del servicio IT, basados en ITIL V3, habían decidido planificar los despliegues de las aplicaciones los lunes por si habían incidencias con los cambios.
Se decidió automatizar las pruebas para disminuir los incidentes, delegar los despliegues con bajo riesgo técnico (el 80%) y crear un chat compartido entre desarrolladores y responsables de sistema para coordinarse.
Ahorro: el 80% de peticiones podía desplegar inmediatamente → 5,6 días.
El ahorro total se estimaba en 45,35 días, bajado el tiempo total a 44,65 días (un 50% de ahorro).
Así pues, el uso del Value Stream Map prometía acortar a la mitad el tiempo de entrega de las mejoras en la APP de los clientes sin trabajar más.
Eliminando desperdicios del proceso de mejora del servicio
Artur, el Agile Coach, animó a Geanina, la Product Owner, a ir más allá de la mejora obtenida y eliminar más fuentes de desperdicio en el trabajo. Para ello propusieron a los mismos participantes del ejercicio anterior usar el modelo de las 7 fuentes de desperdicio de Lean a las fases del proceso de mejora de la APP que se evaluó anteriormente .
El resultado fue el siguiente diagrama:
A continuación se detallan los desperdicios identificados.
👉 1. Falta de testing en desarrollo. La falta de conocimientos hacía que los desarrolladores no hicieran un testing adecuado y se liberaban muchos defectos. Esto producía a su vez tener que parar el desarrollo de funcionalidades para corregir urgentemente los defectos, bajando la productividad de los Sprints.
Solución: Traer a un especialista de QA al equipo para instaurar un estándar de pruebas y entrenar a los desarrolladores.
👉 2.No se validan las peticiones. El equipo se dio cuenta de que algunas peticiones se aceptaban sin saber si realmente eran un problema real para los usuarios, o estimar cuantos usuarios podrían beneficiarse. Esto producía añadir funcionalidades que realmente no eran necesarias.
Solución: Crear una checklist con comprobaciones básicas que filtran peticiones con poco valor real.
👉 3. Muchas tareas en paralelo en desarrollo. La falta de transparencia respecto a las tareas en curso hacía que se acumularan muchas de estas en paralelo. Esto provocaba a su vez que los desarrolladores cambiaran de tarea varias veces al día por lo que se rompía su concentración y bajaba su productividad, además de aumentar el riesgo de defectos.
Solución: Añadir todas las peticiones en curso del equipo de desarrollo a un tablero kanban y limitar el WIP [1] o peticiones en paralelo. Esto tendrá el doble efecto de trabajar con efectividad en las prioridades y reducir el agobio. Además facilita disminuir la multitarea. Ambas cosas facilitan que se mantenga el testing.
👉 4. Retraso al evaluar las peticiones. En ocasiones había peticiones que tardaban semanas en ser evaluadas. Esto provocaba que cuando surgían dudas al evaluar las peticiones, los peticionarios se olvidasen frecuentemente de los detalles y se tuviera que retrabajar la recogida.
Solución: Poner las peticiones en un repositorio común para que se tardara, como máximo, 2 semanas en evaluarlas.
👉 5. No se pilota (en ocasiones) con todos los roles. No existe un método común para pilotar los cambios en las funcionalidades, por lo que a veces se olvida involucrar a algunos roles. Por esto, en ocasiones, estos roles protestan cuando se despliegan las funcionalidades y se deben modificar estos cambios, provocando un sobrecoste.
Solución: habilitar una checklist que evite la posibilidad de saltarse la validación con ciertos roles.
👉 6. Las personas que pilotan cambian frecuentemente. Esto obliga a que en ocasiones se tengan que definir los pilotos más de la cuenta, o a que una persona comience un piloto y tenga que continuar otra. Ambas situaciones provocan un sobrecoste y aumentan la probabilidad de error.
Solución: planificar mejor la disponibilidad de las personas que pilotan para disminuir sus cambios.
👉 7. Se despliegan igual cambios sencillos que complejos. El procedimiento de despliegue es igual para cambiar una APP que la versión del ERP. Esto provoca que cambios pequeños y con bajo riesgo sigan un proceso detallado y costoso, que no aporta ningún valor.
Solución: tipificar los cambios sencillos a las aplicaciones y diseñar un proceso exprés.
Conclusión: producir más trabajando menos
En este artículo hemos visto en un ejemplo sencillo de como dos herramientas de Lean, Value Stream Map y 7 fuentes de desperdicio, han permitido:
- Acortar el tiempo de desarrollo un 50%.
- Rebajar el trabajo innecesario y aumentar la productividad.
- Aumentar la calidad y disminuir defectos.
Y todo sin añadir sin invertir más recursos.
¿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:
1. ¿Cuáles son los beneficios de limitar el WIP? de David Coloma (versión infografía)
