En "Innovation happens everywhere..." se mostraba un vídeo con un dúo de artistas canarios que se habían diferenciado significativamente del resto haciendo lo mismo de una forma diferente. En el día a día de nuestros proyectos nos podemos igualmente diferenciar haciendo pequeños pero continuos cambios que incorporen mejoras en nuestra forma de hacer las cosas. Nada que ver con las innovaciones disruptivas que hacen temblar los pilares de sectores completos, nada que ver el célebre "Vamos a cambiar el mundo" de Steve Jobs... pero sostenidos en el tiempo pueden tener un espectacular efecto en nuestra empresa/departamento/equipo.
Nuestros pequeños cambios pueden ir en la dirección del clásico "hacer más con menos" prometido por el Pensamiento Lean, o tal vez en una reducción del Time to Market o simplemente disminuir el nivel de estrés mejorando con ello la satisfacción del equipo. Cualquiera de los objetivos anteriores deben ser alcanzados a través de la mejora de la eficiencia, por más que se empeñe la jerarquía superior en hacerlo aumentando el ritmo con el clásico "redoble de tambores".
El método Kanban nos ofrece un conjunto muy reducido de reglas que nos sitúa en esta senda. La primera es visualizar el flujo de trabajo. Empieza por no cambiar nada, simplemente visualizar como el trabajo pasan de una etapa a otra. Es sorprendente la capacidad de mejora que tiene el mero hecho de visualizarlo, ya que deja al descubierto muchas ineficiencias que permiten a las personas que trabajan habitualmente en dicho proceso mejorarlo significativamente. La siguiente regla es limitar el trabajo que tenemos en curso: No te engañes, somos más eficientes manejando las tareas de una en una. La tercera regla: observa, mide y corrige lo que consideres que puedes mejorar.
Esta última regla en parte surge como resultado de la aplicación de las anteriores. Si el equipo deja al descubierto las ineficiencias puede eliminarlas, si se le escucha y se aceptan sus propuestas con el tiempo emerge un clima en el que se considera natural proponer mejoras. Si no estás acostumbrado a escuchar/plantear propuestas de mejora es posible que el clima no sea el adecuado.
Por otra parte, la limitación del trabajo en curso (work-in-progress: WIP) provocará bloqueos en el tablero. Ten en cuenta que un WIP muy alto genera tareas ociosas mientras que un WIP muy bajo provocará gente ociosa. Esto es debido a que ante determinadas situaciones del tablero Kanban puede darse el caso de que una persona no pueda comenzar una nueva tarea (debido al WIP) ni ayudar a otro compañero (debido a la Ley de rendimientos decrecientes) por lo que esta persona, hasta que se resuelva el bloqueo del tablero, se encuentra “de brazos cruzados”.
Esta última regla en parte surge como resultado de la aplicación de las anteriores. Si el equipo deja al descubierto las ineficiencias puede eliminarlas, si se le escucha y se aceptan sus propuestas con el tiempo emerge un clima en el que se considera natural proponer mejoras. Si no estás acostumbrado a escuchar/plantear propuestas de mejora es posible que el clima no sea el adecuado.
Por otra parte, la limitación del trabajo en curso (work-in-progress: WIP) provocará bloqueos en el tablero. Ten en cuenta que un WIP muy alto genera tareas ociosas mientras que un WIP muy bajo provocará gente ociosa. Esto es debido a que ante determinadas situaciones del tablero Kanban puede darse el caso de que una persona no pueda comenzar una nueva tarea (debido al WIP) ni ayudar a otro compañero (debido a la Ley de rendimientos decrecientes) por lo que esta persona, hasta que se resuelva el bloqueo del tablero, se encuentra “de brazos cruzados”.
Obviamente es complicado que, al menos inicialmente, la jerarquía superior vea con buenos ojos que una persona no sea “productiva”. Porque, ¿como relacionas a una persona de brazos-cruzados con la innovación? ¿Y cómo puede ser esto más productivo?
La respuesta está en la forma de gestionar estos bloqueos creando tiempos de innovación que redunden en el bien general de la empresa/departamento/equipo. Obviamente no se trata de que esa persona pueda dedicarse media mañana a leer su sección preferida de un periódico online o planificar sus vacaciones… eso no redundará en la mejorará del rendimiento. Pero si se encarga de investigar cómo automatizar el etiquetado de versiones, o se lee un capítulo de un libro de Testing, o se instala Gradle para compararlo con la herramienta actual de build, o ve un par de vídeos técnicos en YouTube... en este caso sí estará mejorando el rendimiento a medio plazo del equipo. Si además les das la suficiente libertad para que cada uno profundice en el campo que le interese, tendrás un factor extra de motivación.
Lo importante en este punto es alinear estos tiempos de innovación con nuestro propio proceso y entorno. Si no desarrollamos para dispositivos móviles (ni hay previsión de ello), la innovación en ese sentido no aportará nada al equipo, sólo a la persona, por lo que no debería iniciarse. Pero en todos lo procesos existen posibilidades de mejoras, algunas veces a través de cambios simples y otras requerirá de este esfuerzo extra de investigación pero haciéndolo bien, los indicadores de rendimiento no sólo no se degradarán sino que mejorarán. La siguiente imagen muestra la evolución real de una métrica, en este caso el número de peticiones de usuarios en espera para un equipo de mantenimiento software antes y después de la aplicación de Kanban.
De este modo, una vez arrancada una iniciativa Kanban, ajustado los límites del trabajo en curso (WIP) y estabilizado las métricas básicas dispondrás de una palanca accionable para amplificar la innovación dentro de tu equipo si manejas esos bloqueos adecuadamente.
Hay organizaciones que ofrecen un tiempo fijo a sus empleados a estas tareas, y por ejemplo, cada dos semanas dedican un día a la innovación pero suele tratarse de empresas que nacieron Ágiles, dudo que un entorno tradicional sea capaz de dar este salto de forma sencilla, pero a través de Kanban igualmente lo puedes potenciar sin cambios bruscos.
No hay comentarios:
Publicar un comentario