Resultados de búsqueda de octubre 2020

Cómo mejorar la gestión de proyectos tecnológicos e industriales con Kanban y KMM – Introducción

Empresas tecnológicas, industriales o de servicios desean gestionar proyectos o desarrollar productos complejos de un modo que les permita:

  • Ver el progreso de los mismos al nivel de detalle que precisen
  • Decidir en qué conviene concentrar el esfuerzo entendiendo bien la demanda y la carga de trabajo actual
  • Reaccionar rápidamente a bloqueos y cambios
  • Gestionar eficazmente la coordinación entre equipos para reducir tiempos de espera
  • Tomar decisiones sobre la base de métricas
  • Hacer todo lo anterior sin perder el punto de vista del cliente

Han probado con equipos multidisciplinares para romper con los silos departamentales, han incorporado marcos de trabajo ágiles a nivel de equipo, también han desplegado herramientas colaborativas (Sharepoint, Teams, Confluence, …) y sienten que es preciso un salto de nivel para que los pequeños éxitos conseguidos con equipos aislados sean trasladables a toda la organización.

En ese momento descubren que el método Kanban y el Kanban Maturity Model son una alternativa a otros métodos de gestión de proyectos y desarrollo de productos, y que encajan en su perspectiva de cómo habría de ser ese salto:

  • Debe contar con la implicación de todos, miembros de equipos y directivos
  • Aquellos que hacen el trabajo son quienes han de decidir cómo mejorar su forma de trabajar
  • El cambio ha de hacerse de forma colaborativa, consensuada y poco a poco

La siguiente narración no difiere mucho de lo que encontramos (o esperamos encontrar) en empresas que han confiado en el método Kanban y el KMM.

 

Un escenario casi real

La empresa había decidido invertir en una nueva forma de gestión de proyectos basada en el método Kanban. En la reunión inicial con los consultores (Kanban coaches), habían quedado claras las causas de insatisfacción actual, y los objetivos iniciales que se perseguían.

Empezaron con sesiones de formación, luego vendrían sesiones de acompañamiento mientras cada área daba forma al diseño de sus sistemas Kanban, y trataban de integrarlos. El equipo interno de impulsores de la iniciativa había hecho un gran trabajo. 

Pasados ya nueve meses desde entonces, el comité directivo celebraba su reunión mensual por videoconferencia. Como siempre, la primera hora la dedicaban al seguimiento de la implantación de Kanban.

La directora general tomó la palabra y dijo:

—Llevamos ya varios meses desde que comenzamos con la iniciativa Kanban, ¿qué habéis observado desde nuestra última reunión? ¿Algún otro resultado positivo? ¿Qué dificultades nuevas han aparecido? ¿Cómo estamos lidiando con las dificultades previas?

Los directores de las distintas áreas se habían acostumbrado a estas preguntas. Al principio, los consultores externos facilitaban la reunión de seguimiento, informaban de los avances, y dejaban algunas preguntas abiertas a los miembros del comité, pero no tardaron en cambiar de formato. 

La iniciativa Kanban no era algo externo que unos cuantos consultores resolvían, era un proceso interno que implicaba a todos, por supuesto también a dirección, y debía tratarse como cualquier otra iniciativa: los miembros del comité tenían que evaluar los resultados que se estaban consiguiendo en sus respectivas áreas, cuáles eran los riesgos a que se enfrentaban y además ser conscientes de cómo esta iniciativa estaba cambiando comportamientos y relaciones internas.

El director de ingeniería respondió:

—Como suelo hacer, he charlado con mi gente para conocer de  primera mano sus impresiones. Me dicen que lo que más valoran es la gestión de las dependencias con otras áreas. Ahora pueden tomar decisiones más rápidamente. Si hay un trabajo que se está retrasando, sabemos qué causa el retraso y qué acciones tomar.

—Sí, como tenemos una visión del flujo extremo a extremo de los proyectos, los míos empiezan a tener clara la carga de trabajo actual y a configurar la demanda para comprometer plazos atendiendo a la capacidad disponible —añadió la directora comercial—. Eso ha limado muchas asperezas con el resto de áreas. Como se han empezado a medir tiempos de entrega [enlace a post Lead Time] esperamos poder responder a nuestros clientes con mayor confianza cuando nos preguntan para cuándo tendríamos listo el siguiente bloque de trabajo, pero aún no podemos hacerlo.

—En efecto —apostilló el director de compras— creo que la sensación general es que hemos recuperado el control de los proyectos, en vez de que la carga de trabajo nos controle a nosotros. A mí me piden soporte a menudo para que les ayude a eliminar algunos impedimentos en su flujo de trabajo. Aún hay dificultades, supongo que en mi área como en otras, hay equipos que han necesitado darle varias vueltas al diseño de sus sistemas Kanban hasta estar convencidos de que les permitía ver todo su trabajo y gestionarlo.

La directora general hizo entonces una observación:

—Tal como nos han dicho tantas veces nuestros Kanban coaches, se trata de hacer un cambio evolutivo y experimental. Sabíamos que los diseños de los flujos de trabajo debían emerger a partir de la gente que hace el trabajo, y eso lleva tiempo. 

» Por otra parte, es verdad es que estamos todos encantados de poder acceder de un vistazo el grado de avance de cada proyecto, y entrar en los detalles si es preciso. Precisamente, entremos en detalles, ¿cómo han evolucionado las políticas de gestión de dependencias entre áreas? ¿Y el trabajo que se estaba haciendo para consensuar los criterios de prioridad?

La reunión prosiguió y como resultado se actualizó el tablero de seguimiento con las observaciones realizadas, las acciones en curso y las que se acababan de proponer, más que suficientes para dar los siguientes pequeños pasos en su camino de evolución gestionada.

 

La narración anterior describe lo que podríamos escuchar en una reunión de seguimiento de la iniciativa Kanban por parte de Dirección, tras algunos meses de su puesta en marcha, y conviene destacar lo siguiente:

  • El equipo directivo al completo está fuertemente implicado en la iniciativa
  • La reunión tiene lugar con la estructura adecuada: observaciones realizadas, acciones llevadas a cabo, resultados conseguidos, dificultades encontradas, próximas acciones
  • No se dejan de lado las implicaciones de la iniciativa en la dimensión cultural: comportamientos y relaciones internas
  • Los propios responsables de áreas participan en resolver aquello que impide el flujo de trabajo
  • El cambio se entiende de forma evolutiva y experimental

Los responsables de tomar la decisión de poner en marcha una iniciativa de este calado quieren saber: en qué consiste lo que se propone, qué resultados pueden conseguirse y en qué plazo, y qué desafíos va a suponer una iniciativa así no sólo para equipos sino también para los directivos.

En los siguientes artículos de esta pequeña serie de 3 artículos pretendemos dar respuesta a estas inquietudes, tal cual lo hacemos como Kanban coaches cuando los responsables de una empresa solicitan nuestros servicios.

En el artículo siguiente [Gestión de proyectos y KMM: Diagnóstico y propuesta] explicaremos cómo identificar la situación de partida, y en qué consiste la propuesta de gestión de proyectos con el KMM. En el último artículo de esta serie [Gestión de proyectos y KMM: Los primeros pasos] describiremos cómo se pone en marcha una iniciativa de este tipo, qué resultados marcarse como objetivo, las prácticas que suelen plantearse, qué solemos encontrar una vez que todo está en marcha, resistencias que aparecen en la gente y los desafíos para los responsables.

 

Antonio Menchero Fernández
Accredited Kanban Trainer
Accredited Kanban Coach
www.berriprocess.com

Artículos relacionados:

¿Cómo y qué debo visualizar en mi tablero kanban?

Comenzamos repasando cuáles son las 6 prácticas generales de Kanban:

  1. Visualizar
  2. Limitar el trabajo en curso (WIP)
  3. Gestionar el flujo de trabajo
  4. Hacer las políticas explícitas
  5. Crear bucles/ciclos de feedback (reuniones)
  6. Mejorar y evolucionar

En este post vamos a centrarnos en la primera de las prácticas Kanban; visualizar. Te queremos explicar cómo y qué debes visualizar en tu tablero kanban a medida que la organización va evolucionando en función del nivel de madurez en el que se encuentre al inicio de su camino hacia la agilidad organizacional.

Prácticamente todas las empresas comienzan en un nivel 0-1 de madurez respecto al Kanban Maturity Model. Aquí puedes ver un pequeño esquema que resume cómo es la situación de las organizaciones en cada uno de los niveles:

Captura ML0 y ML1

En nivel de madurez 0 las personas usan sus propios tableros kanban, es decir, tableros personales. De esta forma centrándonos en la práctica que nos interesa, la práctica de visualizar, podemos ver que en este nivel es algo impensable. No se visualiza nada con el equipo. Cada persona se centra en su trabajo y visualiza ese trabajo individual en un tablero kanban personal en el que mediante tarjetas apuntan información básica relacionada con la tarea o elemento de trabajo que realiza. Un ejemplo de tablero kanban personal puede ser este:

Tablero ML0

 

Ya en el nivel 1, la organización empieza a enfocarse en el equipo. Se empieza a visualizar el trabajo de varias personas en un tablero kanban para que de un vistazo se sepa quién está trabajando en qué tareas y cuál es el estado de cada una de ellas. Un ejemplo de cómo se visualiza el trabajo mediante este sistema puede ser este tablero:

Ejemplo tablero ML1

Cuando el equipo ya está completamente habituado usando este tipo de tableros en el que se visualiza el trabajo de cada persona, se suele pasar a un tablero kanban de equipo en el que se usan avatares por cada persona que está trabajando en el equipo. Ya no se organiza el trabajo de cada persona por carriles, aquí se trabaja en equipo. De hecho, para que este sistema funcione, el equipo ya empieza a definir una serie de políticas básicas para que todos los integrantes del equipo sepan cómo actuar en cada momento. Puedes entenderlo con este ejemplo:

Tablero ML1

 

Si pasamos ya a un nivel de madurez superior, en el nivel 2 hablamos de una organización orientada al cliente. En este nivel, la organización ya gestiona el flujo de trabajo de principio a fin y por varios equipos.

Captura ML2

En este nivel lo más común es que ya se visualicen los tipos de trabajo por medio de colores en las tarjetas o bien carriles horizontales del tablero. En este nivel se comienza a visualizar las tareas o elementos de trabajo bloqueados (si los hubiera), así como los retrabajos que se deben realizar de nuevo. Con esa visualización lo que se consigue es poder conocer cuáles son las causas de esos bloqueos y retrabajos; algo realmente importante para que puedan evitarse y conocer los tiempos de resolución de esos problemas y así reducir los tiempos de entrega y asegurar el cumplimiento de los plazos.

También se visualiza el envejecimiento de los elementos de trabajo con el fin de saber cuánto tiempo lleva una tarjeta en cada fase del tablero, así como las dependencias que existen entre otros servicios o sistemas.

Cuando el equipo está listo para seguir avanzando empiezan a introducirse más prácticas generales como por ejemplo la de visualizar actividades concurrentes u opcionales por medio de casillas de verificación dentro de cada tarjeta. Cada vez hay más información en el tablero, lo que hace que todo sea muy visual y la transparencia aquí esté más que presente en el equipo.

Ejemplo tablero ML2

 

En un nivel superior como es el nivel 3 también conocido como “apta para su propósito”, la organización tiene el propósito claro, los niveles de servicio bien definidos y cumple con las expectativas de los clientes de forma sostenible. Aquí tienes un resumen de este nivel:

Captura ML3

Volviendo a la forma de visualizar el trabajo en este nivel, lo que necesita la organización es poder visualizar el flujo de trabajo y los elementos de trabajo o tareas por medio de un tablero kanban de equipos agregado, es decir, tener la visión completa. Se empiezan a visualizar también las distintas clases de servicio usando colores o decoraciones, como por ejemplo a través de pegatinas en las tarjetas. También se introduce la práctica de usar “parkings” para visualizar peticiones de trabajo en espera o bloqueadas que dependen de otro servicio o sistema. La organización en este punto es cuando empieza incluso a usar tableros kanban aguas arriba (de descubrimiento) para las ideas y opciones descartadas. Este puede ser un buen ejemplo de tablero:

Tablero ML3

Y por último para aquellos equipos ya consolidados en el nivel de madurez 3, se aprecia la evolución en cuanto a la forma de visualizar el trabajo puesto que ya son capaces de visualizar la capacidad disponible; visualizan lo que se puede arrastrar; visualizan ya la fecha objetivo de cada elemento de trabajo o tarea (ANS, Acuerdos de Nivel de Servicio). Por ejemplo, este puede ser un tablero de equipo agregado de nivel 3:

Tablero agregado ML3

 

Como verás la forma de visualizar va evolucionando poco a poco, y es el propio equipo y organización los que notan cuándo necesitan ir incorporando más prácticas para aumentar esa transparencia y colaboración. Al fin y al cabo, visualizar es eso, transparencia y colaboración entre el equipo y entre equipos.

¿Sabes ya cómo y qué debes visualizar en tu tablero Kanban?

Todas las prácticas a seguir están recogidas en el póster KMM – Mapa de prácticas. Puedes descargarlo gratis desde nuestra web haciendo click aquí.

 

Isabel Villanueva Izquierdo
Accredited Kanban Coach
www.berriprocess.com

Artículos relacionados:

 

Lead Time

—Entonces, ¿para cuándo tendréis lista la campaña? —dijo el cliente.
La responsable del departamento sumó mentalmente el tiempo que lleva hacer el briefing, la sesión de brainstorming, y la ejecución.
—En unas dos semanas —respondió.
—Bueno, espero que esta vez cumpláis —añadió el cliente.

Dos semanas después la campaña de marketing no estaba lista aún, el cliente había estado llamando insistentemente los últimos días, nervioso porque sospechaba que no iban a llegar a tiempo, creyendo que por mucho insistir podría forzar el cumplimiento del plazo previsto…

El resto de la historia seguro que podemos imaginarla: prisas, cambios de prioridad, esfuerzos extra, cansancio, falta de motivación, pérdida de confianza del cliente, etc. Desafortunadamente nada que nos sea demasiado ajeno, ¿verdad?

Definición de tiempo de entrega

Estamos acostumbrados a estimar el tiempo que nos llevará hacer un trabajo complejo sumando el tiempo que nos suele llevar cada una de las actividades necesarias para completarlo. Pero generalmente no incluimos los tiempos de espera, aquellos que tienen lugar, por ejemplo, porque hacemos varios trabajos a la vez y mientras estamos con uno no atendemos al resto, o porque quien puede hacer la actividad siguiente no está disponible para seguir.

Para colmo, comprometemos los plazos de entrega obviando o despreciando esos tiempos de espera, y luego nos asombramos de que no los cumplimos por más esfuerzo que pongamos de nuestra parte.

Sin embargo, cuando en Kanban nos piden responder a la pregunta “¿Para cuándo me lo tienes?”, contestamos con el tiempo de entrega. El tiempo de entrega (en inglés, Lead Time, aunque ciertos autores prefieren Cycle Time) se define como el tiempo que pasa desde que comprometemos la realización de la petición de un cliente hasta que se la entregamos terminada conforme a sus expectativas, y es la métrica de flujo por excelencia.

El tiempo de entrega de una petición incluye, por tanto, el tiempo que activamente estamos trabajando sobre esa petición pero además los tiempos de espera en que incurrimos. Bien pudiera ser, que la realización de una petición nos haya llevado 2 horas de trabajo activo, pero la hayamos entregado en 10 días, el tiempo de entrega es 10 días, aunque sólo hayamos dedicado 2 horas.

Registrando tiempos de entrega

Registrar tiempos de entrega es sencillo, basta anotar la fecha en que comprometemos la petición o elemento de trabajo (día de inicio) y la fecha en que lo terminamos (día de fin). La diferencia entre ambas es el tiempo de entrega (en número de días). Habitualmente sumamos 1 a la diferencia si consideramos días completos, asumiendo que empezamos a primera hora del día de inicio y acabamos a última hora del día de fin.

Desde la perspectiva del movimiento de las tarjetas en el tablero kanban, el tiempo de entrega empieza a contar desde que el elemento de trabajo pasa a la columna Comprometido (Punto de Compromiso), hasta que llega a la columna Prototipo Terminado (Figura 1).

Ilustración Tablero Kanban donde se reflejan Tiempo de entrega del sistema y tiempo de entrega del cliente
Figura 1

Por supuesto, lo anterior sigue siendo válido si la finalización del elemento de trabajo lleva horas y no días, en tal caso, el registro de la fecha incluye la hora y el tiempo de entrega se medirá en horas.

Si utilizamos una herramienta Kanban electrónica (como Kanbanize, la herramienta llevará el registro por nosotros, y además lo hará no solo de las fechas-horas de inicio y fin, sino también de las fechas-horas en que el elemento de trabajo entra o sale de cada columna del tablero que representa una actividad o cola.

Mejorar los tiempos de entrega

Es claro que los clientes quieren que sus peticiones sean entregadas lo antes posible, es decir, con un tiempo de entrega corto, pero es igualmente relevante para ellos que seamos fiables, es decir, que a la hora de contestar cuándo lo tendremos listo podamos dar un rango de tiempos de entrega estrecho.

Supongamos que el proveedor A nos dice “Me llevará terminarlo entre 5 y 20 días” y el proveedor B nos dice “Lo tendrás listo entre 7 y 9 días”, ¿qué proveedor elegimos?, ¿cuál resulta más fiable? Sin duda, el proveedor B es más fiable, aunque el proveedor A pueda terminarlo antes en algún caso, la confianza en que vaya a conseguirlo es menor.

Decimos que aspiramos a gestionar nuestro flujo de trabajo para que éste sea predecible y los tiempos de entrega suficientemente cortos. Una interpretación más formal de lo anterior, en términos de la distribución de tiempos de entrega.

Por otra parte, la Ley de Little nos revela lo qué podemos hacer para reducir nuestro tiempo de entrega: reducir el número de elementos de trabajo en curso, o dicho de otro modo, reducir el WIP (Work In Progress).

Interpretando diagramas de tiempos de entrega

El registro y posterior análisis de los tiempos de entrega nos servirá para entender qué tal lo estamos haciendo, ¿estamos entregando antes?, ¿somos más predecibles?; y también para pronosticar cuándo podremos entregar los nuevos compromisos.

Una forma de empezar el análisis es representar los tiempos de entrega en un diagrama de dispersión (en inglés, scatterplot). Revisando el diagrama de dispersión podemos ver patrones y tendencias que nos pueden sugerir cambios en las políticas con las que gestionamos el flujo de trabajo. En la Figura 2, se tiene un ejemplo de diagrama de dispersión, y en él podemos observar y cuestionarnos por ejemplo lo siguiente:
La forma triangular del diagrama implica que los tiempos de entrega están aumentando, ¿se debe esto a que la tasa de llegada de peticiones es mayor que la tasa de entrega, o se debe a que estamos pagando deuda de flujo?
Los elementos de trabajo con tiempos de entrega mayores, ¿son elementos que han envejecido innecesariamente en nuestro sistema?

Cycle Time ScatterplotFigura 2

En el margen derecho del diagrama de la Figura 2, se han señalado los percentiles. Por ejemplo, el percentil 85% corresponde con un tiempo de entrega de 93 días, lo que significa que en el 85% de los casos, las peticiones se entregan en 93 días o menos. Esta conclusión ya nos permite avanzar una respuesta al cliente cuando nos pregunte para cuándo tendremos listas sus próximas peticiones.

Otro diagrama interesante es el histograma de frecuencias absolutas de tiempos de entrega (Figura 3) que nos da una idea de la forma de la distribución de los tiempos de entrega. En este tipo de diagrama podemos analizar cómo es la cola de la distribución, la dispersión de la distribución, si ésta es o no multimodal, y a partir de ahí identificar categorías de elementos de trabajo (tipos de trabajo) o razonar sobre las Clases de Servicio. Al igual que en el diagrama de dispersión, también podemos representar los percentiles sobre el histograma.

Cycle Time HistogramaFigura 3

El tiempo de entrega desde el punto de vista del cliente

La definición de tiempo de entrega dada más arriba corresponde a lo que se conoce en Kanban como Tiempo de entrega del sistema, refiriéndonos al sistema de gestión del flujo de trabajo considerado, que empieza en el punto de compromiso y termina en la primera cola sin limitación del WIP que en la Figura 1 es la columna “Prototipo Terminado».

No obstante, desde la perspectiva del cliente, el tiempo empieza a contar desde el momento en que él hace la petición y ésta empieza a prepararse (columna “Preparación”) y termina cuando ésta es entregada (columna “Entregado”), y posiblemente incluye una etapa de validación del ciente después de “Prototipo Terminado” (ver Figura 1).

A este otro tiempo de entrega se le conoce por Tiempo de entrega del Cliente (en inglés, Customer lead time).

Relación con otras métricas

La relación entre el tiempo de entrega y otras métricas de flujo, como la tasa de entrega y el WIP queda establecida en la Ley de Little [enlace a postLey de Little y sistemas Kanban] y puede verse reflejada gráficamente en los Diagramas de Flujo Acumulativo (en inglés, CFD, Cumulative Flow Diagram).

Es interesante además tener presente que la Eficiencia de Flujo (en inglés, Flow Efficiency) se define como la razón del Tiempo de trabajo activo (en inglés, Touch time) y el Tiempo de entrega. Si calculamos este cociente para cierto proceso, ponemos en evidencia las ineficiencias del flujo de trabajo que llevan necesariamente a inútiles tiempos de espera.

La eficiencia de flujo nos da una perspectiva de cómo mejorar la gestión del trabajo poniendo el foco en el cliente, algo bien distinto a lo que resulta del enfoque en la eficiencia de recursos.

 

Antonio Menchero Fernández
Accredited Kanban Trainer
Accredited Kanban Coach
www.berriprocess.com

Artículos relacionados:

Niveles de Madurez Organizacional (KMM) – Nivel de Madurez 0 y 1

Seguro que has oído hablar del Kanban Maturity Model, también conocido como KMM, pero si todavía no lo conoces, no te preocupes. Vamos a preparar una serie de posts relacionados donde explicaremos de uno en uno cada uno de los niveles de madurez por los que las empresas escalan hasta llegar a convertirse en una organización “apta para su propósito”.

El KMM fue creado gracias a la experiencia de más de 10 años de sus creadores, Teodora Bozheva y David J. Anderson trabajando en distintas organizaciones de diversos sectores y países. En él se reúnen las prácticas más relevantes por las que se pueden guiar las organizaciones para conseguir mejoras, cumplir con las expectativas de los clientes, evitar y resolver desafíos como la resistencia al cambio, proponerse objetivos demasiado ambiciosos o no saber cómo seguir avanzando en su camino hacia la agilidad.

Consta de 7 niveles de madurez en total. El primero de ellos, es el nivel 0 conocido como “inconsciente” en el que las personas de la organización están centradas únicamente en sus tareas personales, no hay visión de equipo. También en este nivel se aprecia que siempre hay personas con conocimientos muy específicos que no suelen compartir con los demás lo que saben, puesto que se encuentran centrados en que su trabajo salga. No saben que tienen que entender el proceso. Pero no nos vamos a centrar en explicar este nivel 0 dado que nos interesa avanzar más allá de este nivel.

ML0: a mi manera

Pasamos al nivel 1 desde donde en la gran mayoría de organizaciones empiezan, conocido como “enfocada en equipo”. Según el último informe anual de KPMG “Agile Transformation From Agile experiments to operating model transformation” 2019, podemos destacar que el 74% de los encuestados aplican Agile en su organización a nivel de equipos; viendo muy lejos aplicarlo a nivel de toda la organización.

En el nivel 1 hablamos ya de tareas de equipo, aunque bien es cierto que aún no existe la cultura de colaboración plena. Se utiliza ya en este nivel un tablero kanban de equipo donde se visualizan las tareas de cada persona para que exista ese principio de transparencia y que ésta facilite la colaboración. En este nivel casi siempre hay alguien que “tira del carro” como puede ser un Team Leader o responsable.

Por norma general el objetivo principal de este nivel será el de crear un entendimiento común de que no consiste en empezar trabajo, puesto que si empezamos sin terminar el sistema se colapsa, es por eso por lo que se empieza a usar avatares que señalen el trabajo de cada persona, se marcan límites WIP (Work In Progress) tanto por persona como por equipo, se empiecen a visualizar políticas iniciales para que todos los miembros del equipo sepan cómo actuar ante cualquier imprevisto o cambio de prioridades, y se comienzan a usar algunas métricas que por el momento, medirán solo a las personas y sus trabajos (métricas de gestión del flujo de trabajo, bloqueos, cuando se empieza un trabajo, cuando se termina…).

En cuanto a las reuniones que se suelen realizar en este nivel son la Reunión Kanban de Equipo diaria, informal y “de pie” en la que hablar de los problemas que existen para continuar con algo esa misma mañana, o bien algún cambio de prioridad por la entrada de una urgencia; y por otro lado la Reunión de Reposición a nivel de Equipo en la que se habla de las tareas que pueden entrar en el tablero una vez a la semana y cuáles tienen problemas; se trata de revisar y realimentar el tablero para que el equipo tenga el trabajo bien definido.

En este nivel también suele suceder que se empiece a pensar en las expectativas del cliente, algo realmente interesante. Por último, resulta indispensable que el Middle/Senior Level Management se implique para continuar en el camino hacia la agilidad y seguir así con las prácticas recomendadas para poder pasar al nivel 2 conocido como “orientada al cliente”.

ML1: equipos desconectado

¿Quieres seguir conociendo los niveles de madurez?

En otro post te explicaremos el siguiente nivel 2 de madurez “orientada al cliente”. Síguenos en redes sociales para que no te pierdas las nuevas publicaciones.

 

Isabel Villanueva Izquierdo
Accredited Kanban Coach
www.berriprocess.com

Artículos relacionados: