featured

Upstream: Flujo de generación de opciones

En los artículos anteriores de esta serie dedicada a Lean Kanban hablamos de:

• ProtoKanban: Qué es y sus beneficios.
• Downstream, ¿cómo ir más allá de ProtoKanban?

En ellos vimos como, entre otros beneficios, el método Kanban puede ayudar a los equipos a aumentar la tasa de entrega, reducir lead times, y todo ello desminuyendo la sensación de sobrecarga.

Si no estás familiarizado con conceptos como WIP limit, lead times o tasas de entrega te aconsejo que les eches un ojo a los anteriores artículos antes de seguir leyendo.

Y en tu empresa…. ¿cómo se toman las decisiones?

Standish Group tiene una base de datos con más de 1.000 organizaciones y 50.000 proyectos. Todos los años publica el informe “CHAOS Report” dónde plasman sus conclusiones sobre como impactan en el éxito o fracaso de los proyectos diferentes factores, como pueden ser madurez de los equipos, metodología de trabajo, skills de los miembros del equipo, etc… En el último CHAOS Report nos contaron que el factor que más impacta en el fracaso o éxito en un proyecto es la latencia que existe a la hora de tomar decisiones. Según sus números, el 58% de los proyectos con buena latencia de toma de decisiones tienen éxito. Solo el 9% de los proyectos con mala latencia llegan a buen puerto.

Como agilista, me parece que tiene todo el sentido del mundo. Si la mentalidad Agile se basa en la aceptación de la incertidumbre y su manera de abrazarla es la continua adaptación, una empresa con más capacidad de tomar decisiones será más adaptativa, más ágil, y tiene más posibilidades de llevarse el gato al agua.

Siempre me ha llamado la atención que en muchas empresas de las que he visitado la decisión del qué hacer, ya sea en un producto o un servicio, se queda relegada a las personas más ocupadas de las empresas y se confía que casi en pocos minutos (y en su tiempo libre) sean capaces de tomar las decisiones acertadas. Y eso si tienen tiempo de reunirse, claro.

Inanición del downstream

Una consecuencia de no gestionar ni dar visibilidad a la generación de ideas, y que pasa en un altísimo porcentaje de implantaciones de Kanban, es lo que conocemos como el “downstream starvation” (inanición del downstream).

Una vez que nuestro flujo de ejecución o downstream comienza a trabajar con Lean Kanban, a gestionar su demanda y a tener las conversaciones correctas ayudados por la limitación del WIP, la mayoría de los tiempos de espera y cuellos de botella vienen por parte de los usuarios, los representantes del usuario en el equipo, o las personas de negocio (latencia en la toma de decisiones). En definitiva, las personas que deciden el “qué”. Esto empieza a provocar que el downstream se va quedando algo ocioso, o trabajando en tareas cuyo valor de negocio es bajo. Algo que no interesa económicamente a la empresa.

Kanban, ¡ayúdanos!

Kanban puede ayudarnos en toda la cadena de valor del servicio y, por supuesto, en el flujo de decisión de qué se va a hacer, o upstream.

Hasta ahora habíamos hablado sobre el downstream, pero si tiene sentido aliviar el downstream de la sensación de sobrecarga, ¿no tendrá sentido alivar de una sobrecarga similar a los trabajadores creativos de nuestro upstream, esos quienes deben descubrir los conceptos e ideas a implementar?

El upstream existe tanto en servicios como en productos. Y no te obliga a que el downstream deba ser gestionado con Kanban. Puedes trabajar con Kanban tu upstream y gestionar con Scrum, o cualquier otro método o framework la ejecución.

Visualizando y creando el flujo upstream

Lo primero que tenemos que hacer es visualizar cuál es nuestro flujo de upstream y como se relaciona con nuestro downstream. Algo como:

Además, limitaremos el WIP para crear un sistema pull.

Tasas de descarte

En el flujo downstream la tasa de descarte suele ser casi nula. Una vez que un elemento llega al punto de commitment del equipo (en este caso ready to start) la inmensa mayoría de elementos completarán el flujo conforme la capacidad del sistema lo vaya permitiendo.

Pero nuestro flujo upstream no debería comportarse de esta manera. En cada etapa de nuestro flujo de ideación, hay una oportunidad de descartar una mala idea: demasiada cara; tomará demasiado tiempo; o nuestros clientes no quieren ni necesitan esto.

Si todo lo que se te ocurre lo estás metiendo en tu producto o servicio, puede significar que no estás generando suficientes opciones para darte cuenta de las malas ideas y quedarte solo con lo que da más valor al usuario y, por lo tanto, más reveniew para tu empresa. Una buena gestión de opciones lleva asociada una tasa de descarte.

Acoplando upstream y downstream

Nuestro sistema downstream funciona con un flujo estable de tarjetas que viajan por los kanban que van quedando disponibles (recordad que en este caso los kanban son los huecos libres que nos dan la señal de que podemos acometer más trabajo). Trabajar con WIP Limit es lo que provoca justamente este flujo, ya que hace entrar en el sistema la misma cantidad que sale. Podemos verlo como una tubería perfectamente sellada dónde la misma cantidad de agua que entra, sale. El caudal existente en nuestro sistema vendrá regulado por el WIP limit.

Pero en el sistema upstream no tiene esta naturaleza. En él se descartan ideas por el camino. Es como una tubería con goteras entre las diferentes fases que puede tener ( necesidad detectada, análisis, diseño, etc… ).

¿Cómo podemos enfrentarnos a esta situación y prevenir que nuestro downstream se quede sin comida? Introduciendo en nuestro upstream un WIP mínimo o un número de opciones mínimas (además del WIP limit). De esta manera nos aseguramos que el caudal de nuestra tubería es lo suficientemente alto para contrarrestar las goteras, y dejar listos un mínimo de elementos de dónde el downstream pueda tirar.

Ahora tenemos dos palancas para jugar e intentar acoplar con éxito estos dos sistemas: las opciones mínimas del upstream y el WIP limit del downstream.

Conclusión

Implementar Lean Kanban en ejecución muchas veces es insuficiente de cara al usuario final. Lo importante es que el tiempo desde que se detecte una necesidad hasta que la solución esté implementada no se dilate. Para conseguir esto, debemos crear flujo tanto en la ideación (upstream) como en la ejecución (downstream).

Como nuestro flujo upstream debe tener una tasa de descarte, introducimos el nuevo concepto de “WIP mínimo” u “opciones mínimas” para asegurarnos de que el número de opciones que llegan a nuestro downstream son suficientes para mantener su flujo lleno.

Visualizar este flujo e imponer un mínimo de elementos activos puede ser una palanca que deje aflorar un posible problema de toma de decisiones dentro del proyecto. La exigencia del WIP mínimo muchas veces ayuda a los equipos de decisión, comités, etc… replantearse su estrategia de gestión.

El primer tablero Kanban del equipo

Desde la experiencia con varios equipos, hoy me gustaría hablarte de la evolución de un tablero Kanban concreto. Es cierto que las decisiones de unos equipos a otros no se parecen, ni las necesidades o su trabajo. Pero he vivido una serie de momentos que se repiten en el tiempo. Algo así como El día de la marmota para un Agilista

Podríamos llamarlo “los primeros escalones” cuando un equipo empieza a usar cualquier metodología, marco de trabajo o mentalidad Agile. Y el tablero es una de las herramientas más valiosas como comentaba en mi artículo anterior.

De menos a más

Todos empiezan con algo muy sencillo, normalmente por consejo del Scrum Master o el Agile Coach que les esté acompañando. Entonces, lo primero será visualizar el flujo de trabajo del equipo en cuestión. El equipo prepara un tablero y te enseña esto:

Ahora es cuando te toca hacer preguntas. ¿Solo tenéis 3 pasos en vuestro flujo?¿Quién pone esas tarjetas ahí?¿tienen orden alguno o prioridad?… pero voy a hablar de la primera para empezar.

Visualiza tu workflow o flujo de trabajo

Al principio los miembros de un equipo tienen oxidado este tipo de análisis. Porque no suelen analizar como trabajan, sino el trabajo en sí. Así que, a ti, que estás intentando ayudarles a crear un tablero Kanban útil, te costará muchas preguntas, algunos momentos incómodos, un poco de presión y mucha paciencia.

Tras una buena charla con todos los miembros del equipo, incluyendo siempre al Product Owner o Manager que tiene visión de negocio, se han añadido nuevas columnas. Ahora en algunos de los miembros del equipo puedes ver cierto brillo en los ojos, ¡incluso alguna sonrisa!. Esto se debe a que han tratado temas que les suelen doler, porque se atascan, donde no tienen mucho poder y ahora es visible. Así que el equipo trae esto:

Evitemos el caos

Ahora sabemos que hay más pasos en el flujo de trabajo. Pasos que son importantes porque se toman decisiones que no son solo técnicas, sino de negocio.

Al final muchos equipos deciden meter una columna de “Test” para la comprobación de que todo está como debería, pero pocas veces se trata de un test técnico. Es algo que al principio me sorprendía, ahora ya se que es uno de esos “primeros pasos”. Duele menos llamar así a la comprobación del Manager o el PO de que ese item es lo que ellos habían pedido.

Añadir WIP limits al tablero kanban

Como puedes observar, en el segundo tablero, hay mas columnas con el mismo número de tarjetas. Y casi todas las subtareas técnicas están en la columna “test” provocando de esta manera, un pequeño embudo que acumula tareas sin terminar. Por otro lado, todas las subtareas ya están en proceso o en test, pero algunas no se están avanzando. Toca sesión de preguntas incómodas de nuevo. ¿Esto es real? ¿se está trabajando en todas y cada una de las subtareas?

Si queremos que el tablero kanban sirva para algo y nos haga mejorar, hay que cambiar de mentalidad. Kanban nos ayuda a trabajar con una mentalidad pull y evitar el empezar mucho y acabar poco.

Hace unos días, mi compañero Nacho Navarro publicó un post interesante que te recomiendo acerca de elegir los WIP limit. Básicamente un WIP limit es un límite del trabajo activo que puede existir. Se puede limitar por columnas, por personas, el sistema completo, etc.. Por ejemplo, un equipo con 3 desarrolladores podrían decidir que no hubiera más de 3 tareas en curso en la columna “doing” a la vez. De esta forma nos asegurarnos de que creamos un sistema pull real.

Gestión del flujo de trabajo

Es importante que el mensaje de la mentalidad pull haya calado. En este tablero mejorado vimos muchos cambios:

Priorización de los elementos y sus tareas.
Orden para terminar más trabajo que antes.
Problemas de estancamiento o embudos.
Posibles necesidades de mejora para el tablero del equipo.
Métricas. Ahora podemos medir cuánto tardamos en entregar algo.

Políticas explícitas para usar bien el tablero

Esta vez, y solo para evitar tentaciones, hay que añadir las reglas del juego. Si queremos que esto funcione de verdad, necesitamos ser legales. Nada de decir que una tarea está “casi hecha” en la columna de “Done”.

Estas son una serie de requisitos que una subtarea debe cumplir si queremos pasarla a la siguiente columna. Si no los cumple, no está lista para pasar a la siguiente columna. Del mismo modo que si la columna siguiente tiene el WIP limit ocupado, tampoco puede pasar aunque las políticas se cumplan.

Esto nos ayuda a funcionar mejor con el sistema pull de Kanban. Así nos centramos en acabar el trabajo ya empezando en lugar de empezar otra tarea nueva. El equipo entendió que era necesario poner unas políticas explícitas en cada columna de paso. Así se aseguraban un mínimo en la nueva columna. El tablero quedó así:

Mejora continua de verdad

El último paso también es muy importante, ya que nos permite ir viendo estas evoluciones a lo largo del tiempo y los proyectos. Un ejemplo de ello es que en este último cambio, también añadieron algunas clases de servicios con diferentes colores en las tarjetas. Así se aseguraban que si alguna tenía fecha fija o era prioritaria, la vieran antes. Es necesario tomarse un tiempo de reflexión de todo el equipo en conjunto para tratar posibles mejoras.

Por supuesto esto es una versión reducida de un sistema que se puede complicar todo lo que necesitemos. Para ello podéis pasaros a leer la guía de Kanban que tenemos en la web, que es muy completa.

Espero que te sirva de inspiración este pequeño resumen en base a mi experiencia. En próximos post escribiré otros ejemplos, hablaremos de las tarjetas Kanban y de posibilidades dentro de un tablero kanban.

Cómo elegir un buen WIP Limit

El agilismo es una mentalidad, una manera de entender el desarrollo de software que cuando te sumerges te va salpicando poco a poco en muchos aspectos de la vida.

Cuando comenzaba en esto de las formaciones uno de los principios ágiles por los que pasaba rápidamente por encima era:

“Los procesos Ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.”

Cuando estuve ayudando a nuestros amigos de Product Hackers me tocó ponerme el gorro de Product Owner y este principio al que no le daba mucha importancia… se convirtió en mi preferido. Sólo en el momento en el que todas las piezas encajaron a nivel equipo, empresa, cliente, etc… y conseguimos un entorno de desarrollo sostenible y constante, empezamos a entregar valor de verdad y satisfacer las necesidades prioritarias de nuestros clientes una y otra vez creando una relación de confianza que nos permitió alcanzar grandes éxitos.

Wip limit: Creando el espacio

Una vez me hicieron la pregunta: “Si tenemos una capacidad máxima de delivery, ¿cómo que no limitamos la capacidad de entrada?”

Más o menos me quedé así:

Y es que…. ¿sirve de algo meter más trabajo del que va a salir en un sistema? Si tengo una depuradora de agua en mi piscina… ¿le intentaría meter más agua de la que es capaz de depurar para intentar depurar más? Si lo que quiero es pagar una gran factura de reparación y una mirada incrédula de un técnico de depuradora… entonces puede que sí.

Y es que limitar el WIP es precisamente lo que nos permite que nuestro sistema sea estable y constante en el tiempo. Es como una tubería donde solo entra caudal si sale.

WIP limit: La palanca magica

Hubo un señor que demostró la relación entre el número medio de clientes en una tienda, su frecuencia de llegada y el tiempo medio que pasaban en la tienda. Ahora estaréis pensando…¿y por qué me cuestas esta gran anécdota Nacho? Pues porque este señor se llamaba Little, y esta es la ley de Little y es la base de Kanban:

Como vemos, el WIP es la relación entre el lead time y el throughput rate o delivery rate. También podemos ver como afecta el WIP al lead time mirando un CFD (Cumulative Flow Diagram):

¿Cómo elegir mi WIP Limit?

La relación entre cuanto menos WIP menos lead time está clara con la ley de little o el CFD. Así que alguien puede pensar… ¡pues pongo 1 de WIP limit! Eso nos deja la paradoja del One piece flow dónde te aseguras que cuando una tarea entra en el sistema sale muy rápido, pero tu delivery rate se verá afectado y será muy bajo. ¿Esto es malo? ¿esto es bueno? Pues ni bueno… ni malo… en algunos entornos necesitarán un tiempo de respuesta muy rápido y no les importará tanto la tasa de entrega y en otros entornos necesitarán un equilibrio mayor.

En una de mis vidas pasadas colaboraba con un cliente muy tradicional dónde había una pequeña galia trabajando con Kanban y funcionando muy bien. Ellos querían poner en producción al menos una vez a la semana. Pero esta empresa solo permitía subir una vez al mes. En esta situación…. ¿un lead time de 1 o 2 días me ayuda? ¿O puedo pensar en abrir un poco el WIP, aumentar un poco el lead time, pero subir el delivery rate? La capacidad de absorción de nuestros clientes es un factor a tener en cuenta también.

Creo que este vídeo explica muy bien como puede ser una búsqueda de el WIP deseado (Nota: en el vídeo se habla de cycle time que es el tiempo que está la tarea desarrollándose. El Lead Time es el tiempo desde que me comprometo hasta que lo entrego. Como es de suponer, están estrechamente relacionados)

En definitiva, hay que encontrar un equilibrio entre el Lead Time y el Delivery Rate.

¿Cómo elijo mi primer WIP limit?

¿Cómo elijo ese primer WIP limit que mediré, inspeccionaré y adaptaré si aún no tengo métricas?. El primer WIP limit habrá que elegirlo según la experiencia de los miembros del equipo o con consejo externo. Lo importante es tener una mentalidad empírica para inspeccionar y adaptar así que tampoco me volvería loco eligiéndolo.

Una frase que a mi me sirvió: “El WIP limit debe doler”. Es una restricción. Muchas veces los equipos tienen a pensar… si somos 4… y cada uno puede con 2 o 3 cosas a la vez… ¡pues pongamos 10! Como ya he dicho antes este número no está ni bien ni mal. Habrá que medir, inspeccionar y adaptar si hace falta. Pero una primera elección que nos duela suele resultar más acertada la mayoría de las veces. Como probar uno por persona en todo el sistema. Pero como vimos antes, cada entorno es un mundo y persigue diferentes métricas.

¿Qué pasa si cambio el WIP limit?

Imaginemos que quieres bajar el Lead Time porque quieres ganar predictibilidad y poder asegurar un SLA más bajo. En ese momento decidís bajar el WIP limit. Ahora te tocará esperar a que el sistema se vacíe para ver como funciona. Es como si tienes una cisterna de 5 litros y la cambias a una de 3. No podrás ver como se comporta el nuevo sistema hasta que se vacíe y se llene de nuevo. Es un proceso que pasará de forma natural y no requiere ningún esfuerzo extra que no sea respetar vuestras reglas y paciencia.

Conclusiones

Limitar el WIP es un arma muy poderosa para crear un entorno sostenible. Siempre es difícil elegir el primer WIP, pero hay que acordarse de que:

Se puede cambiar en cualquier momento. Siempre que se esté persiguiendo la mejora del sistema y no una auto-trampa para eliminar una restricción que nos molesta.
Hay que tener en cuenta la capacidad de absorción de nuestros clientes
Es una restricción y como tal, la primera vez que lo estipulamos, es buena señal si nos duele.
Hay que mirar (al menos) nuestras métricas de Lead Time y de Throughput para ir equilibrando entre ellas cambiando nuestro WIP si fuera necesario.
Una vez cambiado el WIP Limit, el impacto no es inmediato.

Flujo downstream: Cómo ir más allá de Proto-Kanban

https://jeronimopalacios.com/kanban/Este es el segundo artículo de una serie dedicada a la introducción de Lean Kanban en organizaciones. Si no lo has hecho ya, es recomendable empezar leyendo Proto-Kanban: Qué es y sus beneficios donde hablé sobre como la visualización y una mentalidad pull podían ayudar a un equipo que está empezando en esto de Kanban.

¿Como ir más allá de Proto-Kanban?

Con Proto-Kanban hemos empezado a tener una mejor visualización de nuestro sistema y estamos empezando a gestionar trabajo y no personas. Pero aún estamos lejos de tener un flujo de trabajo real. ¿Cómo continuar?

Nuestra mentalidad pull nos ha ayudado a mejorar el lead time y la tasa de entrega. Pero esto no es suficiente. En nuestras formaciones vemos una y otra vez que existe una gran tendencia a hacernos auto-push y cuando la demanda crece, tenemos elementos con fecha fijada o urgentes, el acto reflejo es empezar a meter y meter trabajo en nuestro sistema colapsándolo.

Lo único que conseguirá sobrecargar un sistema por encima de su capacidad es tener mucho trabajo empezado y nada terminado. Esto es un desperdicio de tiempo y dinero, aumentará el lead time, disminuirá la capacidad de adaptación de nuestra empresa y de entregar a sus clientes lo que necesitan cuando lo necesitan.

Para crear un sistema pull completo vamos a utilizar algunas de las prácticas de Lean Kanban:

Limitar el WIP
Políticas explícitas
Clases de servicio
Feedback loops

Limitando el WIP (Work in Progress)

Llegó el momento de dar un paso más, ir de la mentalidad pull adquirida con Proto-Kanban a un sistema pull con trabajo limitado. Estableciendo WIP limits en nuestro sistema nos aseguramos que esa tentación de auto-push desaparece porque ahora nuestro sistema, sencillamente, no lo admite.

Establecer WIP limits no es más que limitar el trabajo en curso en nuestro sistema. Podemos poner un límite para todo el sistema (no puede haber más de 6 elementos empezados), podemos poner límites por columnas, por persona, podemos combinar todos, etc…

En la imagen podemos ver los WIP limits representados en la cabecera de cada columna por un número rodeado de un círculo.

Esta limitación permitirá al equipo:

Reducir aún más la sensación de sobrecarga
Focalizarse en lo realmente importante en ese momento
Entregar con mayor calidad

Esta calidad bajará drásticamente el número de elementos mal acabados que vuelven a entrar en el sistema (re-work), lo que impactará positivamente en el lead time, en la tasa de entrega y en lo más importante, la satisfacción del cliente.

Además, limitar el WIP nos permitirá crear un sistema sostenible en el tiempo ganando predictibilidad basado en datos y no en estimaciones u opiniones. Lead times medios, cycle times, etc…

En este post hablamos sobre qué hay que tener encuenta para elegir un buen WIP limit.

Haciendo las políticas explícitas

Hemos creado un flujo de trabajo pero… ¿cómo funciona? ¿quién mueve qué? ¿cómo se deciden las prioridades? ¡Las políticas explícitas acuden al rescate!

La selección de políticas debe hacerse por aquellos que son responsables de realizar el trabajo. Las políticas son variadas y de muchos tipos. Pueden existir políticas por columna (quien mueve que, como se deciden las prioridades), políticas para todo el sistema (cuando se hacen replenishments, como se revisan los ítems) o políticas por clase de servicio.

Las políticas deben estar visibles en todo momento. Algo que ayuda a los equipos a hacer explícitas las políticas es pensar que cualquier persona que pase por delante del tablón debe entender perfectamente como funciona el sistema al completo.

Es común en los equipos que están empezando intenten crear políticas nuevas que son más bien buenas intenciones que una política de funcionamiento. Esto desemboca en post-its gigantes con una norma que nadie está cumpliendo, generando frustración y la sensación de que la visualización puede ser algo que no es tan importante mantener. Es fundamental que el equipo entienda que las políticas:

Deben ser escasas
Simples
Estar bien definidas
Visibles
Las políticas no son un deseo, deben aplicarse siempre. Hay que ser realistas e inspeccionar si la estamos usando, si no, por qué no, etc…
Tienen que ser fácilmente modificables

Clases de servicio

Para poder gestionar el flujo correctamente es importante conocer el coste del retraso (cost of delay) de los elementos de trabajo. Debemos saber qué ítems son importantes, urgentes, con una fecha dada, etc… Kanban utiliza cuatro arquetipos para definir como cambia el valor del ítem de trabajo según su coste de retraso:

En la imagen podemos ver como evoluciona el coste del retraso o el impacto según pasa el tiempo.

Urgente: El coste del retraso crece y crece desde el primer día de forma lineal con una gran pendiente. Lo necesito, lo necesito ya y cada minuto cuenta.
Fecha fija: Al principio, el coste de retraso es bajo. Pero a partir de una fecha el coste de retraso es altísimo. Por ejemplo, si te piden una campaña de marketing para el blackfriday.
Estándar: Crece casi de forma lineal y constante en el tiempo. Suelen ser las más comunes en un sistema.
Intangible: Los ítems de clase intangible pueden ser importantes y valiosos, pero no hay costo de retraso tangible asociado con ellos en el futuro cercano.Lo que pasa con los ítems de esta clase es que un día estallan y el coste de retraso se dispara y se comportan como una urgente.

Pero cada sistema es un mundo y por tanto, el equipo debe encontrar las clases de servicio que mejor se ajusten a su sistema. Hay equipos que han llegado a definir una clase de servicio con el nombre de su CEO. Y una política asociada a esta clase de servicio que rezaba: “No empezaremos nunca un ítem de trabajo bajo esta clase de servicio hasta después de una semana”. Este CEO era especialista en pedir cosas muy urgentes y luego… arrepentirse. Como vemos, la combinación de clases de servicio y políticas es muy poderosa y nos permite gestionar perfectamente nuestro flujo.

Hay un comportamiento que nos encontramos muchas veces: “He empezado con este elemento de trabajo por qué me apetecía”. Las clases de servicio, junto a las políticas definidas, nos ayudan a eliminar la subjetividad y la procrastinación a la hora de elegir qué elemento de trabajo comenzar. La elección ahora tiene unas reglas objetivas que todo el equipo conoce, entiende y han establecido de mutuo acuerdo.

Feedback loops

El Agilismo se basa en el empiricismo por lo que no debemos olvidar los procesos de inspección y adaptación. Kanban define hasta siete cadencias con diferentes objetivos. Esto puede provocar rechazo por parte del equipo por la sensación de sobrecarga de reuniones. A nosotros nos da buen resultado empezar con la Daily Kanban y un Replenishment meeting semanal. Poco a poco, los equipos van teniendo necesidades que encajan con los objetivos de las otras cadencias y van sumándolas. Escribiré otro post para tratar exclusivamente de las cadencias.

¿Cómo podemos medir nuestro impacto?

Lo ideal es tener un histórico de métricas del equipo para poder comparar. Pero al menos, con Proto-Kanban ya deberíamos tener:

Lead time medio:Tiempo desde que nos comprometemos a tener una tarea hasta que la entregamos.
Cycle time medio: Tiempo que la tarea está desarrollándose.
Tasa de entrega: Cantidad de ítems entregados en unidad de tiempo.

Es importante medir, al menos, estas tres. A mi me gusta también introducir el customer lead time que es el tiempo desde que un ítem entra en nuestro backlog hasta que se entrega. Al fin y al cabo, al cliente le interesa cuanto tiempo tardas en entregarle la tarea desde que se la pide al equipo.

Nos hemos encontrado empresas con lead times muy bajos y muy orgullosos. Pero luego, cuando indagabas, encontrabas tasas de entregas bajísimas. Habían estado eliminando las tarjetas que llevaban en el sistema mucho tiempo. De esta manera “camuflaban” su lead time real. Pero la tasa de entrega no engañaba. ¿Sirve para algo medir y autoengañarse?

Conclusion

Una vez que tenemos Proto-Kanban funcionando es el momento de introducir más prácticas para crear y gestionar un flujo de trabajo:

Limitar el WIP
Políticas explícitas
Clases de servicio
Feedback loops

Debemos recordar que Kanban se ocupa del diseño, la gestión y la mejora de los sistemas de flujo. Conseguir un sistema estable en el tiempo es solo el primer paso. El equipo debe seguir mejorándolo continuamente por lo que hay que medir, inspeccionar y adaptar.

Si quieres profundizar más puedes leer nuestra guía de Kanban o el Kanban esencial condensado de David J. Anderson y Andy Carmichael

Continuar leyendo: Upstream, flujo de generación de opciones >>

Management 3.0 – ¿Por qué surge?

El pasado sábado 2 de junio tuve la suerte de participar en el evento AgilityTRes60, al que asistí tanto de oyente como de facilitador de una sesión de introducción a Management 3.0.

También estuve hablando sobre Management 3.0 los días 30 y 31 de mayo. En este caso, se trataba de una de las formaciones oficiales de 2 días que impartimos desde Jerónimo Palacios & Associates (Management 3.0 Two-Day Workshop).

¿Sabéis qué comparten principalmente ambas sesiones? Que pretendo asentar muy bien las bases, intentando que los asistentes entiendan:

Por qué utilizar nuevos modelos de gestión y liderazgo
Qué es Management 3.0
Cómo bajamos la teoría a la práctica

En este artículo os voy a hablar del por qué. Más adelante publicaré otros hablando de qué es Management 3.0 y cómo lo aterrizamos.

¿Por qué Management 3.0?

¿Cuántas veces el ser humano suele hacer algo porque está de moda? ¿Cuántas veces lo ejecuta de forma mecánica sin entender sus pilares y sobre qué se fundamentan?

Tanto cuando estoy haciendo co-training con Jero en algunas de nuestras formaciones, como cuando estoy trabajando con el resto de mis compañeros apoyando a nuestros clientes en sus procesos de transformación, me doy cuenta que la respuesta a las dos preguntas anteriores es “bastantes más veces de las que me gustaría”. Esto en gran parte se encuentra ligado al concepto de culto del cargamento del que ya hemos hablado en varias ocasiones.

Es por ello que siempre hago mucho hincapié y dedico muchas horas en entender yo primero, y ayudar a otros a entender más tarde, las razones por las que queremos introducir un cambio. En este caso cambio el enfoque de la pregunta de un “¿por qué?” a un “¿para qué?”.

En lo que respecta a Management 3.0, ¿por qué recibe este nombre? Esta pregunta es la que nos permite hablar de su nacimiento, del motivo por el cual surge este concepto. La razón es bastante simple. Hay dos versiones de management anteriores, la 1.0 y la 2.0. Vamos a ver por encima qué implican estos predecesores.

Management 1.0 – Las jerarquías

En la Primera Revolución Industrial ya se hablaba de producción en serie, cadena o masa. Estos términos alcanzaron su máximo esplendor tanto con Frederick W. Taylor, a través del Taylorismo, como con Henry Ford, a través del Fordismo.

Estos procesos de producción y la mayor parte de los marcos de gestión son desarrollados por ingenieros, caracterizándose por:

Gestionar la empresa como si se tratase de una máquina.
Especializar a los trabajadores.
Poner foco en la productividad.
Cronometrar el tiempo de las tareas.
Pagar incentivos por productividad/rendimiento.
Secuencializar el trabajo.
Introducir managers que se encargaban de la supervisión, organización y dirección del trabajo.

Además, se basan en:

Realizar un diseño por adelantado.
Planificar de forma descendiente.
Crear estructuras y procesos basados en orden y control.

Si pensamos detenidamente en los 10 puntos anteriores, diría que la clave está en la palabra “máquina”. Es entonces cuando todo tiene sentido, pues estos procesos funcionan bien cuando hablamos de máquinas, cuando nos referimos a cómo funcionan y el tipo de tareas que éstas realizan: tareas predecibles y repetibles.

El problema viene cuando hablamos de creatividad, innovación, conflictos, comportamientos, redes y relaciones, complejidad, seres humanos… Aquí, las reglas aplicadas a las máquinas se quedan excesivamente simples y no sirven para gestionar estos entornos.

Estos modelos a los que nos referimos bajo el concepto de Management 1.0, son probablemente los estilos de gestión más extendidos a día de hoy.

Management 2.0 – Las modas

Algunas personas se han dado cuenta que Management 1.0 no funciona bien out-of-the-box y que hay que introducir cambios. Surge Management 2.0.

Las organizaciones que se gestionan con esta versión de management, reconocen principalmente las siguientes afirmaciones:

Las personas son el activo más importante.
Los managers tienen que convertirse en “servant leaders”, o lo que es lo mismo, líderes que den servicio a la organización (como siempre digo, no confundir “dar servicio” con “ser siervos” o “servidumbre”).

Aunque las ideas anteriores suenan genial y resultan muy atractivas, seguimos encontrando grandes problemas en estas organizaciones. La explicación es sencilla: como solución al Management 1.0, lo que hemos hecho ha sido añadir una serie de complementos que se acoplan a la versión 1.0 out-of-the-box. Es por ello que, aunque sí se alivian los problemas, las estructuras, arquitecturas y jerarquías siguen siendo las mismas.

Me gusta destacar dos consecuencias que se producen al hacer un cambio de “look&feel” del Management 1.0 para tender hacia Management 2.0, que son:

A pesar de que los managers comprenden que la mejora de toda la organización no se logra simplemente a través de la suboptimización de sus partes, la gran mayoría prefiere mantenerse dentro de la jerarquía olvidando que las personas no suelen responder bien a modelos basados en orden y control con planificación descendiente.
Puesto que las estructuras, arquitecturas y jerarquías de la organización siguen siendo las mismas o prácticamente iguales, cuando la empresa o las personas que la conforman tienen un problema, una situación difícil, una crisis, tienden a hacer exactamente lo mismo que hacían inicialmente, vuelven a sus orígenes, aplicando reglas tradicionales del siglo XIX a situaciones complejas del siglo XXI.

Management 3.0 – La complejidad

Es un movimiento de innovación, liderazgo y gestión en el que se considera a las organizaciones como redes sociales complejas donde hay que gestionar los sistemas y no a las personas, encontrando juntos la forma más eficiente para que nuestra empresa logre sus objetivos, manteniendo la felicidad de sus trabajadores como una prioridad.

En próximos artículos trataré más detenidamente qué es Management 3.0 y cómo podemos aterrizar la teoría de forma práctica.

Resumen

A modo de resumen voy a hacer alusiones a la página de Management 3.0, ya que me gusta bastante cómo definen en pocas palabras cada una de las versiones de management que hemos visto:

1.0: hacer lo incorrecto, tratando a las personas como engranajes de un sistema.
2.0: hacer lo correcto de la manera incorrecta, con buenas intenciones, pero con iniciativas jerárquicas anticuadas de arriba hacia abajo.
3.0: hacer lo correcto de manera correcta, implicando a todos en la mejora del sistema y fomentando el compromiso de los empleados.

Nuestra formación

Si quieres formarte en Management 3.0, no dudes en consultar los próximos eventos en nuestra página o preguntarnos a través de la dirección de correo [email protected]. También puedes ver los comentarios de anteriores asistentes accediendo a este enlace.