Planificación ágil: Lo mejor de dos mundos

Agile Plaining

Visión General de la Planificación Ágil

Planificación ágil. Parece una paradoja, ¿verdad? Planificar implica establecer límites, crear listas de control, determinar fechas de entrega y seguir un proceso paso a paso, ¿no es así?

Pero Agile, ¿no se trata de que la gente haga lo suyo? Mucha gente piensa que la planificación tradicional es el equivalente musical de una orquesta clásica disciplinada y la planificación ágil es el caos de forma libre del jazz.

Nada más lejos de la realidad.

Este artículo explicará por qué el pensamiento ágil y la planificación no son excluyentes y pueden funcionar juntos de manera poderosa para su negocio.

Descubramos si la Planificación Ágil es algo para usted.

Breve reseña

La planificación ágil es una forma de planificar el desarrollo de productos en un entorno ágil, desde las metas y objetivos del negocio hasta la ejecución diaria en los equipos de desarrollo.

El desarrollo de productos, especialmente el de software, es dinámico. Los requisitos de los usuarios y clientes cambian. Debido a los cambios en su entorno y porque el uso de un producto a medida que evoluciona desencadena ideas de una manera que ningún documento de especificación podría jamás.

Por ello, es fundamental aceptar los cambios frecuentes y planificar en consecuencia.

Al igual que el desarrollo ágil de software, la planificación ágil es iterativa, lo que la hace intrínsecamente adaptable al cambio. Esto le permite centrar su atención en las necesidades del usuario y del cliente en todos los niveles de su negocio.

También significa que el plan en sí no es tan importante. El verdadero valor de la planificación ágil radica en el pensamiento necesario para crear el plan y en cómo conecta el trabajo a todos los niveles con las metas y objetivos de la empresa orientados al cliente.

Breve historia

El desarrollo de software tenía mala fama en los años 80 y 90 del siglo pasado. Los proyectos se excedían en sus plazos y en sus presupuestos.

Resultó que el desarrollo de cualquier software es un esfuerzo complejo en un entorno a menudo complejo y cambiante. Algo que simplemente no se puede controlar con los métodos de planificación tomados de los proyectos de construcción.

El enfoque en cascada no es suficiente cuando se trata de responder a los cambios en el entorno y las necesidades de los clientes.

El desarrollo ágil de software evolucionó por ello. Sin embargo, muchas empresas seguían utilizando el método tradicional de planificación del desglose del trabajo para predecir sus costes y establecer presupuestos.

El desarrollo ágil de software elimina el desglose del trabajo, al menos hasta el último momento. Algunos defensores de lo ágil incluso abogan por negarse a realizar estimaciones de tiempo y recursos. Al fin y al cabo, de qué sirve planificar de esta manera cuando se sabe que las cosas cambian y que cualquier plan es probable que sea inexacto en el momento en que se crea.

Sin embargo, la necesidad de controlar los costes y establecer presupuestos no desapareció ni siquiera cuando los beneficios de la agilidad en la entrega de software que funciona y satisface las necesidades de los clientes eran evidentes.

Algo tenía que cambiar y la planificación ágil era la respuesta, ya que ofrecía a los directivos y ejecutivos una forma de estimar los costes y establecer los presupuestos sin que el departamento de desarrollo tuviera que volver a intentar predecir el futuro.

¿Cómo funciona?

La idea clave de la planificación ágil es vincular todo lo que se hace en el desarrollo a las estrategias y objetivos de la empresa.

Esto significa que la planificación comienza en la cúspide -el director y la alta dirección- y se va detallando progresivamente hasta llegar al nivel de los equipos que ejecutan el trabajo.

Una bella metáfora de este proceso de planificación es la cebolla de la planificación ágil.

Planificación ágil Cebolla

Es un recordatorio visual del espectro que la planificación ágil debe cubrir en toda la empresa.

How does it work?

The key idea for Agile Planning is to tie everything that’s done in development back to the business’ strategies and objectives. This means that planning starts at the top — the director and senior management level — and gets progressively more detailed on the way down to the level of the teams that execute the work. A beautiful metaphor for this planning process is the Agile Planning Onion.

Como puede ver, la cebolla tiene seis capas. Éstas corresponden a la estructura jerárquica típica de la mayoría de las empresas.

  • El nivel estratégico examina hacia dónde quiere dirigirse la empresa en el futuro, sus metas y objetivos a largo plazo.
  • El nivel de cartera es importante en las empresas que ofrecen múltiples conjuntos de productos. Examina cómo estas suites de productos proporcionan a los clientes una solución integral que ayuda a la empresa a alcanzar sus metas y objetivos.
  • El nivel de producto desarrolla una hoja de ruta para un solo producto (suite), detallando hacia dónde tiene que ir para cumplir su parte en la cartera.
  • El nivel de lanzamiento detalla qué trabajo hay que hacer en un producto y en qué orden, y establece fechas de entrega basadas en el rendimiento histórico y la duración de las iteraciones.
  • El nivel de iteración se centra en el trabajo que debe realizarse en la siguiente iteración. Este es el dominio de los equipos que ejecutan el desarrollo del producto.
  • El nivel diario es donde los equipos se reúnen para discutir la planificación diaria de su trabajo y el progreso hacia la consecución de lo que planearon en el nivel de iteración.

Clientes en el centro

En la planificación ágil, la atención se centra continuamente en aportar valor al cliente.

La pregunta en todo momento es: ¿lo valoran? Poco más importa.

El trabajo que realiza un equipo es menos importante que el valor que su trabajo representa para los clientes.

Para asegurarse de que el trabajo representa un valor para los clientes, hay que entregarlo con regularidad para poder recibir la opinión inmediata y directa de los clientes. Esto le permite adaptarse a medida que construye y mejora el producto que está creando para ellos.

Sí, esto significa que todo lo que has planificado puede cambiar a medida que cambian las necesidades del cliente. Por eso la planificación ágil, como el desarrollo ágil, es iterativa.

Y eso está bien porque lo que se busca es el valor del cliente, no la ejecución de un plan para desarrollar algo que el cliente ya no necesita.

Poner al cliente en el centro de la planificación ágil se inspira directamente en los dos primeros principios del Manifiesto Ágil:

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

Último momento de responsabilidad

La planificación ágil favorece la toma de decisiones en el último momento responsable. Al menos en el caso de las decisiones irreversibles -que no tienen vuelta atrás, o la vuelta atrás sería costosa-.

La cuestión es que no tomar una decisión tiene un coste, pero tomar una decisión demasiado pronto -con conocimientos y datos insuficientes- también conlleva un coste importante.

  • El coste de no tomar una decisión reside en el coste de mantener las ineficiencias u otros inconvenientes de la situación actual. Y estos costes bien pueden aumentar con el tiempo.
  • El coste de tomar una decisión demasiado pronto aumenta el riesgo de tomar la decisión equivocada e incurre en el coste de oportunidad: las ganancias que podrías haber tenido, si hubieras tomado una decisión diferente.

Por eso hay que esperar hasta el último momento responsable: cuando el coste de no tomar una decisión sea mayor que el de tomarla.

Esto se aplica a todas las decisiones, incluida la planificación de las características de su producto.

Hay que esperar al último momento de responsabilidad para refinar (detallar) las nuevas características, porque lo que hay que hacer para una característica cambia a medida que se implementan otras características. En otras palabras: si añades detalles (tomas decisiones) demasiado pronto, habrás desperdiciado el esfuerzo cuando las circunstancias cambien y tengas que aplazar esa función, o incluso descartarla por completo.

Por lo tanto, sólo hay que perfeccionar (en parte) las características que se implementarán definitivamente en las próximas dos o tres iteraciones. Y añada sólo los detalles suficientes a las características que tienen que esperar más tiempo para informar de sus decisiones de planificación y priorización.

Entregas frecuentes

En el Manifiesto Ágil se observa que se hace hincapié en la entrega frecuente de software que funcione.

Asimismo, es un componente clave de la planificación ágil.

Las entregas frecuentes de características tienen varios beneficios. Cuanto más frecuentes sean las entregas de software funcional, mayor y más detallada será la retroalimentación de los clientes. Esto tiene un efecto en cadena para la planificación de la siguiente iteración y evita alejarse demasiado del resultado deseado por el cliente.

Este es uno de los contrastes con el desarrollo tradicional en cascada y con los métodos de planificación del desglose del trabajo por adelantado.

Presupuestos y fechas de entrega

La planificación ágil fomenta un enfoque probabilístico para estimar los plazos del proyecto y las fechas de entrega.

Las características de un enfoque probabilístico son:
  • Evitar las estimaciones de una sola fecha siempre que sea posible.
  • Utilizar en su lugar «rangos» de fechas.
  • Reflejará las variables de un proyecto.
  • Basaría los cálculos predictivos utilizando datos históricos.
  • Tanto los costes como la duración del proyecto no pueden definirse con precisión desde el principio.
Las características de un enfoque determinista son:
  • Fechas fijas de finalización rígidas.
  • Cada actividad tiene un valor planificado.
  • La duración total del proyecto es fija, es determinista.
  • Los riesgos se definen como algo inamovible.
  • Los costes y la duración del proyecto son fijos desde el principio.

El enfoque probabilístico de la planificación ágil tiene varias ventajas para su proyecto:

  • Las líneas de base del proyecto para el coste, el alcance y los plazos, reflejan las variables, los cambios y las incertidumbres inherentes a cada proyecto.
  • El uso de datos históricos para los cálculos (simulaciones de Monte Carlo) producirá rangos de fechas finales más realistas.
  • Los presupuestos y las fechas de entrega son más realistas. Es mejor estar «casi bien que totalmente mal».
  • Podrá mitigar mejor riesgos como el rebasamiento del proyecto, los costes y la exposición, cuando las tareas individuales puedan contribuir a un rebasamiento.
En resumen, los plazos ágiles serían flexibles en cuanto al alcance y el tiempo (para adaptarse a los cambios de requisitos), pero fijos en cuanto a los recursos (equipos y, por tanto, coste). Y esto es precisamente lo que permite estimar los costes y determinar los presupuestos sin necesidad de que el desarrollo realice las estimaciones.

En este sentido, la planificación ágil ofrece lo mejor de ambos mundos. Pero recuerde:

  • Centrarse en el trabajo y no en el trabajador.
  • En un enfoque ágil, quién hace el trabajo es de importancia secundaria.
  • El trabajo en sí mismo es de importancia primordial.
  • No hay necesidad imperiosa de asignar roles, planificar para equipos y no para individuos.
  • El flujo de trabajo en sí debe ser fluido y continuo.
  • El negocio decide las características que quiere construir y las pone en orden de prioridad para el negocio.
  • El equipo de desarrollo decide cómo construirlas.
  • Juntos priorizan las características teniendo en cuenta las limitaciones técnicas y la eficiencia.

Garantía de calidad incorporada

Aunque no forma parte estrictamente del proceso de planificación en sí, conviene tener en cuenta que en el enfoque de cascada, las pruebas de aceptación por parte de los usuarios y operadores son una etapa separada después de la construcción y las pruebas técnicas del producto por parte de los propios desarrolladores.

En el enfoque ágil, la idea es probar pronto y con frecuencia. Los usuarios y operadores revisan y prueban cada característica en cuanto está disponible, en lugar de esperar a que todo el producto esté listo.

Al fin y al cabo, el objetivo es entregar un software que funcione.

Cuando se entrega una función en un entorno ágil, se prueba y se acepta. No de forma aislada, sino en el contexto del producto tal y como ha crecido hasta entonces.

No hay necesidad de una etapa separada o de un equipo separado para garantizar que todo encaje y funcione en conjunto. Todo eso forma parte del proceso estándar y ya se ha completado.

Esto hace que la planificación sea mucho más fácil y que las fechas de entrega sean más predecibles, ya que no habrá grandes sorpresas desagradables al final que te obliguen a rehacer el trabajo. Las sorpresas se limitan siempre a lo que se ha hecho en una iteración y, con la colaboración y los comentarios del cliente en cada iteración, el riesgo de crear algo que el cliente no pretendía también es pequeño.

La entrega continua facilita la planificación

Un gran obstáculo para la planificación previsible son las medidas que los desarrolladores tienen que tomar para mantener las funciones terminadas fuera del producto lanzado porque el calendario de la empresa baila al ritmo de una melodía diferente. Por ejemplo, cuando un conjunto de nuevas características debe ser lanzado durante una feria comercial.

El problema es que mantener esas características «en stock» presenta riesgos porque el trabajo en el producto no se detiene, y su incorporación en una fecha posterior significa tener que rehacer el trabajo, especialmente muchas pruebas.

La forma de evitar todo eso es adoptar la entrega continua con interruptores de características que controlen qué características están disponibles para quién. Esto permite desconectar el momento de la liberación a los clientes del momento en que una característica se integra en la base de código liberada.

Uso de decisiones basadas en datos

Un componente clave de la planificación ágil es su flexibilidad inherente para adaptarse a los cambios en el entorno de trabajo.

El reto de realizar proyectos durante la pandemia es un gran ejemplo de ello. Durante la pandemia, algunas personas enfermaron y estar ubicados en el mismo edificio se hizo imposible. Esto afectó a todos los implicados en el desarrollo y la entrega de funciones nuevas y modificadas.

En lugar de cuestionar los plazos fijos y deterministas, Agile utiliza datos y métricas reales para tomar decisiones realistas e informadas.

Existen varias herramientas para ello.

Una herramienta que se utiliza a menudo son los tableros Kanban y las métricas centradas en el flujo de trabajo a través del proceso y su uso para estimar las fechas de entrega del trabajo en curso y en preparación.

Un enfoque más matemático consiste en utilizar simulaciones de Montecarlo para predecir los costes y las fechas probables de entrega. Hace tiempo que se utilizan en la gestión de proyectos Lean y son una herramienta útil para estimar el rendimiento de los proyectos.

La simulación de Montecarlo utiliza datos históricos sobre capacidad y rendimiento para calcular el porcentaje de posibilidades de alcanzar un objetivo del proyecto, como el coste o la fecha de entrega. Esto permite evaluar el riesgo asociado al trabajo.

Similitudes y Diferencias

Las principales diferencias entre la planificación tradicional y la planificación ágil:

  • La planificación tradicional es determinista (o trata de serlo) – La planificación ágil es probabilística aceptando que el mundo cambia.
  • La planificación tradicional se ve como una opción «segura» – La planificación ágil se ve como una opción «arriesgada». Esto es incorrecto.
  • La planificación tradicional se compromete pronto en el punto de menor conocimiento – La planificación ágil se compromete en el último momento responsable en el punto de conocimiento informado que además aumenta exponencialmente con la continua retroalimentación del cliente.
  • La planificación tradicional es rígida, el plan en sí lo es todo – La planificación ágil es flexible, el plan en sí es relativamente poco importante, la planificación lo es todo.
  • La planificación tradicional informa de fechas de entrega fijas, lo que implica predictibilidad y certeza – La planificación ágil utiliza rangos de fechas predictivos utilizando datos históricos, aceptando la fluidez de una actividad compleja en un entorno adaptativo complejo.
  • La planificación tradicional suele requerir planes separados o específicos para la gestión de la estrategia empresarial y la planificación diaria – La planificación ágil abarca la armonización de la planificación desde la estrategia hasta el «taller».
  • La planificación tradicional se centra en las tareas – La planificación ágil se centra en el valor.

El riesgo del enfoque en cascada, que consiste en hacer predicciones en una fase temprana, cuando se sabe lo mínimo sobre lo que está por venir, es que las predicciones son tremendamente inexactas. La razón es que un cambio en las necesidades del cliente significa que también hay que rehacer el trabajo que ya se ha hecho en etapas anteriores.

El enfoque de planificación ágil es intrínsecamente iterativo y adaptable. El riesgo se mitiga con los comentarios de los clientes a lo largo del proyecto y con cada función entregada.

Vale la pena señalar que la gran escala de algunos proyectos, como los emprendidos por la NASA, seguirá un enfoque más tradicional de planificación o un híbrido de cascada y ágil llamado planificación en espiral.

Una vez vistas las similitudes y diferencias entre Agile y waterfall, veamos las funciones y responsabilidades clave en la planificación ágil.

Funciones y responsabilidades clave

Las funciones cruciales de la planificación ágil son:
  • Directivos responsables de la planificación estratégica y de la cartera.
  • Directores de proyecto, directores de producto, directores de investigación y jefes de equipo de producto responsables de la planificación del producto.
  • Gerentes de proyecto, gerentes de entrega responsables de la planificación de lanzamientos y de tender un puente entre el personal anterior y los equipos técnicos para decidir qué características van a lanzar.
  • Desarrolladores, probadores, diseñadores, responsables de la planificación de la iteración y la planificación diaria.

Estos roles y responsabilidades reflejan la cebolla de la Planificación Ágil que se discutió anteriormente.

Y, de nuevo, es importante destacar que es el papel y la responsabilidad de todos adoptar la mentalidad ágil y aceptar el concepto de planificación ágil.

Reuniones clave, ciclos y cadencias de entrega

La planificación ágil no prescribe realmente ninguna reunión o ciclos y cadencias específicas, pero hay cadencias típicas para cada capa de la Cebolla de planificación:

  • Los equipos discuten el trabajo diario a diario. Piensa en el stand up diario en Scrum o en el inicio del día en Lean.
  • Los planes de iteración, obviamente, siguen la longitud de la iteración. Por ejemplo, la Planificación del Sprint en Scrum, informada por los resultados de la Revisión del Sprint y la Retrospectiva del Sprint anterior.
  • Los planes de liberación suelen seguir una cadencia trimestral. Piensa en la planificación trimestral del incremento del producto en SAFe.
  • Las hojas de ruta del producto y los planes de la cartera suelen tener una cadencia de 12 meses.
  • Las empresas suelen tener planes estratégicos de 12 meses y de 5 años.

Errores comunes

Para que la Planificación Ágil funcione, el pensamiento ágil, tal y como se establece en el Manifiesto Ágil, tiene que estar en la mente de todo el mundo en toda su empresa, en todos sus departamentos y en toda su gente.

Si el pensamiento ágil, la mentalidad ágil, es primordial en la planificación a través de las seis capas de la Cebolla de la Planificación, utilizarla en su beneficio se hace mucho más difícil.

Los escollos más comunes a los que se enfrentan las empresas son:

  • La planificación ágil se refiere a la búsqueda de objetivos empresariales y a la forma en que éstos se transmiten al «taller» para mantener a todos alineados. Los problemas surgen cuando un departamento no está sincronizado con otro.
  • Con frecuencia, la planificación ágil se adopta con éxito en las tres capas interiores de la cebolla, pero no en las tres superiores. Esto hace que todo se desajuste.
  • No aceptar que el propio plan cambiará inevitablemente, ya que es en sí mismo, iterativo y reflejará los requisitos cambiantes del cliente.
  • Un punto débil habitual es planificar a partir de una fecha fija predeterminada. Esto fomenta la previsión futura desde una posición en la que se tiene el menor conocimiento.
  • Olvidando que el objetivo es mitigar y reducir el riesgo, no aumentarlo tomando decisiones o predicciones en un momento en el que no se tiene suficiente conocimiento para hacerlo.

Cómo empezar

Lo mejor que puede hacer para comenzar de manera excelente su campaña de Planificación Ágil, es buscar capacitación y asesoramiento.

No sólo para unos pocos, sino para todos los involucrados en la planificación en cualquier capa de la Cebolla de la Planificación Ágil. Después de todo, difundir el conocimiento ayuda a difundir la mentalidad y pone a todos en la misma página.

Dicho esto, no hay que lanzarse a la piscina con todo el mundo al mismo tiempo.

Comience con las capas internas de la Cebolla de Planificación Ágil. Estas son las personas que probablemente ya están bien versadas en la planificación de sus iteraciones de manera ágil.

Muévase hacia afuera una capa a la vez. Si tiene varios grupos de productos, puede considerar esto para un solo grupo de productos primero y usar la experiencia con eso para traer otros grupos de productos a bordo.

Más información

  • Agile Project Management: Creating Innovative Products por Jim Highsmith.
    Agile Project Management: Creating Innovative Products por Jim Highsmith.
  • Herding Cats por Greg Ross-Munro.
  • Forecasting: Asking the right questions for Business Agility (seminario web a petición)
  • Delivering Business Agility without Estimation (seminario web a petición)
  • Portfolio and Upstream Kanban (seminario web a petición)

¿Listo para comenzar su viaje de planificación ágil?

¿Recuerda por dónde entramos? ¿La planificación ágil suena como una paradoja? Bueno, ahora sabe que eso no es cierto. Y ya sabe lo que necesita saber para decidir si es algo para usted. Si es así, empiece por recibir una formación y un asesoramiento sólidos. De Nimble, por supuesto.
Signup

Signup for updates!

[wpforms id=»8824″]

¡La vida es buena cuando sus equipos ágiles están sincronizados!

Solicite una demostración personalizada de SwiftEnterprise.