De la visualización al método Kanban
He visto durante estos últimos años, los mismos fallos con Kanban que con Scrum. Se cometen de la manera más inocente, al igual que en Scrum cambiando ceremonias, no realizándolas, quedándose en los superfluo y no llegando al potencial de Scrum, como proceso para estimular un cambio de mindset y de forma de hacer las cosas, así como para estresar un área, departamento o compañía para propagar o iniciar un cambio de modelo productivo.
Con Kanban está sucediendo lo mismo en muchos escenarios. Se ven muchos paneles de visualización y no es Kanban, ni tan siquiera es Proto-Kanban.
Recordemos que un panel de visualización es eso, solo un panel donde podemos visualizar nuestros problemas, nuestro trabajo. No se toman decisiones, ni mejoras, simplemente se queda en visualizar.
Entre ese proceso inicial de visualización y el método Kanban, existe o puede existir un estado de transición intermedio : Proto-Kanban.
Proto-Kanban se considera a paneles cuya misión es estresar el sistema para usar sistemas Kanban y permitir el cambio evolutivo.
Si solo se persigue visualizar el trabajo no estamos ni en Proto-Kanban, estamos en visualización.
Con un sistema Proto-Kanban se intenta estresar el sistema mediante:
- la toma de decisiones en el panel de visualización.
- empezar a medir para tomar decisiones con datos.
- comenzar con el cambio de mentalidad pull (empieza a parar, deja de empezar o comienza a terminar, termina de empezar).
- tener conversaciones en torno al panel para la toma de decisiones incluyendo feedback loops.
Un gran cambio de visualización, o Proto-Kanban a método Kanban es la existencia o no de una columna llamada doing o in progress. Si nos damos cuenta doing o in progress no aporta valor final al producto, no es un estado de valor, es un estado de transición.
El método Kanban persigue la entrega de valor, cada estado, ha de ser mirado o revisado con ese punto de vista, la entrega de valor al cliente final siempre.
El método Kanban se persigue mediante la implantación de una serie de prácticas:
- Visualización completa del sistema : Muchas veces no se visualiza el sistema completo porque no se quieren ver los puntos de dolor, cuellos de botella, etc que hacen daño.
- Limitar el WIP : Sólo limitando el trabajo en curso se comenzará a terminar las cosas mejor, con más calidad y más rápido. Se le implantará coherencia al sistema que se está creando.
- Tener flujo Pull completo : Comenzar a tirar del sistema y no a vernos absorvidos por la vorágine de todo es importante.
- Establecer políticas y puntos de compromiso: Creando commitment point fortalecemos nuestro compromiso con el cliente y el sistema, pasando a tener acuerdos de entrega o compromisos asumidos. Establecemos políticas para los tipos de trabajo en el sistema, para los cambios de estado, de esta manera mejoramos la calidad del trabajo. Establecemos clases de servicio que facilitan los acuerdos de entrega y servicio al cliente.
- Feedback loops: Son ceremonias a realizar que van desde una reunión de coordinación diaria (Standup Meeting), una reunión para administrar la entrada del sistema pull (replenishment o Commitment Meeting), una reunión para hacer foco en como se realiza el delivery (Delivery Planning Meeting), una revisión de la forma de entrega (Service Delivery Review), riesgos (Risk Review), Operaciones (Operations Review) y Estrategia (Strategy Review), estas últimas 3 cuando hay sistemas Kanban extendidos, enlazados y escalados en otros niveles de la empresa.
- Evolución de mejora: Es una evolución como vemos, en un sistema que hay que inspeccionar y adaptar continuamente para mejorar, implantando la cultura de mejora continua.
Existe un modo de ver si de verdad se está implantando correctamente el método Kanban, porque no es simplemente unas prácticas y un tablero, es una cultura de mejora y es un cambio en las relaciones con los implicados, se denomina Litmus Test y verifica si se ha cambiado el modo de hacer las cosas de verdad :
- ¿Los managers han cambiado su comportamiento? El modo en que se relacionan y cooperan.
- ¿Ha cambiado la entrada del cliente? El cliente ha cambiado los mecanismos de solicitud.
- ¿Ha cambiado su contrato el cliente? Al cambiar el sistema y mejorar la negociación con el cliente en los nuevos acuerdos y marcos de trabajo de entrega han de cambiar.
- ¿Ha cambiado el service delivery del cliente? El modo de entrega, la calidad, velocidad, compromiso, etc ha tenido que cambiar y ser percibido por el cliente.
VISUALIZACIÓN:
PROTO-KANBAN:
KANBAN:
Con Kanban está sucediendo lo mismo en muchos escenarios. Se ven muchos paneles de visualización y no es Kanban, ni tan siquiera es Proto-Kanban.
Recordemos que un panel de visualización es eso, solo un panel donde podemos visualizar nuestros problemas, nuestro trabajo. No se toman decisiones, ni mejoras, simplemente se queda en visualizar.
Entre ese proceso inicial de visualización y el método Kanban, existe o puede existir un estado de transición intermedio : Proto-Kanban.
Proto-Kanban se considera a paneles cuya misión es estresar el sistema para usar sistemas Kanban y permitir el cambio evolutivo.
Si solo se persigue visualizar el trabajo no estamos ni en Proto-Kanban, estamos en visualización.
Con un sistema Proto-Kanban se intenta estresar el sistema mediante:
- la toma de decisiones en el panel de visualización.
- empezar a medir para tomar decisiones con datos.
- comenzar con el cambio de mentalidad pull (empieza a parar, deja de empezar o comienza a terminar, termina de empezar).
- tener conversaciones en torno al panel para la toma de decisiones incluyendo feedback loops.
Un gran cambio de visualización, o Proto-Kanban a método Kanban es la existencia o no de una columna llamada doing o in progress. Si nos damos cuenta doing o in progress no aporta valor final al producto, no es un estado de valor, es un estado de transición.
El método Kanban persigue la entrega de valor, cada estado, ha de ser mirado o revisado con ese punto de vista, la entrega de valor al cliente final siempre.
El método Kanban se persigue mediante la implantación de una serie de prácticas:
- Visualización completa del sistema : Muchas veces no se visualiza el sistema completo porque no se quieren ver los puntos de dolor, cuellos de botella, etc que hacen daño.
- Limitar el WIP : Sólo limitando el trabajo en curso se comenzará a terminar las cosas mejor, con más calidad y más rápido. Se le implantará coherencia al sistema que se está creando.
- Tener flujo Pull completo : Comenzar a tirar del sistema y no a vernos absorvidos por la vorágine de todo es importante.
- Establecer políticas y puntos de compromiso: Creando commitment point fortalecemos nuestro compromiso con el cliente y el sistema, pasando a tener acuerdos de entrega o compromisos asumidos. Establecemos políticas para los tipos de trabajo en el sistema, para los cambios de estado, de esta manera mejoramos la calidad del trabajo. Establecemos clases de servicio que facilitan los acuerdos de entrega y servicio al cliente.
- Feedback loops: Son ceremonias a realizar que van desde una reunión de coordinación diaria (Standup Meeting), una reunión para administrar la entrada del sistema pull (replenishment o Commitment Meeting), una reunión para hacer foco en como se realiza el delivery (Delivery Planning Meeting), una revisión de la forma de entrega (Service Delivery Review), riesgos (Risk Review), Operaciones (Operations Review) y Estrategia (Strategy Review), estas últimas 3 cuando hay sistemas Kanban extendidos, enlazados y escalados en otros niveles de la empresa.
- Evolución de mejora: Es una evolución como vemos, en un sistema que hay que inspeccionar y adaptar continuamente para mejorar, implantando la cultura de mejora continua.
Existe un modo de ver si de verdad se está implantando correctamente el método Kanban, porque no es simplemente unas prácticas y un tablero, es una cultura de mejora y es un cambio en las relaciones con los implicados, se denomina Litmus Test y verifica si se ha cambiado el modo de hacer las cosas de verdad :
- ¿Los managers han cambiado su comportamiento? El modo en que se relacionan y cooperan.
- ¿Ha cambiado la entrada del cliente? El cliente ha cambiado los mecanismos de solicitud.
- ¿Ha cambiado su contrato el cliente? Al cambiar el sistema y mejorar la negociación con el cliente en los nuevos acuerdos y marcos de trabajo de entrega han de cambiar.
- ¿Ha cambiado el service delivery del cliente? El modo de entrega, la calidad, velocidad, compromiso, etc ha tenido que cambiar y ser percibido por el cliente.
VISUALIZACIÓN:
PROTO-KANBAN:
KANBAN:
Comentarios
Publicar un comentario