Hoy me gustaría compartir con vosotros un error que cometí hace tiempo y que a día de hoy sigue siendo uno de lo que más me encuentro a la hora usar el método Kanban como palanca de transformación en las organizaciones.
Hace pocos días mi compañero Jero nos contó qué es la transformación digital en un post altamente recomendable. Otra de las consecuencias de todo lo que explica Jero en ese post es que en las grandes organizaciones todo empezó a gestionarse con Silos Técnicos. Es muy tentador pensar que así está todo muy bien ordenadito. Front por un lado, backend por otro, middleware y los gestores de infraestructuras por otro. De hecho, puedo externalizar todo cómodamente y controlar la productividad de mis proveedores con puntos función, número de historias de usuario, o cualquier otra métrica de actividad (y no de valor).
Como ninguno de estos silos es capaz de producir valor al usuario final por sí mismo debemos crear una entidad que aglutine el trabajo de todas estas islas tecnológicas y lo entregue al usuario final. Y así surge la figura del Proyecto. Cuando alguien tiene una idea de negocio solicita a todos los silos el impacto que tienen en el proyecto y una estimación de en qué release podrán tener lista su parte. Tras un mes de reuniones se les comunica si realmente ese proyecto ha sido aprobado en el comité y en qué release esperan liberarlo.
Kanban como solución
Esta forma de trabajar genera miles de dependencias y bloqueos, además de un “Time to market” que, por experiencia personal, supera ampliamente el año. Esta claro que hay que hacer algo. Las organizaciones se suman al carro de la transformación digital y comienzan a apostar por métodos Ágiles.
Uno de los métodos Ágiles más conocidos es Kanban y a las oficinas de Transformación les suele encajar cuando hablamos de un silo tecnológico que da servicio al resto de la compañía.
Pero pensemos por un momento el ciclo de los proyectos. Separaremos en dos alturas cuando hay alguien trabajando en el proyecto y cuando está esperando a que alguien realice otro trabajo:
Este es el escenario en el mejor de los casos. Generalmente las releases tienen una fecha a la que algunos silos llegarán con el trabajo terminado y otros no. Lo que nos va dejando proyectos incompletos dentro de nuestro sistema durante meses y meses. Esto hace competir a las grandes en la carrera de la innovación entregando al usuario ideas que tuvieron hace más de 12 meses.
Obteniendo beneficio limitado de Kanban
Cuando se empieza a trabajar con Kanban en muchas organizaciones se piensa que el problema está en los equipos. Que no sacan el trabajo suficiente y se pone el foco en mejorar esos pequeños picos de actividad que vemos en la imagen anterior en vez de en los periodos de espera. Trabajar en tratar de mejorar esa eficiencia de recurso en vez de la eficiencia de flujo de todo el proceso nos hace desperdiciar mucho dinero y tiempo obteniendo pocos beneficios.
Si comenzamos a trabajar con Kanban solamente a nivel de silos seguramente habremos ganado en visualización de nuestro trabajo, gestionaremos mejor los riesgos y hasta podremos aumentar nuestra tasa de entrega. Pero lamentablemente esto apenas impactará en el time to market global, en que el número de bloqueos baje o en que generemos más valor. En definitiva, nuestro impacto en aumentar beneficios en la empresa será prácticamente nulo.
¿Cómo podemos lidiar con esto?
Un buen Agile Coach debe buscar la visión sistémica y ayudar a la organización a entregar más y más valor al usuario. Agile es un medio para maximizar revenue, gestionar riesgos y aprovechar oportunidad de mercado. Pero Agile no es un fin en sí mismo. Hay que tener cuidado de caer en la trampa de tener una lista de checks de si los equipos tienen tableros o no, si hacen dailies o no, si hacen retrospectivas o no, y quedarnos ahí. Cuidado con la vanidad de las métricas de actividad. (Aquí te dejo el enlace a nuestro Kanban Metric Layout por si te interesa)
Soluciones hay muchas y depende del contexto. Te puede ayudar:
- Que la organización sepa hablar de “flujo” a todos los niveles. Y entiendan cómo funciona.
- Tener métricas orientadas a flujo: Lead time, throughput, tiempo medio de bloqueo, etc.. en los equipos, y a nivel programa o portfolio.
- Poner el foco en eficiencia de flujo en vez de en eficiencia de recurso.
Entendiendo el concepto de flujo, visión sistémica y usando correctamente el método Kanban se puede obtener un alto impacto en un tiempo reducido. Si quieres saber más:
