Aprendizajes del diseño de sistemas Kanban en una cadena de valor

Para diseñar un sistema Kanban se recomienda utilizar STATIK.

En este post os vamos a contar los aprendizajes obtenidos al utilizarlo para poner en marcha una cadena de valor completa para su gestión con método Kanban

En publicaciones anteriores os hemos contado cómo comenzamos una evolución de una organización hacia el uso de método Kanban para la gestión de cadenas de valor mediante algunas herramientas como Valué Stream Mapping.
Una vez que tenemos identificados los flujos de valor y de información y todos los intervinientes en los mismos pasamos a diseñar nuestro sistema Kanban mediante STATIK.

STATIK

STATIK, o Systems Thinking Approach to Introduce Kanban, es un modelo para introducir el método Kanban desde una perspectiva sistémica y enraizada en el propósito de la organización. Parte de entender la organización como un conjunto de servicios conectados que, como fin último, aportan un valor claro y diferencial.

STATIK se estructura en 8 pasos. Para poner en marcha STATIK previamente necesitamos identificar y listar los servicios de que se compone la organización o área objetivo. Una vez estructurados, los 8 pasos de STATIK se realizarán para cada uno de esos servicios.

Este método para diseñar sistemas Kanban se puede aplicar de muy diferentes formas y en diferentes momentos de la introducción de Kanban, tanto para comenzar a definir el sistema como para su evolución continuada.

En Enciende La Luz realizamos una serie de sesiones a medida de las necesidades de la organización utilizando diversas dinámicas de facilitación de las mismas para obtener los mejores resultados e impulsando desde el aprendizaje mediante el ejemplo la introducción de los valores y principios del método Kanban y el modelo operativo definido en cada organización.

La experiencia

En esta experiencia en la que lo hemos puesto en marcha se ha decidido modelar el sistema tal y como está actualmente la estructura organizativa, aplicando STATIK a los actuales equipos funcionales que operan la cadena de valor en sus diferentes etapas y procesos.

A esta estructura de áreas y equipos se le ha añadido un nivel superior a todos ellos (este nivel no existía oficialmente en la organización a nivel de la cadena de valor) para la visualización y gestión de toda la cadena de valor al completo.

Alrededor de este nueva estructura se le ha dotado de un equipo multifuncional mediante algunos roles adicionales como un manager de productos y un manager de servicio y representantes de las diferentes áreas para comenzar a disponer de una red de conexión de servicios y procesos alienados al flujo principal de la cadena de valor.

Como consultores hemos facilitado el proceso de Statik y el soporte para el uso de una herramienta de visualización por parte de todas las personas partícipes en la cadena de valor, dejando que ellos mismos como equipos definan y diseñen sus procesos de gestión y visualización del trabajo en la herramienta, y acompañándolos en todos los pasos para fortalecer el marco de uso del modelo operativo Kanban definido, sus valores y principios.

Como herramienta para la visualización y gestión del trabajo en la cadena de valor se ha optado por el uso de Kanbanize. Facilita el diseño y configuración de los propios tableros, flujos de trabajo y tarjetas de visualización de los diferentes tipos de trabajo por cualquiera de las personas participes en los diferentes espacios de trabajo, lo que permite que el propio equipo aplique el resultado del diseño del sistema Kanban obtenido mediante STATIK en la herramienta y lo actualice conforme se vaya introduciendo mejora evolutiva en el sistema.

Kanbanize es la plataforma Kanban líder para la gestión y entrega de proyectos eficientes.

Kanbanize, ¡unete!

Aprendizajes y beneficios obtenidos

La utilización del método STATIK para comenzar a diseñar los sistemas Kanban genera una serie de beneficios en la transformación hacia el uso de método Kanban.

  • La visualización de la identificación de sus propios servicios y procesos mediante las dinámicas realizadas comienza a generar propuestas de mejora, algunas tan claras que se comienzan a aplicar con la incorporación del nuevo modelo operativo y marco de trabajo con Kanban. Aparecen todas esas políticas no escritas y debates de si algunas de las formas de hacer las cosas son las más adecuadas.
  • Los equipos de las diferentes áreas comienzan a modificar sus mecanismos de comunicación y colaboración para poder comenzar a visualizar y gestionar el trabajo de forma más eficiente y unificada. Todo ese trabajo oculto y rutinario que se hacia y que no estaba visible para nadie comienza a visualizarse y gestionarse.
  • El hecho de generar una visualización y gestión de su sistema mediante una nueva herramienta común para toda la cadena de valor (se estaban utilizando herramientas dispares e inconexas para cada área) fomenta la transparencia y empieza a visualizar los problemas y puntos de mejora existentes dentro de las áreas y entre las áreas para toda la cadena de valor. Se comienzan a gestionar las dependencias y los bloqueos de una forma más visual y comunicativa, con menos burocracia pesada y lenguaje más colaborativo para la resolución de los mismos.
  • El sentimiento de pertenencia de las personas a la misma cadena de valor y el empoderamiento sobre el nuevo sistema y método de gestión aumenta al ser todos ellos partícipes de su definición y creación mediante la participación de TODOS en las dinámicas y comienzo de la gestión con la herramienta que se utiliza para ello.

Siguientes pasos

Actualmente los equipos de la cadena de valor se encuentran en etapas iniciales de su nuevo proceso de gestión mediante Kanban y mediante la aplicación de Kanban Maturity Model (KMM) estamos llevando la evolución de este sistema Kanban a niveles superiores dentro de toda la organización. Os iremos contando esta experiencia con KMM en siguientes post.

Enlace a post anteriores de esta experiencia:
INCREMENTA LA PRODUCTIVIDAD CON KANBAN Y VALUE STREAM MAPPING

Para más información de Lean Kanban y STATIK:
LEAN Y KANBAN ¿QUÉ ES?

También te puede interesar.

Ventajas de aplicar el Lead Time en los Equipos Scrum

En ocasiones, cuando arrancamos con los Equipos Scrum, nos encontramos con un par problemas habituales: el tamaño de los PBIs y que trabajan en paralelo en todas los PBIs del sprint. Hoy te traigo una solución que hemos puesto en marcha en algunos Equipos Scrum de nuestros clientes.

Burndown y Burnup para el Scrum Master

Como Scrum Master puedes obtener información muy valiosa analizando estos dos gráficos para entender lo que está ocurriendo en tu equipo.

¿Tiene mi equipo Scrum los conocimientos necesarios para construir mi Producto?

Scrum propone que nuestros equipos tengan todos los conocimientos para generar productos que cubran nuestras necesidades. Te traigo hoy una herramienta sencilla para averiguar si tus equipos Scrum son realmente multidisciplinares.

Aprendiendo en un Equipo Scrum

El conocimiento compartido potencia a tu equipo. Aquí descubrirás cómo identificar las áreas de conocimiento y favorecer su aprendizaje continuo

Las consecuencias de un Backlog interminable

Nuestro Product Backlog con el tiempo se va llenando y convirtiendo en un Backlog interminable. En este artículo te planteo las consecuencias más relevantes que tiene.

Cómo mejorar tu Scrum Daily

En ocasiones nos encontramos con equipos en los que la Scrum Daily se ha convertido en un evento individualista donde cada miembro del equipo de desarrollo comenta las tareas realizadas durante el día anterior, muchas veces con cierto carácter de reporte. Sin embargo, la daily es un evento colectivo donde a través de la inspección y adaptación se traza un plan de trabajo del día para el equipo.

¿Quién debe priorizar el Product Backlog en Scrum?

Agile y Scrum nacen principalmente del mundo del Software, aunque en los últimos años se han llevado a otros ámbitos de las empresas. Scrum plantea al Product Owner como una única persona. La realidad de la empresa nos empuja a implementar algún tipo de escalado de Scrum, en el que aparecen, de una forma y otra, Product Owners de Product Owners. ¿Significa esto que se está haciendo una mala implementación de Scrum? ¿O nos estamos adaptando a las necesidades tal y como indica Agile? ¿Tiene que de verdad ser una única persona? ¿O hay otras posibilidades manteniendo la cultura Agile?

¿Es conveniente tener un Equipo Scrum en exclusiva para Incidencias?

En tus Equipos Scrum os encontráis en una situación en la que la cantidad de incidencias que hay que atender os penalizan demasiado, o la deuda técnica acumulada aumenta en exceso la complejidad de cualquier evolución en software.

Mi estrategia de Onboarding como Scrum Master

Me incorporo a un equipo como Scrum Master, ¿¿por dónde empiezo??

Estoy seguro de que esta pregunta ha pasado por la cabeza de más de uno y de una cuando se ha enfrentado al reto de comenzar a trabajar en una nueva empresa o con un nuevo equipo. En este post quiero compartir una estrategia que yo he utilizado y me ha sido útil para abordar el proceso de onboarding.

El Product Owner y su relación con los Stakeholders

Como Product Owner enseguida te has dado cuenta de la gran importancia que tiene tu relación y la del Equipo Scrum con los Stakeholders.

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada.

Aceptarás nuestra política de cookies si continúas navegando.

ACEPTAR
Aviso de cookies