No planificar es planificar el fracaso. Esta frase del experto en gestión del tiempo Alan Lakein resume a la perfección la importancia de la planificación en la gestión de proyectos. Por mucho que odiemos las fechas y los alcances fijos en el mundo Agile, estos son el pan de cada día en muchas organizaciones, y no podemos ignorar su importancia. Incluso si salimos del ámbito de los proyectos con fechas y alcances fijos y nos sumergimos en el mundo del desarrollo de productos, la planificación sigue siendo de suma importancia. La mayoría de los clientes no comprometerán su presupuesto en una especificación abierta y exigirán una fecha de entrega junto con la cotización.
Al asumir dicha realidad, una pregunta natural es, “¿cómo creamos un plan de proyecto agile?”. Esta es una pregunta difícil, y la mayor parte del material que existe sobre el tema cubre únicamente el desarrollo de software. Esto crea la impresión de que Agile es únicamente para la industria de software, pero nada más lejos que la realidad.
La planificación Agile NO es planificación Scrum
A menudo leerás que la planificación Agile es lo mismo que la planificación Scrum. Sin embargo, esto está lejos de ser así. Scrum es un esquema prescriptivo de trabajo para el desarrollo de software que propone una manera concreta de planificar. Es frecuente en el mundo del software, pero a menudo es objeto de severas críticas.
No entraremos en detalles de por qué la planificación Scrum es defectuosa, ya que preferiríamos hablar sobre el pensamiento Agile aplicado a varias industrias y no solo software. Es más importante saber cómo aplicar las técnicas y prácticas genéricas a nivel global de la empresa, independientemente del tipo de negocio. Por el momento, sólo es esencial conocer que la planificación Agile no involucra el esquema Scrum en absoluto.
Planificación Agile de proyectos vs planificación tradicional de proyectos
En el pasado, los líderes empresariales dedicaban una gran cantidad de su tiempo al diseño de planes de ejecución detallados para los años venideros.
Por mucho tiempo, esta forma de planificación funcionó a la perfección. Sin embargo, a medida que los mercados se volvieron más dinámicos, en las últimas décadas del siglo XX, los requisitos comerciales comenzaron a cambiar con más frecuencia y fue necesaria una nueva forma de planificación más flexible.
Esta necesidad se volvió obvia y algo crítica con el auge del trabajo del conocimiento. Mientras que hace solo 50 años las personas trabajaban principalmente en fábricas, hoy en día el trabajo se hace en oficinas, en donde las personas utilizan su cabeza más que sus manos. Es en el trabajo del conocimiento preciso en donde más se necesita un plan de proyecto Agile.
La principal diferencia entre la planificación Agile y la forma tradicional (también conocida como “en cascada”) es que la primera es iterativa y se adapta a cambios. En contraste, la segunda es un proceso de planificación pesado paso a paso.
Cabe mencionar que ambos enfoques tienen sus virtudes. Cuando estás construyendo un puente o un edificio, quieres tener un plan bien detallado y bien pensado. En este caso, introducir requerimientos al final del proceso con un plan de proyecto Agile no es el enfoque más adecuado. Claro, puede pasar, pero los cambios pueden ser costosos de implementar.
Sin embargo, en el trabajo del conocimiento el cambio es bienvenido en cualquier etapa del proceso, incluso al final. El objetivo es crear una solución que satisfaga a los clientes, y todo está permitido. En pocas palabras, en la gestión de proyecto Agile, estableces planes detallados solo para períodos de tiempo más cortos, y puedes fácilmente hacer cambios cuando sea necesario.
Características de la planificación Agile de proyectos
Primero, centrémonos en los diferentes niveles en los que puedes planificar. La “cebolla de planificación Agile” describe mejor estos niveles:
Es fundamental comprender la idea de que la planificación Agile es aplicable en cada capa de la cebolla. No solo haces Agile a nivel de equipo (día, iteración, lanzamiento). Puedes tener un servicio de gestión de producto Agile, gestión de cartera Agile, y estrategia Agile. Ser ágil en tu estrategia es lo que define la agilidad empresarial en general.
Como dijimos antes, aunque no lo explicamos, la planificación agile es iterativa. Esto significa que desarrollas y ajustas tu plan varias veces, tanto como consideres necesario. El objetivo es invertir tiempo en la planificación en el mejor momento posible y adaptarse fácilmente a los cambios si estos ocurren en la fase de ejecución.
Independientemente del nivel en el cual operas, tu plan de proyecto Agile tendrá características similares. Explorémoslas sin ningún orden en particular:
- El objetivo desde los ojos del cliente (valor).
- Menos detalle siempre que sea posible (comprométete tan tarde como sea posible).
- Entregas frecuentes (lotes pequeños).
- Intervalos de fechas en lugar de estimaciones de fechas exactas (probabilísticas vs deterministas).
- Enfoque en el trabajo y no el trabajador (no miembros en particular, el responsable es el equipo).
- Sin fases de aseguramiento de la calidad separadas (la calidad está incorporada).
- Planes a dos niveles (líneas de tiempo para iniciativas, las tareas no tienen fechas de inicio/final).
- Basándose en datos (basándose en datos históricos y simulaciones de Montecarlo).
El objetivo desde los ojos del cliente (valor)
Un plan agile debe considerar exactamente lo que el cliente quiere. Si necesitamos tomar prestado un término del diccionario Lean, usaremos el término Valor. En otras palabras, nuestro plan debe estar claro en cómo y cuándo vamos a entregar valor al cliente.
En este sentido, cuanto más se enfoque el plan en los resultados, mejor. Si estás acostumbrado a incluir actividades dentro del plan, piénsatelo dos veces. ¿qué es más crucial, saber qué hace la gente, o qué valor ha producido?
Menos detalle siempre que sea posible (comprométete tan tarde como sea posible)
Imagina que te estás preparando para una expedición a una montaña alta que nunca ha sido explorada antes. Tendrás una estimación aproximada de la duración de la expedición para preparar suficiente agua y comida. Sin embargo, no sabes si habrá algún lugar apto para acampar ni dónde podría estar ese lugar.
Muchos proyectos en el trabajo del conocimiento son bastante similares a dicha expedición. Conoces bastante de antemano sobre el proyecto, pero no lo suficiente como para comprometerte en cada parte del mismo. Aun así, muchos managers insisten en tener un plan estricto y detallado para cada entregable del proyecto. Curiosamente, en la vida real relegamos nuestro compromiso hasta el último momento en que sea responsable hacerlo, pero fallamos en hacerlo en nuestro plan de proyecto.
Entregas frecuentes y feedback rápido (lotes pequeños)
Un plan Agile debe adecuarse a entregas frecuentes y hacer explícita la recopilación del feedback. De hecho, el feedback recibido debe ser reflejado en la siguiente versión del plan, lo que mejoraría la probabilidad de un cierre exitoso de proyecto.
Por definición, los proyectos son grandes lotes de trabajo. Sin embargo, no hay obligación de entregarlos de una vez. La mayoría de los clientes querrían tener una vista previa temprana de los resultados para asegurarse que el proyecto no se desvía mucho de lo que esperan recibir.
Supongamos que el equipo de proyecto entendió mal los requerimientos y se puso a trabajar en algo completamente diferente a lo que imaginaba el cliente. ¿Prefieres darles un feedback cerca del inicio o esperarías al final del proyecto? Es más que natural dar una feedback temprano en el ciclo y prevenir la pérdida de tiempo y recursos valiosos.
Intervalos de fechas en lugar de estimaciones de fechas exactas (probabilísticas vs deterministas)
Cuando los clientes preguntan sobre la duración del proyecto, generalmente esperan una fecha fija. Pero te sorprendería saber cuántos clientes estarían de acuerdo si les das un intervalo de fechas en lugar de una fecha fija.
Como dicen, es mejor tener más o menos razón que estar equivocado. Y esto es lo que alentamos a todos a hacer – utilizar intervalos de fechas basadas en datos históricos y métodos de predicción para crear una línea de tiempo Agile para tu plan.
Enfoque en el trabajo y no el trabajador (no miembros en particular, el responsable es el equipo)
Esto proviene de la misma perspectiva que el ejemplo del compromiso tardío. Si asignas personas a los trabajos demasiado pronto, corres el riesgo de hacer lo incorrecto en el momento equivocado. Desde la perspectiva de que nos preocupamos por el flujo de trabajo y no necesariamente en utilizar cada trabajador al 100%, está bien permitir que el equipo se organice en torno al proyecto.
Es cierto que tienes especialistas en el equipo, lo que genera muchas dependencias, especialmente en empresas grandes. La respuesta natural de un coach Agile sería eliminar las dependencias, pero esta es una respuesta que está lejos de la realidad. No puedes eliminar todas las dependencias sin crear cientos de problemas en otras partes de la organización.
Lo razonable sería gestionar las dependencias que provienen de la visión holística de tu organización y los flujos de valor. Si el flujo de valor al cliente se ve bloqueado por el equipo X, entonces allí es donde deberías enfocarte, incluso si eso significa que el equipo Y no tendría nada en lo que trabajar.
Esto es un tanto radical y requiere un cambio de paradigma, pero es un concepto fundamental en la planificación Lean y Agile de proyectos. Está demás decir que, en dichas situaciones, tu plan debe reflejar el enfoque en la resolución de bloqueos/problemas con un menor enfoque en la utilización de los empleados.
Sin fases de aseguramiento de la calidad separadas (la calidad está incorporada)
Toyota se convirtió en el mayor fabricante de autos en menos de 50 años, comenzando como una pequeña empresa familiar. Uno de sus principios fue la “calidad incorporada”, que significa que no se debe perder tiempo reparando el producto después de que ha salido de la línea de producción.
Sería mejor si te esfuerzas por lograr el mismo nivel de calidad durante la fase de ejecución del proyecto y, por cualquier medio, tratar de evitar la fase final de “aseguramiento de la calidad”. Si tienes una gran fase final de aseguramiento de la calidad, es probable que hayas ignorado este aspecto a lo largo del ciclo de vida del proyecto, y una vez que llegas a esta fase las cosas comienzan a ponerse feas.
Por supuesto, es mejor tener un control de calidad final en lugar de enviar un producto defectuoso, pero esto debería ser una excepción y no la norma.
Planes a dos niveles (planifica sólo las iniciativas y no las tareas)
Esta es una de las características esenciales de una planificación Agile efectiva. Si tienes un plan gerencial de todos los entregables principales (iniciativas), es fácil dividirlos en tareas y después pasar dichas tareas a los equipos de ejecución.
Aunque suene trivial, esto representa una diferencia sustancial comparado con los planes tradicionales en diagramas de Gantt. Cuando divides una iniciativa (entregable de proyecto) en sus tareas, recomendamos no asignar fechas de inicio y finalización para cada tarea a menos de que sea necesario.
Por ejemplo, una tarea que representa la creación de banners para un concierto sería inútil después del concierto, por lo que debe tener una fecha límite. Sin embargo, la mayoría de las veces, las tareas no tendrán una fecha límite real.
Cuando omites fechas de inicio/finalización para todas las tareas individuales le permites a tus equipos arrastrar (pull) nuevo trabajo cuando tengan la capacidad y no cuando pensaste que deberían tener la capacidad. Aquí, la palabra ARRASTRAR (PULL) se utiliza a propósito, ya que ilustra el principio ARRASTRAR que ya conocemos tan bien de Toyota.
El hecho de que asignes fechas de inicio y finalización a la iniciativa y omitas las fechas de sus tareas secundarias, separa la planificación de la ejecución. De este modo, mantienes el plan de Proyecto Agile en términos de tiempo y compromiso, pero permites a tus equipos tomar la decisión optima ya que son los más cercanos a los detalles técnicos del trabajo.
Basándose en datos (utiliza tus datos históricos para planificar el futuro)
Si utilizas el método Kanban para ejecutar las tareas diarias en tus equipos, es fácil emplear métodos estadísticos para la previsión basada en datos. Uno de estos métodos ampliamente utilizado en el mundo Agile son las llamadas simulaciones de Montecarlo.
Las simulaciones de Montecarlo toman como entrada datos históricos (rendimiento y tiempo de ciclo). Luego, con la ayuda de algoritmos matemáticos, se simulan cientos de resultados posibles para tu proyecto. Después de evaluar todos los posibles resultados, la simulación ofrece información sobre las posibles fechas de finalización del proyecto con cierta probabilidad adjunta al pronóstico.
Por ejemplo, una simulación de Montecarlo puede pronosticar un 85% de probabilidad de que tu proyecto se concluya antes del 2 de julio. Alternativamente, el pronóstico puede decirte que hay un 95% de probabilidad de que entregues 200 tareas o más antes de tu fecha límite. Esto da una buena indicación sobre el estado del proyecto y se basa completamente en estadísticas, lo que puede ahorrarte el tiempo de calcular todas las tareas una por una.
Herramientas como el software de Businessmap, combinan esta idea con la anterior (planes a dos niveles) para crear un sistema de pronóstico continuo que informa a los managers de todos los proyectos el estado actual y sus entregables. La plataforma de software de Businessmap extiende este tipo de pronóstico continuo al nivel de cartera ya que es fácil ver un pronóstico en tiempo real de todos los proyectos. Todo lo que necesitas hacer es ejecutar las tareas del día a día en un conjunto de tableros Kanban y conectarlas a Su portfolio.
Ejemplo de plan de proyecto Agile
Como ya hemos hablado de las características de la planificación Agile, veamos un ejemplo práctico de cómo construir un plan Agile y cómo lo hacemos en Businessmap.
Definición de los principales entregables o lanzamientos del proyecto
Digamos que tenemos que planificar la creación de un nuevo sitio web. Como el alcance de esto es bastante grande, lo primero que haríamos es definir las diferentes partes funcionales (entregables) que se irán lanzando continuamente al mercado.
Aquí debemos aclarar que no vamos a planificar los entregables en detalle. Un proyecto Agile deja esto para el “último momento responsable” y lo incluye progresivamente a lo largo del proyecto. Esto nos ahorra el tiempo, que de otro modo perderíamos, de la planificación innecesaria y nos ayuda a retener la agilidad para cualquier cambio emergente.
Para construir una hoja de ruta para la ejecución de los entregables puedes usar una línea de tiempo de proyecto Agile. En Businessmap, por ejemplo, usamos una línea de tiempo Kanban (como se puede ver abajo). Después, puedes añadir uno o más de los entregables para que se ejecuten en paralelo o visualizar una secuencia cuando algunos de estos sean dependientes de otros.
Dividir en tareas
Una vez que tenemos visualizadas todas las partes principales del proyecto en una vista similar a una hoja de ruta, nuestro siguiente paso sería dividirlas en tareas individuales. A medida que elaboramos progresivamente nuestros planes Agile, comenzaremos con los entregables más críticos en este punto.
Para visualizar las tareas y su flujo hasta su finalización, puedes utilizar un tablero Kanban dedicado. En Businessmap, conectamos la línea de tiempo Agile que contiene la hoja de ruta del proyecto y el tablero Kanban, como se observa a continuación.
Esto ofrece una vista inigualable de todo el progreso del proyecto desde el concepto hasta la realización. Como resultado, podemos ver qué entregables están actualmente en progreso, su estado, y quien está trabajando en qué, en cualquier momento. Esta configuración también nos permite colaborar entre nosotros cuando las tareas se atascan en el proceso y resolver los problemas más rápido.
Mediante el concepto de la planificación “justo a tiempo”, podemos retener la agilidad para cualquier cambio de última hora, requisitos emergentes o prioridades cambiantes. Esto nos permite satisfacer mejor las necesidades del cliente con la entrega de nuestros proyectos.
Ofrecemos la plataforma de software
más flexible para agilidad empresarial orientada a resultados.
