Agilidad y gestión ágil de proyectos

Agilidad empresarial (Agility) y agilidad puramente productiva (Agile), dos términos que tienden a confundirse y sobre los cuales pretendemos dar luz en el siguiente artículo. Aunque si bien es obvio que existe un vínculo entre ambos, también lo es que su trasfondo último es muy distinto. Luego los objetivos que persigue uno y otro término rara vez coincidirán. Esta problemática deriva en un hecho muy habitual: ponemos en valor una iniciativa que no nos reporta los resultados esperados cuando todo, en teoría, ha funcionado acorde a la preestablecido. ¿Dónde está el problema? Lee nuestro artículo, para evitar que esto ocurra en tu propia empresa.

Agilidad a nivel de negocio (Agility) y agilidad productiva (Agile), términos que no deben confundirse.

La necesidad de este artículo tiene su origen en la cantidad de casos en que, de forma errónea, se confunden los términos de agilidad empresarial (Agility) y agilidad puramente productiva (Agile). Aunque si bien es obvio que existe un vínculo entre ambos, también lo es que, su trasfondo último es muy distinto. Luego, los objetivos que persigue uno y otro término rara vez coincidirán.

De esta condición, por tanto, depende el éxito o el fracaso empresarial de cada una de estas iniciativas. Nunca alcanzaremos los resultados esperados si la iniciativa de base no está enfocada a ellos. Y es un error, os lo garantizo, mucho más común de lo que se puede imaginar: casi todas las empresas que afirman que “eso de la agilidad” no va con ellos es porque, en su momento, acometieron un proyecto abocado al fracaso, incluso antes del kick-off meeting.

En este sentido, voy a intentar explicar de la forma más llana posible, qué es cada término, qué implicaciones y connotaciones tiene y, sobre todo, qué objetivos persigue.

Para ir de menos a más, empecemos por la Agilidad Productiva (Agile), ya que es un término mucho más acotado. Normalmente, la confusión viene siempre derivada de la implantación de Agile, del cual se esperan unos resultados que, en realidad, corresponderían al Agility. Contrariamente, rara vez pasa a la inversa, ya que el que conoce el término de agilidad empresarial “Agility” es porque ya tiene un bagaje previo que le permite diferenciarlo del equivalente productivo “Agile”.

1. AGILIDAD PRODUCTIVA AGILE

1A/ Contexto

Cuando nos ponemos como objetivo diseñar un nuevo producto o servicio, una de las partes más complejas es trazar su puesta en el mercado. Una tarea especialmente difícil para todas aquellas empresas que vienen del mundo de los servicios puros y, de repente, quieren comenzar a generar producto, sea por la motivación que sea. Entre las más comunes, se sitúan las siguientes:

• Quieren seguir las tendencias del mercado.
• Quieren avanzar hacia dónde lo está haciendo su competencia.
• Quieren meterse en proyectos de I+D+i y con servicios no es posible.
• Han identificado algún tipo de ayuda o subvención para producto.
• Quieren tener un recurrente asegurado por licencias y mantenimientos.
• Quieren “generar dinero mientras duermen”.
• Es decir, quieren tener una cierta estabilidad que el servicio no les da.
• Etc.

Esta complejidad, en muchas ocasiones, no se detecta hasta que el proyecto, por desgracia, ya está abocado al fracaso. Esto ocurre, en esencia, porque la valoración técnico-económica inicial y la gestión del proyecto asociado a la creación de ese nuevo producto se lleva a cabo mediante las mismas metodologías que se venían usando para los habituales servicios.

Sin embargo, el contexto en muy distinto, sobre todo a nivel incertidumbre. Siempre que queremos llevar a cabo algo extraordinario, entendiendo por extraordinario algo que se sale de mi zona de confort; se van a presentar escenarios inesperados. Al fin y al cabo, voy a realizar una labor exploratoria, casi experimental. Voy a formular unas hipótesis de cómo entiendo yo qué será ese desarrollo, pero sin tener capacidad para anticiparme al impacto de los posibles contratiempos porque directamente los desconozco.

Además, se suma una nueva condición que siempre hemos de tener presente en el horizonte: hemos de diseñar lo que el cliente realmente esté demandando. Aquí no se admiten conjeturas. Es decir, he de estar preparado para lanzar, con la mayor celeridad posible, productos mínimos viables para su testeo. Un testeo del cual obtendré un valiosísimo feedback sobre el que iterar, tantas veces como sea necesario, con el fin de proporcionar al cliente ese nuevo producto o servicio a su medida.

Ambas condiciones, por tanto, chocan de frente con ese encorsetado diagrama de Gantt que tanto amamos y odiamos al mismo tiempo. En ese Gantt, como mucho, puedo fijarme unos buffers a modo de contingencias y, si he fijado unas dependencias relacionales, identificar las tareas cuello de botella (camino crítico), para conocer mi mejor y mi peor fecha de fin de proyecto de forma estimada. Herramientas, por tanto, muy básicas para poder controlar con garantías esos flujos no lineales de alta incertidumbre.

Normalmente, para hacer una buena valoración técnico-económica, es clave poder estimar el tiempo y esfuerzo que va a llevar hacer cada una de las subtareas y/o actividades que competen al desarrollo. Por ello, siempre se hace hincapié en la importancia de contar con una amplia experiencia previa en el campo correspondiente. Ya que así acotamos el riesgo de sobreestimar horas (nos podemos quedar fuera por precio al ir a cliente final) o subestimarlas (podemos resultar adjudicatarios de un proyecto dónde seguro perderemos dinero.

Luego, ya en fase de valoración u oferta (si hablamos para terceros), he de tener claro qué metodología voy a emplear para la gestión del proyecto en caso de tener que llevarlo a cabo. Un aspecto que rara vez he podido ver reflejado en las ofertas que han llegado a mis manos por parte de proveedores o colaboradores. Y es que, equivocadamente, tendemos a ubicarlo más bien como un detalle a definir en el kick-off meeting, cuando ya puede ser demasiado tarde para asegurar el éxito del proyecto.

Llegados a este punto, la otra pregunta que no surge, es: ¿qué es para nosotros un proyecto exitoso? Formalmente, según el PMBook, “un proyecto se considera exitoso cuando el mismo se completa, en plazo y presupuesto, y se cumplen con los requisitos especificados en el alcance”.

Una definición sobre la que José Luís Portella, CEO de Magnatalent, hace unas importantes puntualizaciones para adaptarla al contexto tan complejo que vivimos estos días: “sin embargo, a día de hoy, esta definición es incompleta: Los criterios actuales miden el valor de la inversión (VOI) y no solo el retorno de la inversión (ROI), el alineamiento con la estrategia de la compañía, la capacidad evolutiva de la solución, la utilización adecuada de las nuevas tecnologías y, por su puesto, todo lo relacionado con la responsabilidad social corporativa o el respeto absoluto por el medio ambiente. Es por tanto crítico que, en la ejecución del mismo, se tengan en cuenta otros factores teniendo una visión a medio plazo y un respeto absoluto a todos los stakeholders del proyecto”.

Todo lo anterior, nos lleva a las siguientes conclusiones:

• En proyectos de alta incertidumbre o alta complejidad (co-creación, experimentación, etc.), la metodología de valoración y gestión clásica de proyectos, es insuficiente.
• La experiencia en un campo, por si sola, ya no es suficiente garantía para poder estimar horas y esfuerzo correctamente.
• Cuando el cliente entra en la ecuación, algo necesario por otro lado, también entra en los workflows de la metodología seleccionada, luego, debe de tener unos conocimientos mínimos para poder jugar su papel.
• La metodología a emplear, sea la que sea, se tiene que tener clara desde la fase de valoración técnico-económica.
• El concepto de proyecto exitoso es más complejo cada día. Es una realidad que, antes o después, tenemos que afrontar para poder adaptarnos.

1B/ Principios, Atributos y Claves del Agile

Agile no es en realidad algo nuevo, ya que tiene sus orígenes en el desarrollo de proyectos de software a principios de los 90. En aquellos días, con la llegada del primer sistema operativo Windows de éxito comercial (el 3.0), se destapó la necesidad de dotar a estos usuarios de herramientas de software que permitieran sacar al máximo partido a sus PCs.

Sin embargo, en aquellos días, el tiempo de poner en mercado un nuevo desarrollo, era de 3 años de media. Así, era común que, cuando un producto veía la luz, podía ya estar obsoleto de base o no cumplir con lo que los usuarios demandan entonces. Existía un gap tecnológico importante que derivó en una avalancha de proyectos fracasados e inversiones desastrosas.

Así, casi una década después, y con el fin de solventar este gran problema, 17 de los principales líderes de desarrollo de software mundial se dieron cita en una estación de esquí en Utah para dar forma al Manifiesto Ágil, el cual cambiaría la industria del software para siempre.

Un Manifiesto Ágil que contaba con 12 principios básicos, de los cuales se extraen los 5 atributos más importantes de definen a un proyecto productivo como ágil (Agile):

• Transparencia
• Enfoque al cliente.
• Adaptabilidad.
• Sentimiento de pertenencia (liderazgo efectivo).
• Mejora Continua

Transparencia: La visión compartida del proceso, con independencia de la posición de ese stakeholder en el organigrama productivo, es necesaria. Y cuando digo cualquier stakeholder, obviamente, no sólo es a nivel interno, sino también externo: cliente, proveedores, etc. De ahí, precisamente, surgen esos tableros de trabajo tan vistosos llenos de postits, cuyo fin es promulgar con esa política de apertura total. Una política dónde cualquier idea, en cualquier momento, es igualmente bienvenida: no hay que tener miedo a comprometer el proyecto si aportamos valor. Así, se crea un entorno unitario dónde los errores y los aciertos sólo tienen un nombre de fondo, el del equipo.

Enfoque en el cliente: Cualquier potencial solución resulta estéril si no somos capaces de hacer ver al cliente como ésta resolverá sus problemas. Decía Dave Mcclure: “A los clientes no les importa tu solución. Les preocupan sus problemas”. Un contexto que, en ocasiones, es complejo de gestionar, puesto que ese cliente, en muchos casos, no tendrá el background técnico necesario para entender la propuesta. Pero lo que sí que tendrá claro, siempre, es lo que necesita, por ello, la colaboración continúa es la clave. Ese feedback que vamos a obtener de forma iterativa es oro para poder optimizar el desarrollo de nuestros proyectos y conseguir un cliente satisfecho que obtenga, justo, lo que quería (que no tiene porqué ser lo mismo que inicialmente pensaba que necesitaba).

Adaptabilidad: Estar siempre listos para responder ante el cambio es la mayor de las virtudes. Nuestro fin es entregar, en cada momento, el máximo valor al cliente, recopilando su feedback para proceder en consecuencia. Y hasta no alcanzar esa fase, no sabremos exactamente qué acciones son las siguientes a tomar. Por lo que, o somos capaces de adaptarnos rápidamente a ese escenario particular o seremos incapaces de dar una respuesta de garantías.

Sentimiento de pertenencia: Empoderar al equipo contribuye a un liderazgo más eficiente, ésta es la máxima. Las complicadas jerarquías piramidales, aparte de generar cuellos de botella, ponen en riesgo la correcta transmisión de la información: a mayor número de interlocutores, cada uno con una formación más o menos técnica, mayor probabilidad de ocurra eso que llamamos “teléfono roto”. Por ello, tiene todo el sentido que la información fluya de forma natural hacia el interlocutor más preparado, independientemente de su posición jerárquica. Con esta medida, dotas de autonomía al empleado, potencias su crecimiento personal y profesional, fomentas la colaboración con el equipo y generas un grupo ágil en su proceder.  El resultado es un grupo de trabajo altamente motivado y focalizado en los objetivos; así como, un líder que es libre para centrarse en el trabajo y no en los trabajadores.

Mejora continua: es uno de los aspectos que más se acerca al Lean, cuyo objetivo era “hacer más con menos”. Al final, ese feedback constante por parte del cliente es también un aprendizaje continuo, y planificar los siguientes pasos en función de dicho feedback te obliga a ser mejor en cada entrega. En ese sentido, es un win-win que contribuye de forma muy positiva al éxito del proyecto.

Sólo a partir de estos principios del Manifiesto Ágil y sus atributos podemos dar forma a los 4 claves que definen Agile:

• Las personas y la interacción por encima de los procesos y las herramientas.
• Desarrollos que funcionan por encima de documentación extensa.
• Colaboración con cliente por encima de la negociación del contrato.
• Responder a los cambios por encima de seguir un plan.

No quiere esto decir que los elementos finales de cada afirmación se desprecien, siguen siendo importantes, pero lo son más aún los primeros. A modo resumen, podríamos citar a Victor Fairén, consultor de Lean Agile, quien afirma lo siguiente sobre Agile:

“Agile es una mentalidad, una filosofía, una cultura organizacional. Esta filosofía pone en el centro las PERSONAS, tanto al cliente como a los miembros del equipo. El foco debe ser las Personas, la comunicación, como fluye la información, la colaboración, la confianza y la autonomía.”

1C/ Frameworks de Trabajo

Nos queda ahora ver cómo encajamos este nuevo mindset Agile, apoyado en esos 12 principios básicos, 5 atributos y 4 claves del Manifesto Agile, en un marco de trabajo con el que nos sintamos cómodos.

La oferta es muy amplia en este sentido, ya que, para que un framework funcione ha de personalizarse para cada organización, equipo e incluso proyecto. Es decir, si el día de mañana decides formarte en algún framework, como puede ser Scrum, que es el más conocido, y lo aplicas tal cual te lo han enseñado, casi con toda seguridad serás incapaz de sacarle el máximo partido.

Esta condición da como resultado cientos de variables funcionales que los usuarios, a lo largo de los años. han ido recopilando bajo denominaciones en formas de siglas: XP, CI, CD, FDD, TDD, SCALE, SAFe, entre otros muchos. Todas ellas, bajo los principios del Agile, ponen en valor el salto cualitativo que supone su aplicación frente a las metodologías clásicas o en cascada. Sobre todo, en proyectos de media-alta complejidad, dónde sólo el 10% de los casos se cataloga como exitoso de forma consensuada:

 % de proyectos exitosos, cuestionables y fracasados; según volumen de negocio.

Pero ¿qué diferencia, a nivel ejecución, a un proyecto ágil de uno clásico? Sin entrar en las particularidades de cada framework, voy a hacer una reflexión al más puro estilo PMBook.

Esta guía define lo que se conoce como las 3 restricciones de un proyecto: alcance, tiempo y coste; las cuales definen implícitamente la calidad entregada. Pero, como hemos visto, la mayoría de las veces, en proyectos complejos, no se alcanza el éxito. Es decir, asumiendo que el alcance es el que es, porque la necesidad es la que es, habrá desviaciones en tiempo, coste o calidad. Luego, tenemos 1 parámetro fijo y 3 variables.

Si hacemos ahora el mismo análisis con un proyecto Agile, dónde me reúno continuamente con el cliente para recoger feedback e ir mejorando el proceso y la calidad de las entregas, ¿qué tengo? Lo que consigo es acotar tanto el riesgo, que ahora tendré los tiempos, costes y calidad entregada como 3 parámetros fijos, y como variable sólo me quedará 1 parámetro, el alcance. Y diréis: ¿pero has dicho antes que el alcance es el que es? Lo que ocurre aquí es que con esta política de co-creación y mínimo riesgo voy a poder brindar al cliente la posibilidad de hacer ciertos cambios en el alcance sin que esto me penalice ni repercuta negativamente en el éxito del proyecto. Condición que va a repercutir, además, en positivo, tanto en la satisfacción de ese cliente como en su potencial fidelización.

Llegados a este punto me gustaría poner sobre la mesa los 2 frameworks más extendidos para que el que tenga curiosidad pueda indagar ya por su cuenta:

• SCRUM: Es el framework más popular con diferencia. Data de 1995 y fue creado por Jeff Sutherland y Ken Schwaber. Con Scrum, un proyecto se ejecuta en ciclos temporales cortos (Sprints) de 2-3 semanas, dónde las tareas a realizar se particionan como historias de usuario según su complejidad y el esfuerzo que suponen. En cada ciclo hay que aportar siempre el máximo valor posible al producto, recibiendo feedback continuo del cliente tras cada sprint con el fin de iterar el proceso de forma continua en busca de esa mejora constante. Sin entrar en terminología más técnica, la cual puede ser objeto de otro artículo, el proceso se rige según sigue:

Ciclo de gestión de proyectos con Scrum

• SCRUMBAN: Scrumban es un término bastante ambiguo y que define una aproximación de Scrum con el fin de hacer una transición hacia el Kanban. Kanban es una técnica de gestión de tareas muy visual que cumple con muchos principios del Agile, pero que no tiene por qué implicar un desarrollo Agile en sí. Es decir, con Kanban lo mismo puedo llevar a cabo un proyecto clásico o en cascada que un Agile. De ahí nace Scrumban, de la necesidad de diferenciar entre esas 2 posibles vertientes. En esencia, se emplean los fundamentos ya mentados de Scrum, pero con una mejora a nivel de procesos que aporta Kanban gracias a su potencia visual. Esto permite adelantarse a posibles cuellos de botella o dar respuesta incluso más rápida a tareas críticas.

Diferencias entre Scrum y Scrumban

Para terminar, únicamente me quedan mentar las herramientas de software que os pueden ayudar en este paso a Agile: Jira, Asana, Monday, Wrike, Airtable, etc. e incluso otras más conocidas como Trello, con las que tenéis que tener especialmente cuidado porque es, en realidad, una herramienta Kanban, por lo que podéis caer en hacer un “falso agile” o un “cascada encubierto” muy lejos del verdadero Agile.

2. Agilidad a Nivel de Negocio (Agility)

Aquí voy a ser mucho más breve, porque habiendo explicado Agile en detalle es sólo cuestión de remarcar las diferencias para entender la amplitud de este nuevo término.

En esencia, cuando yo pongo en marcha Agile en mi empresa lo hago con el fin de mejorar el time-to-market de mi producto o servicio. El problema es que parámetro no depende sólo de la producción en si (Agile), sino de todo el “value stream” del producto o servicio.

Por ello, cuando una empresa pone en marcha todo el mecanismo del Agile de forma aislada se encuentra con que la repercusión real es mínima en comparación con lo esperado. Y entonces vienen las preguntas ¿Qué ha pasado? ¿Por qué no nos está funcionando como debería? ¿La inversión ha merecido de verdad la pena? ¿Está fallando algo?

Lo que ha fallado es que el puzle está aún incompleto. Para que ese time-to-market se reduzca de verdad hace falta Agilidad de Negocio (Agility). Dentro de la cual, una pieza importante en la dimensión productiva es el Agile. Es decir, la iniciativa de digitalización ha de evolucionar en una verdadera transformación digital a nivel transversal para que repercuta en el negocio como se esperaba en un principio.

Aquí entra en juego esa evolución hacia la empresa inteligente, la cual, describo en otro de mis artículos que os invito a leer.

Espero que, ahora sí, tengáis claro la dimensión de cada término para que podáis ponerlos en valor adecuadamente en vuestro negocio. Y si quieres asesoramiento para la implantación de Agile y Agility en tu empresa, no dudes en contactarnos.