¿Hay ejemplos de aplicación de límites WIP en nuestra vida cotidiana?

Estamos rodeados de sistemas Kanban y muchas veces no somos conscientes de ello. Recordemos que Kanban es un sistema de mejora de procesos basado en un sistema de arrastre con restricciones al trabajo en curso (Work In Process) y con visualización del flujo.

El trabajo en curso o WIP es una de las mudas o desperdicios de Lean Thinking, de por sí no aporta valor, retrasa el retorno de la inversión, oculta defectos, reduce la transparencia... La limitación de los niveles WIP expone las debilidades como son las ineficiencias del proceso, cosa muy deseable porque permite la mejora continua y optimizar el flujo ajustando el trabajo a la capacidad.

Unos niños juegan en Ikea, foto cortesía de teinteresa.es

La guardería de niños en el IKEA opera con un sistema Kanban con límte WIP; tenemos la puerta de entrada que representa el estado "pendiente", la zona de juegos que es el estado "en curso" y que está limitado por WIP, y finalmente la puerta de salida que es el estado "hecho".

La capacidad de un monitor para vigilar es de 10 niños, no más. Para no superar la capacidad del equipo de monitores hay una pared con chalecos, según el centro 30 o 50. Los chalecos son el límite WIP, cuando no quedan chalecos no pueden entrar más niños hasta que no salga alguno, de esta manera se asegura no superar la capacidad de los monitores ni por equivocación ni por influencia externa.

IKEA también limita el tiempo de ciclo; los niños están limitados a 1 hora en la guardería y para ello los padres reciben un intercomunicador para estar comunicados y ser avisados a tiempo.

El tráfico fluye después de un accidente - cortesía de Pixabay

Un accidente en la autopista a una hora punta que anula un solo carril.

En esta situación se reduce el número de carriles en el tramo del accidente, reduciendo de esta manera el limite WIP. Si recordamos experiencia pasadas nos daremos cuenta que una vez pasado el accidente la autopista se vuelve fluida como no es habitual a esa hora.

Los embotellamientos y atascos se producen sobre el 80% de la capacidad de las autopistas, si la autopista está por encima, anular un carril en un tramo reajusta el tráfico por debajo del 80% de capacidad, y eso hace que vuelva haber flujo. Aunque sea contraintuitivo, un accidente puede reducir el tiempo de ciclo de nuestro viaje, el tiempo desde que nos incorporamos a la autopista hasta que salimos de la misma.

Starbucks opera con Kanban
Cortesía de Pixabay

El Starbucks es un gran ejemplo de un sistema Kanban limitado por WIP.

Podemos distinguir 5 estados en el proceso, dos de ellos limitados en WIP.

1. La cola para ser atendido ante el área de cajeros representa el estado "pendiente".

"Post-it" en el Kanban de Starkucks
Cortesía de Pixabay

2. Clientes atendidos en alguna caja representan el estado "haciendo pedido". Aquí el cliente pide su café, el cajero anota el nombre y el tipo de café en el vaso, que es el elemento que recorre el flujo (similar a como lo hacen los post-its en los tableros Kanban de TI). Notemos que en este estado hay un límite WIP intrínseco determinado por el número de cajas abiertas.

3. Entre las cajas y la zona de preparación del café hay un buffer, una estado de "espera" donde el cajero coloca los vasos de café y de la que el barista recoge los siguientes pedidos cuando haya acabado con los actuales. Hay locales en los que esta zona tiene unos huecos redondos para colocar los vasos y que funciona a modo de límite WIP. Si todos los huecos están ocupados el cajero no puede colocar más pedidos. No siempre hay estos huecos, aunque el cajero sabe muy bien cuantos vasos puede haber en ese buffer, y, si exceden el límite WIP, este baja su ritmo y ofrece otros productos al cliente hasta que se libera la zona de espera.

Zona de preparación del barista "en curso"

4. El barista, un el profesional especializado en el café de alta calidad, toma los vasos y los lleva a la zona de preparación, el estado "en curso", y prepara a la vez siempre una cantidad de pedidos ajustada a su capacidad. Otro aspecto interesante relacionado con Kanban son los dosificadores de jarabes, cremas y caramelo, los vemos en la imagen de la derecha; son un auténtico poka-yoke ya que son de presión y dan la cantidad exacta de producto sin posibilidad de error.

5. Finalmente el barista llama por el nombre al cliente y coloca el vaso con el café finalizado en un mostrador que representa el estado "hecho".

Cajero enviado a ayudar en cocina para limitar el WIP de
entrada de pedidos - cortesía de freeimages

Los burgers también utilizan Kanban para gestionar su flujo, y lo hacen de manera muy similar a como lo hace Starbucks.

¿Alguna vez habéis estado haciendo cola en las cajas de Burger King, hay mucha gente y aparece un supervisor y manda cerrar una caja y al cajero a ayudar a la cocina?

Lo que está ocurriendo en ese momento es que la cocina esta desbordada, habiéndose convertido en un cuello de botella que está ralentizando el flujo. Cerrando una de las cajas el supervisor reduce el WIP de entrada, con lo que los pedidos se ajustan a la capacidad de la cocina y esta se desatasca. La posible ayuda del cajero en la cocina carece de importancia, su ayuda incrementará la capacidad de forma mínima, lo importante es la limitación en la entrada de pedidos.

¿Cómo afecta Scrum a los costes y a la productividad?

Una de los temas que más debate suscitan, tanto en mi trabajo como coach ágil como en mis clases, son los costes y la productividad. Aunque todo el mundo acabe comprendiendo que con Scrum podemos obtener un producto que es una mejor solución a las necesidades del cliente, suele haber la convicción que los costes en proyectos en cascada están mejor gestionados y optimizados, y que en las empresas en las que trabajamos los proyectos están muy claros... me suelo reír para mis adentros porque los que más convencidos están de ello son los que más se quejan de negocio y de los requisitos incompletos y cambiantes.

Para poder dar respuesta a esta cuestión de forma ilustrativa y visual he preparado dos gráficos que comparan ambas situaciones, en ellos se muestran las diferencias en costes y productividad.

Construcción de un producto en base a proyectos cerrados con concurso entre proveedores

En este primer gráfico se muestra como ocurren los proyectos en el tiempo, suelen ocurrir de forma discontinua con un tiempo de espera en medio, espera para el concurso entre proveedores y la contratación. Las construcción se alimenta de un alcance definido independiente para cada proyecto.

Se pueden identificar tres tipos de costes:

• Coste de Transporte (CoT): representa el coste de la puesta en marcha del equipo, la constitución de entorno y recursos y la transferencia de conocimiento necesaria al equipo. Jefes de proyecto, consultores y en general profesionales de TI coinciden en que los equipos no están rodando y no son eficientes hasta entre 3 y 6 meses desde el inicio de proyecto.
• Coste del Mantenimiento (CoM): representa el coste de mantener a un equipo en su fase productiva, representa las nóminas del equipo más los costes de recursos que consumen.
• Coste de la Demora (CoD): representa el coste del retraso por no construir funcionalidades durante el tiempo de espera entre proyectos. En este periodo las compañías pierden beneficios y competitividad, su time-to-market está afectado perdiendo capacidad de adaptación al mercado y de aprovechamiento de oportunidades emergentes, oportunidades que se desvanecen rápidamente en el tiempo.

La productividad sigue un patrón de crecimiento lento desde el inicio del proyecto hasta la madurez del equipo, seguido de una fase de productividad máxima hasta la fecha de entrega, y finalmente un decrecimiento acelerado en la fase de estabilización y resolución de incidencias.

Podemos observar que únicamente el coste de mantenimiento tiene relación con la productividad, los demás costes son desperdicio desde el punto de vista de valor de negocio.

Construcción de un producto de forma iterativa e incremental con Scrum

En este gráfico con Scrum la construcción se alimenta de una pila de producto viva priorizada por valor de negocio y que siempre está alineada con las necesidades emergentes y cambiantes del mercado (véase como funcionan los conos de incertidumbre en las dos formas de gestión). El tamaño de la pila de producto puede estar alimentado a su vez por proyectos que amplían la visión y la financiación.

Como podemos observar, con continuidad de los equipos, la productividad se mantiene en su nivel máximo de forma continua y sostenible mientras el producto esté vivo y haya presupuesto. La única excepción con desperdicio está en el coste de transporte en la fase de maduración del equipo.

¿La igualdad de género debería de ser uno de los valores de la Agilidad?

Cada vez que doy clases de Scrum o Kanban en el Centro de Novas Tecnoloxías de Galicia, mis alumnos tienen que haber pasado por el módulo de igualdad para poder certificarse, y eso me ha hecho pensar... que tiene mucho sentido.

No, la igualdad de género no debe de figurar entre los valores de la Agilidad, debe de formar parte de cualquier cultura y estar muy interiorizada en sus valores. Scrum no puede funcionar sin la igualdad de género. Por desgracia en nuestra realidad empresarial actual, y también en la de la sociedad, las cosas no son siempre así. He visto en alguna compañía que del grupo de directivos la más inteligente es una mujer, y sin embargo su impacto sobre la toma de decisiones es mínimo, en algunos casos no es ni escuchada. Rohini Anand, Chief Diversity Officer de Sodexo, nos dice que:

Todos los indicadores de beneficios, tanto los financieros como los relativos a la permanencia de clientes o percepción de la marca aumentan cuando existe equilibrio de género en la dirección

No solo puede ser más complicada la igualdad en los puestos directivos, sino también en el liderazgo de equipos. Una mujer frente a un equipo de desarrollo o de mantenimiento no siempre lo tiene igual de fácil que un hombre, se juzga todo por el simple hecho de ser una mujer, sin siquiera dar la oportunidad de demostrar su valía o pensar que ha llegado a ese puesto por alguna circunstancia que tener unos atributos femeninos excepcionales, aunque tengo que decir que en mi experiencia su inteligencia emocional hace maravillas.

El "pollino" con el que Vero se ha ganado a su equipo

Estuve hablando hace poco con Vero, una help desk manager y amiga mía ;-) que me explicaba cómo se había ganado a su equipo. Dio cuerda al "pollino", el que vemos en la imagen de la derecha, y lo soltó en la mesa ante todos sus compañeros. La incredulidad inicial y las risas que siguieron crearon y reforzaron un ambiente de team-building que ha llevado a ese equipo a ser uno de los más productivos de la compañía.

Desde mi perspectiva un gran beneficio de la igualdad de género es el reforzamiento de la dimensión humana, dimensión necesaria en Agilidad y en todo trabajo creativo y motivante, reforzamiento muy necesario en algunas compañías impregnadas de la seriedad del mando y control.

Acabo el post con una expresión italiana de Leonardo Sciascia que me encanta:

Niente senza gioia

o mejor nuestra versión:

Niente senza una donna

Mis agradecimientos a las coautoras del post, a Vero y a Julia, por sus aportaciones y repaso :-D

¿La experiencia de un jefe de proyecto sirve como Scrum Master?

Entrevista a un jefe de proyecto posible Scrum Master
Cortesía de Pixabay

Me comentaba Elena, la responsable de selección de personal, que algunos jefes de proyecto que optan por puestos de Scrum Master argumentan que con los años de experiencia como jefes de proyecto pueden ejercer perfectamente el rol de Scrum Master… Según como, probablemente sea todo lo contrario, en Scrum no existe el rol de jefe de proyecto y estos tienden a ser una interferencia, e incluso un impedimento, porque no tienen ninguna responsabilidad de la que hacerse cargo.

Hay que comprender la diferencia entre un consultor, un jefe de proyecto, y un coach de equipos, un Scrum Master. Las tareas de un Scrum Master son muy distintas a las de un jefe de proyecto. La autoridad del Scrum Master se extiende únicamente al proceso de Scrum y busca hacer emerger al mejor equipo posible, no en gestionar al equipo.

Para transicionar de un rol al otro es necesario desaprender para aprender algo totalmente distinto. Muchas de las aptitudes aprendidas por un jefe de proyecto pueden aportar, pero su perspectiva y la aplicación de las mismas es radicalmente opuesta.

Un jefe de proyecto gestiona personas a las que distribuye trabajo, un Scrum Master acompaña al equipo para que encuentre su propio camino y aprenda a gestionar su trabajo de forma autoorganizada.

Para seleccionar un jefe proyecto adecuado para transicionar a Scrum Master hemos de fijarnos primero en sus habilidades sociales, habilidades denominadas "blandas", las más orientadas a la personas, vinculadas más a la escucha activa, la negociación win-win, la comunicación y la motivación de los miembros del equipo.

Cuando preguntamos a los desarrolladores por el mejor jefe de proyecto que jamás hayan tenido, suelen hablar de un jefe que les ha dado libertad, que les escuchaba, les apoyaba y les aislaba de las interferencias externas. Ese es el tipo de jefe de proyecto que puede ser un buen Scrum Master.

Podemos distinguir este tipo de personas con la metáfora utilizada en la selección de personal en recursos humanos, "t-shaped person", persona tipo T, que describe las habilidades de las personas de la compañía. La vertical en la T representa la profundidad de las habilidades relacionadas y la experiencia en el campo especialista de la persona, y la horizontal la capacidad de colaborar en otras disciplinas con expertos en otras áreas y aplicar el conocimiento en áreas de experiencia que no sean propias.

Una forma que funciona muy bien para identificar candidatos es preguntar al entrevistado cuales han sido sus principales problemas con sus equipos. Si nos habla de un producto de baja calidad, de problemas de tecnología, de incumplimiento de planes y de estimaciones, es señal de un gestor implicado, si nos habla de miembros de equipo, sus conflictos y preocupaciones, de cómo hizo crecer a los junior y como mejoró la comunicación entre los miembros, entonces se trata de un buen desarrollador de personas, en definitiva de un buen candidato para Scrum Master.

Ha de estar abierto a aprender a distanciarse del equipo, darles aire y autonomía de forma gradual para hacer crecer al equipo y para que encuentre su propio camino y aprenda a autoorganizarse.

Demanda de empleo de un rol malentendido

Scrum implica una forma diferente de trabajar y de pensar, un forma diferente de entender el liderazgo que requiere una mentalidad diferente a la tradicional. Ser jefe no significa necesariamente ser líder, y no olvidemos que el liderazgo estructural simplemente es ejercicio del poder. Es absolutamente necesario que el nuevo Scrum Master conozca las reglas y la mentalidad de Scrum, por tanto si no es así hay que formarlo.

Aún así no se puede garantizar que su transición sea un éxito, el sistema que le rodee tiene que acompañarle y jugar con las mismas reglas, las de Scrum. Si consideramos como sistema a la cultura empresarial que nos rodea, la transformación ágil está gateando sus primeros pasos, ejemplo de ello son las numerosas demandas de empleo como las de la imagen de la derecha más arriba (incluso he llegado a ver una que demandaba un Scrum Master - jefe de proyecto - junior). Igual que habrá empresas que no sobrevivirán a la transformación ágil, habrá jefes de proyecto que no encontrarán su lugar como tales en el mundo que se avecina.

Mis agradecimientos a Elena por este debate tan interesante que tuvimos.

¿Por qué la Agilidad da tanta importancia a la comunicación cara a cara?

Conversando cara a cara - cortesía de Pixabay

La comunicación es un elemento fundamental para lograr proyectos y productos exitosos, seguramente coincidiríamos en la afirmación de que muchos proyectos fallan por la falta de comunicación. Este es uno de los puntos que promueve Scrum, y también el Manifiesto Ágil con el sexto principio:

El método más eficiente y efectivo
de comunicar información al
equipo de desarrollo y entre sus miembros es la
conversación cara a cara

Primero resaltar que "cara a cara" se refiere a la comunicación o conversación sincrona en la que todas la partes están presentes para comunicarse, a diferencia de la comunicación asincrona que sería el caso del correo electrónico o a través de documentos escritos. "Cara a cara" no se refiere tanto a presencial o colocalizado, con una buena infraestructura de videoconferencia y en un entorno de confianza el "cara a cara" puede funcionar perfectamente.

Por ejemplo si un miembro de equipo lee la palabra "mediador" en un contexto de una compañía de seguros, probablemente lo relacionará con los procesos de mediación en los juzgados y podría concluir que estos toman importancia cuando ocurren denuncias. Resulta que un mediador en el contexto de seguros es un agente de seguros, y habiendo ocurrido un malentendido, este puede provocar decisiones equivocadas que afecten de forma más o menos grave en un futuro. Si un Propietario del Producto explica sus necesidades y menciona la palabra "mediador" y hay malentendido, probablemente leerá en las expresiones del interlocutor que algo no va bien, uno de los dos preguntará y el malentendido estará reconducido en 3 segundos.

Comunicar es compartir una información de forma tanto racional como emocional, poniendo el contenido realmente en común, llegando a consenso y alineamiento en su significado y valoración. Eso solo se consigue plenamente si está presente el lenguaje no verbal, cuando la conversación es "cara a cara" y de esta manera provee mucha más información.

Cuando conversamos, sólo una pequeña parte de la información que obtenemos de quién tiene la palabra, procede de sus palabras. El psicólogo Albert Mehrabian, actualmente profesor emérito en UCLA, llevó a cabo experimentos de comunicación entre personas y llegó a la conclusión que en una conversación "cara a cara" entre el sesenta y el setenta por ciento de lo que comunicamos lo hacemos mediante el lenguaje no verbal: tonos de voz, gestos, apariencia, postura, mirada y expresión.

En mis clases suelo comparar la comunicación "cara a cara" con solo palabras como el email como cuando caminamos por la acera y vamos en coche. En caso de conflicto si estamos en el coche nos solemos enfadar y no reprimir nuestras palabras, en cambio si chocamos o rozamos con alguien en la acera cruzamos miradas y solemos pedirnos perdón mutuamente.

La colaboración y comunicación "cara a cara" entre el equipo, Propietario del Producto e interesados:

• permite detectar malentendidos en cuestión de segundos
• permite preguntar en ese mismo momento
• permite re-preguntar
• permite pedir un ejemplo si no ha quedado claro
• permite dar y recibir feedback al momento y a tiempo

David, un Propietario del Producto con el que trabajé, decía que "con sólo ver la cara del líder del equipo en la reunión diaria sé perfectamente la situación del proyecto". Y su experiencia fue con un equipo que, en vez de recibir tareas para construir funcionalidades, participó en cocrear soluciones a necesidades de negocio.

Factores del lenguaje no verbal que son cruciales para una buena comunicación:

• Paralenguaje: el volumen, tono o velocidad de nuestra voz revela importante información, especialmente cuando intentamos ocultar nuestras emociones.
• Expresiones faciales: es un lenguaje universal de la naturaleza humana que leemos en fracciones de segundo, indican nuestras emociones: alegría, sorpresa, tristeza, miedo, ira, asco y desprecio.
• Gestos: tienen un elevado componente cultural, los hay ilustradores que construyen credibilidad, los hay que muestran el afecto y los sentimientos, otros no requieren de palabras...
• Posturas: expresan básicamente el grado de interés y apertura hacia los demás, transmiten confianza, estabilidad y seguridad.

¿Cómo debe tratarse un cambio de funcionalidad en medio de la ejecución de un sprint?

... el Propietario del Producto avisa al Scrum Master, o directamente al equipo si no encuentra a este último, convoca una reunión extraordinaria en la que se redefine el sprint para incluir el cambio... Chirría ¿verdad?

Cuando el equipo estima las funcionalidades de la parte superior de la pila de producto, hace el corte de lo que cree que le cabe en el sprint y se lo lleva pila de sprint se adquieren dos compromisos:

• El equipo se siente verdaderamente comprometido con la pila de sprint, de verdad cree que puede construir esas funcionalidades. Al fin y al cabo los miembros del mismo han decidido lo que cabe. Resaltar que se trata de que se sientan comprometidos, si por razones lícitas no llegaran a entregar no se les puede exigir que cumplan ningún compromiso.
• Propietario del Producto, jefes de proyecto, gerentes, responsables de área y otros interesados se comprometen a no romper el sprint, a no cambiar ninguna funcionalidad durante el sprint.

¿Porqué funciona Scrum? Porque es como si hiciéramos pequeños proyectos de dos semanas de duración con su entrega real, con todas sus consecuencias, con todo hecho para poder subir el incremento a producción. Esta forma de trabajar nos permite reconducir y cambiar de rumbo del proyecto entre sprint y sprint hacia lo que de valor y de verdad cubra las necesidades de nuestro cliente.

¿Qué puede a ocurrir si se aceptan cambios de funcionalidad a medio sprint?

• Rompemos el sentimiento de compromiso del equipo. La forma clásica de no sentir responsabilidad es "como lo ha dicho mi jefe... el sabrá lo que hace...". Cuando nos sentimos comprometidos nos sentimos motivados y lo damos todo dentro de lo razonable para cumplir con éxito. Si nos rompen eso, si sentimos que otros mandan sobre nuestras acciones, nos sentimos marionetas y perdemos toda responsabilidad, motivación y creatividad.
• Rompemos el ritmo y el trabajo del equipo. Si cerramos un sprint con ciertas funcionalidades y dejamos que el equipo se autoorganice, este encontrará la mejor forma y la más óptima para construir esas funcionalidades. Si rompemos el sprint el equipo tendrá que reconcebir y replanificar, lo que probablemente llevará a la no entrega a final de sprint.

El peor mal de esta conducta es esta no entrega. Cuando no llegamos a entregar una y otra vez, cada 2 semanas, hay un sentimiento de frustración que se acrecienta y que causa un estrés brutal. ¡Tendremos malos finales de proyecto cada dos semanas! Desde la perspectiva del seguimiento del proyecto saltarán alarmas cada dos semanas y eso puede llevar a un control brutal cada dos semanas...

¿De verdad un cambio no puede esperar como mucho dos semanas?

Si de verdad aplicamos Scrum y nos guiamos por valor de negocio, de manera que el equipo siempre esté construyendo aquello que más valor de negocio aporte, no es usual que haya cambios, ya que sobre lo valioso, el equipo de negocio y el usuario tienen muy claro de lo que se trata. Por supuesto el mercado puede traer un cambio inesperado y fulminante, pero eso es una situación excepcional. Scrum es ágil y permite pequeños ajustes a lo largo del sprint, pero nunca rompiendo con el objetivo del sprint.

En Scrum está prohibido cambiar la objetivo de un sprint a lo largo del mismo

Jefe de proyecto rompiendo el sprint junto al sentimiento de compromiso del equipo

La única autoridad que tiene un Propietario del Producto sobre un sprint es pararlo totalmente. Puede ser que no tenga sentido seguir con lo que está construyendo el equipo, y este decida parar el sprint, el objetivo del sprint ya no tiene sentido. A partir de aquí el equipo deberá dedicarse a las actividades necesarias para dejarlo todo bien, acabar cosas y/o deshacer otras. Una vez todo esté estabilizado se empieza de nuevo con Scrum y se sigue el ritmo con un nuevo sprint.

De forma excepcional existe el sentido común, el Propietario del Producto puede plantear la situación al equipo, y si este encuentra una fórmula que no afecte a la entrega ni al sentimiento de compromiso, en definitiva si el equipo encuentra una solución con la que se sienta cómodo, es factible absorber un cambio de funcionalidad. Resaltar que esa conducta excepcional no es Scrum, es puro sentido común y requiere de confianza y "buen rollo".

Scrum es otra forma de pensar y de hacer las cosas, quién cambie las reglas de Scrum al comenzar a andar va a tener muchos problemas. Hay muchas empresas que hacen Scrumbut, que es como se llama, y esas empresas suelen dejar de trabajar con su "Scrum" por el estrés que les genera. Scrum bien llevado crea espacios y tiempos correctos para que todo fluya de una manera motivante y con entregas con gran calidad... pero para eso hay que aplicar Scrum al 100% como es.