¿Qué hacemos con los roles cuando comenzamos con el método Kanban?

Algo que suelen preguntarse las organizaciones cuando comienzan a implementar el método Kanban es que hacer con los roles y posiciones definidos en la estructura actual. Vamos a ver cómo lo planteamos en Enciende la Luz desde nuestro modelo operacional de evolución a Kanban de manera incremental.

que hacemos con los roles cuando comenzamos con el método kanban

Siguiendo con el artículo de la semana pasada escrito por mi compañero David vamos a profundizar más en algunos detalles para responder a preguntas como esta.

El método Kanban no prescribe roles o reuniones como hacen otros marcos como Scrum. Sin embargo, se han identificado unos roles y unas reuniones desde la experiencia en las organizaciones que son relevantes para que la organización siga los principios del método mediante sus prácticas.

Los 3 principios de cambio del método Kanban parece que nos indican que no debemos comenzar definiendo ni cambiando roles en una organización. Podemos empezar como están, dejando los cambios de roles y reuniones para aplicar en las organizaciones cuando ya estén trabajando en Kanban durante algún tiempo.

Pero ¿qué hacemos si la organización actualmente no dispone de un método de trabajo y unos roles claros para trabajar las primeras prácticas que queremos introducir?

Imaginemos que comenzamos a introducir prácticas como visualizar el trabajo del sistema, gestionar el flujo mediante los primeros eventos como la reunión diaria de Kanban y la reunión de reposición, y limitar el trabajo en curso.
Normalmente es el agile coach o experto en Kanban el que comienza facilitando y ayudando al equipo a realizar estas prácticas por un tiempo determinado. Durante este tiempo, el agile coach identifica aquellas personas dentro del sistema que ejercen las funciones habituales de los roles recomendados en Kanban: Service Request Manager y Service Delivery Manager.
A partir de cierto momento del proceso de evolución, el agile coach deja de realizar esas funciones y actividades delegando en las personas identificadas. Durante su acompañamiento debe realiza una formación a esas personas para que ejerzan las funciones de estos roles y vean cómo mejorar y evolucionar siguiendo los principios de Kanban.

Mediante este modelo de introducción de Kanban por etapas estamos siguiendo sus principios y ayudando a las personas en la evolución hacia este nuevo modo de trabajo de una forma menos agresiva que aplicar los cambios de un día para otro en el sistema, como es cambiar de roles y funciones a las personas y cambiar sus maneras de trabajar actuales desde el principio.

Para la introducción del método Kanban, en Enciende la Luz hemos definido un modelo de operación y acompañamiento a nuestros clientes basado en el modelo Kanban Maturity Model, mediante el cual vamos introduciendo las prácticas necesarias para comenzar con Kanban por parte del agile coach (modo push) e involucrando a las personas del sistema para evolucionar hacia prácticas Kanban de mejora del sistema (modo pull) fomentando el cambio evolutivo continuo.
Puedes saber más sobre Lean y Kanban en nuestra web o contactando con nosotros.

También te puede interesar.

Es importante usar Historias de Usuario

Usar Historias de Usuario es importante para los Product Owner, además de la más utilizada a la hora de escribir el Product Backlog.

Apoya a tu equipo entendiendo qué le ocurre

La transparencia es uno de los pilares de Scrum. Con ella conseguimos hacer visible lo que ocurre dentro del producto, equipo, personas, … para hacer inspección y adaptación. ¿Cómo podemos saber qué ocurre en el equipo para poder apoyarle?

Cómo convivir con las incidencias en un Equipo Scrum

En los Equipos Scrum que desarrollan nuevo software y mantienen el ya existente, es muy habitual tener que lidiar con incidencias provocadas por el software en producción. Su gestión es complicada ya que interrumpen directamente nuestro plan para el sprint, y al producto ya priorizado en el Product Backlog.

Entender a los Equipos Scrum desde las Métricas

En nuestro trabajo diario con los equipos Scrum, es importante entender qué está ocurriendo sprint a sprint, y en qué lugares debemos poner el foco de las acciones de mejora de los equipos. También es importante disponer de datos objetivos, que en las sesiones de retrospectiva o de revisión del proceso, nos ayuden a tomar decisiones basadas en la realidad, y no en sensaciones u opiniones subjetivas.

¿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.

La historia de scrum, su primera implementación

Actualmente Scrum es el marco de trabajo más utilizado para implementar modelos Agile. Hoy os contamos como era su primera versión.

Definition of Ready y Definition of Done

¿Qué necesitas para poder comenzar una tarea? ¿Cuándo podemos dar una tarea por terminada? Para resolver estas dudas, en este vídeo te traemos el Definition of Ready y el Definition of Done

En que punto del proceso consideramos el Producto como Entregable

Escoger dentro de nuestro proceso de generación de producto entregable el punto adecuado, puede ser muy complejo cuando dependemos de terceros.

El Product Owner: el desconocido y olvidado

Desde hace tiempo tengo la sensación que se desconoce la función de un Product Owner.

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.

0 comentarios

Enviar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

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

ACEPTAR
Aviso de cookies