¿Por qué SCRUM o KANBAN para tus proyectos de innovación abierta?

Recientemente estuve hablando con un director de tecnología de una empresa de seguros muy importante y me comentó que es muy difícil gestionar un proyecto de innovación, y sobre todo si es abierta, para conseguir los objetivos específicos planteados en plazo y fecha.

Es cierto que para muchos directivos, acostumbrados a las grandes definiciones de proyectos en cascada, con su planificación inapelable en sus herramientas encargadas de definir grandes diagramas de Gantt, con desviaciones predecibles y con pequeños cambios de ámbito, con riesgos catalogados desde el principio hasta el final con su propio política, hablar de gestión de proyectos e innovación, sobre todo abierta, le supone un cataclismo mental.

Si pensamos en un proyecto de planificación o instalación de una central nuclear así como de un proceso de negocio basado en leyes orgánicas ministeriales establecidas, gestión de proyectos ágiles como SCRUM o KANBAN también tendrían cabida, pero ya están muy trabajados la gestión de proyectos con metodologías predictivas propias, como son PMBok, Prince 2 o la española Métrica 3.

Pero en el caso de estar trabajando con proyectos con un cambio de ámbito constante (recordemos que en innovación se deben validar y despejar todos los aspectos de la incertidumbre que rodean al proyecto, generando un valor para los involucrados), así como tener una inestabilidad del entorno donde se desarrollan (no sabemos la evolución del entorno al estar definido todos los mercados como VUCA, salvo aquellos controlados por los gobiernos), utilizar metodologías adaptativas son la base para poder hacer frente a tantos aspectos que generan incertidumbre.

Tanto SCRUM como KAMBAN resuelven este problema. Ambos son las metodologías más utilizadas en la actualidad y han sobrepasado el mundo IT, estando cada vez más arraigadas en entornos comerciales y operacionales. Principalmente el concepto de ciclo de trabajo o Sprint como define SCRUM que KANBAN no lo tiene al ser aún más flexible (aunque se definan fases) puede ser importante si tenemos tareas que pueden entrar con muy alta prioridad en periodos muy cortos. Por lo tanto, si queremos gestionar entregables con plazos muy definidos con una evolución de producto estable, utilizar SCRUM favorece esta gestión frente a KANBAN, pero si las puestas en producción o lanzamiento de versiones no tiene un patrón fijo y pueden cambiar las prioridades muy rápidamente, mejor KANBAN que SCRUM.

También es importante entender cómo se gestionan las tareas a realizar, ya que en KANBAN son independientes unas de otras, mientras que en SCRUM suelen depender de una historia de usuario, de tal manera que pueden agrupar en otras tareas de menor tamaño en tiempo de trabajo. Por lo tanto, si el equipo está muy distribuido y sin una dirección o estrategia de trabajo fija, utilizar KANBAN es una ventaja, pero si hay pensado un recorrido evolutivo y coordinado entre varias, SCRUM puede ser una mejor solución.

Con todo esto, se ha visto que no hay soluciones mágicas y se debe elegir aquella que mejor encaje con las dinámicas de relación entre posibles socios y su forma de trabajar, o incluso combinar ambas de tal manera que dé respuesta a las necesidades del proyecto y la definición estratégica para afrontar el proyecto de innovación abierta.

 

 

 

 

Photo by Glenn Carstens-Peters on Unsplash