Quiero compartirles lo que he aprendido como Scrum Master en un proyecto de Optimización de Procesos Bancarios y así mismo afinar este tema, para presentarlo en el Agiles 2017 en Chile.
Para meterlos al contexto, estoy liderando un proyecto de Optimización de Procesos Bancarios, donde cada proceso es «como» un micro sistema, con un aplicativo dueño (Usuario) y sus propias dependencias, y el objetivo de este proyecto o servicio, es refactorizar los procesos bancarios, para reducir su consumo de CPU, y así generar ahorro en la facturación de la infraestructura.
Este caso es de Optimización de Procesos, pero también se puede utilizar para incidencias (No planificables).
Hasta aquí, ya tenemos algo raro, no existen historias de usuario, si no procesos a optimizar (de ahora en adelante procesos), y nuestro backlog es un listado de procesos priorizados a optimizar.
Cuando tomé el proyecto, lo primero que pensé fue en usar Scrum, obvio, por algo soy Scrum Master, pero me dí con la sorpresa que los procesos tienen una duración muy variable y difícil de predecir, ya que al ser, micro sistemas, cada uno tiene una naturaleza distinta, por lo que un Sprint de 2 semanas o 4 semanas, iban a quedar cortos.
Tampoco podíamos dividir los procesos, ya que la entrega de valor para el cliente (Definition of Done), es cuando el proceso esté optimizado (y no a medio camino en su implementación).
Luego salio la propuesta de usar Kanban, para procesos continuos y no planificables, pero no quería dejar las ceremonias de Scrum, que para mi dan mucho valor, sobre todo alineandonos al principio Agil de Inspeccionar y Adaptar («A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia»).
Entonces nació Scrumban 🙂 (Que no sólo es Scrum y un tablero Kanban) que es usar lo mejor de Scrum y lo mejor de Kanban con sus restricciones correspondientes.
Primero hay que hacer una diferencia en que tan restrictivo y adaptativo son Scrum y Kanban, dejo un gráfico:
Como pueden «ver» Scrum tiene 9 restricciones, que ya todos conocen y agrupadas en Ceremonias y Roles, a diferencia de Kanban que sólo tiene 3 restricciones:
- Que sea visible (ya de por si, los tableros son visibles 🙂 )
- Que se limite el WIP (cuantos procesos deben de estar en cada columna en Progreso)
- Que se mida el Cycle Time (Tiempo desde que comienza el trabajo en progreso hasta que está en Done)
El resultado de Scrumban, es seguir haciendo las ceremonias de Scrum: reuniones diarias, retrospectivas, review, mini planning y manejar los roles: Scrum Master, Product Owner, Dev Team (Leader Team y Dev Team), y ponerle las 3 restricciones de Kanban a nuestro tablero.
Pero algunas cosas cambian:
- Como el foco, donde Scrum se enfoca mejor en las Personas y el Producto, Kanban se enfoca mejor en las Personas y el Proceso.
- La Velocidad deja de ser un factor importante y el Cycle Time lo reemplaza, donde debemos de mejorar el flujo, para reducir los tiempos de permanencia de un Proceso en progreso.
- En Scrum cuando se usa un tablero Kanban, no es necesario limitar el WIP, en Kanban o Scrumban si es necesario limitar el WIP, y así reducir los posibles cuellos de botella y propiciar que el número de elementos que ingresan al flujo sea igual al número de los que salen.
Esto fue sólo un acercamiento a nuestro Proyecto en Scrumban, se que quedaron muchas dudas, pero aprovechemos el formulario de abajo para despejarlas.
Hay muchas otras cosas que compartir sobre este proyecto Scrumban, es posible que se crea otro post en el blog.
Y si te gusto el post, compártelo 🙂
Adelante, sé rebelde y libera tu curiosidad haciendo clic en la imagen para descubrir todos los detalles jugosos sobre los próximos cursos de SAFe Scrum Master.
