¿Qué es ágil? Una filosofía que se desarrolla a través de la práctica

Originalmente concebido para equipos de desarrollo de software, Agile es ahora el principal enfoque de gestión de proyectos para industrias y empresas de todo el mundo. El atractivo radica en su simplicidad y flexibilidad: la falta de prácticas prescriptivas de Agile lo hace altamente adoptable. Y, sin embargo, al guiar las transformaciones ágiles en varias empresas, descubrí que esta flexibilidad también genera conceptos erróneos sobre lo que significa ser ágil. Muchas empresas dan prioridad a la adhesión a los marcos derivados de Agile sobre la comprensión de la filosofía en sí.

En cambio, los gerentes de proyecto y los entrenadores que ensamblan y guían a los equipos ágiles deben comenzar por capacitarlos para que adopten una mentalidad ágil, esencialmente internalizando los valores y principios fundamentales de la filosofía. Solo entonces deben combinar, personalizar u omitir prácticas de los marcos ágiles en función de lo que mejor se adapte a los requisitos del proyecto.

Al rastrear el desarrollo histórico de Agile y vincular sus principios fundamentales a las necesidades específicas de las empresas y los equipos, este artículo puede ayudar a los gerentes de proyecto a crear un futuro óptimo para las transformaciones de Agile. Como demuestran los siguientes casos, Agile no debe considerarse estrictamente como un enfoque de gestión de proyectos, sino más bien como una filosofía de desarrollo de productos que evoluciona continuamente en la práctica.

Antecedentes ágiles

Compilado por primera vez en 2001, el "Manifiesto para el desarrollo ágil de software", una colección sucinta de cuatro valores fundamentales y 12 principios, fue una respuesta radical a los enfoques lineales, pesados ​​​​en procesos, cargados de reglas y montones de documentación. Pero la historia de Agile se originó décadas antes con un método para optimizar la fabricación industrial.

Un antecedente de la filosofía por su enfoque en la mejora iterativa, el modelo Plan-Do-Study-Act fue desarrollado en la década de 1930 por el físico y estadístico de Bell Labs, Walter Shewhart. Después de la Segunda Guerra Mundial, su protegido, W. Edwards Deming, lo aplicó para formar gerentes en Toyota. El método fue parte integral del desarrollo del Sistema de Producción de Toyota, la fuente principal del pensamiento Lean con su ciclo eficiente de construcción, medición y aprendizaje.

En la década de 1970, el concepto se desarrolló aún más cuando Barry Boehm propuso la técnica Wideband Delphi, utilizando un proceso iterativo para estimar con precisión y objetividad el trabajo y el tiempo necesarios para desarrollar software.

Con la proliferación de las computadoras personales a mediados de la década de 1980, quedó claro que el software como producto y servicio se convertiría en la piedra angular de la forma en que las personas hacen negocios. A medida que los profesionales comenzaron a prestar mucha atención a los enfoques incrementales e iterativos de la ingeniería de software, Agile superó a los procesos Waterfall como el enfoque superior de gestión y desarrollo.

Los investigadores descubrieron que los fabricantes que innovaban más rápidamente que sus competidores empleaban un método multidisciplinario orientado al equipo para mover un producto a lo largo de su ciclo de vida. Esto es ampliamente considerado como la inspiración de Jeff Sutherland para inventar el marco Scrum en 1993, lo que le permitió completar proyectos aparentemente imposibles a tiempo y por debajo del presupuesto, con errores mínimos.

Los valores de Agile en teoría, que surgen de estos antecedentes, se han confirmado en mi uso de Agile en la práctica, con énfasis en el desarrollo iterativo, el trabajo colaborativo en equipo y la estimación precisa.

¿Qué es ágil en teoría?

A medida que las empresas continúan adoptando formas ágiles de trabajar, corren el riesgo de volverlas más prescriptivas de lo que nunca pretendieron los creadores de la filosofía. En mi experiencia, los líderes que desean adoptar Agile se enfocan demasiado en los marcos, o conjuntos de prácticas específicas y su nomenclatura asociada, y no lo suficiente en los valores y principios.

Como bien saben los profesionales avanzados en la impartición de principios Agile, cada organización que busca experimentar una transformación Agile tiene que encontrar y adaptar enfoques que se adapten a ellos. Facilito este proceso de aprendizaje mostrando a los equipos cómo seguir los valores y principios del manifiesto y luego inspirándome en los marcos, como Scrum, Kanban y Extreme Programming (XP), para implementarlos en la práctica.

Los principios del manifiesto ahora son una segunda naturaleza para los gerentes de proyectos ágiles:

1. Individuos e interacciones sobre procesos y herramientas
2. Productos de trabajo sobre documentación completa
3. Colaboración con el cliente sobre la negociación del contrato
4. Responde al cambio sobre el siguiente plan

Sin embargo, a menudo se pasa por alto la advertencia que sigue a estos principios en el manifiesto: "Es decir, mientras que los elementos de la derecha tienen valor, valoramos más los elementos de la izquierda". Muchos practicantes ágiles terminan ignorando los valores de la derecha y enfocándose solo en lo que está a la izquierda. ¿El resultado? Lo contrario de seguir ciegamente los marcos de trabajo pesados ​​​​del proceso: ningún proceso en absoluto, lo cual es igualmente problemático.

Lograr el equilibrio adecuado entre los elementos de la derecha y la izquierda se ha convertido en la clave de cómo guío las transformaciones ágiles. También está ejemplificado por los enfoques de gestión en Apple, Google, Amazon, Facebook y Netflix, ninguno de los cuales se ha suscrito a un marco Agile singular. Han encarnado los principios del manifiesto en primer lugar, mientras siguen o cambian partes de diferentes marcos en función de lo que les ha funcionado mejor; como resultado, se han adaptado a los cambios del mercado y pueden ofrecer nuevos productos rápidamente.

¿Qué es ágil en la práctica?

En el siguiente resumen, modifiqué la redacción original de los valores del manifiesto. Los cambios en la semántica ayudan a aclarar cómo aplico los valores ágiles en la práctica.

En el primer valor, sustituyo el término “individuos” por “personas” porque ser ágil significa estar orientado al equipo. En cuanto al segundo, es obvio que el software tiene que estar "funcionando", por lo que ahora el enfoque está en la "entrega" exitosa y oportuna. El tercer valor es simplemente "colaboración", ya que se aplica por igual a colegas que trabajan juntos y equipos que trabajan con clientes. Finalmente, "marcos" reemplaza "seguir un plan", porque esto evita el malentendido de que la planificación debe abandonarse por completo.

Personas sobre procesos

Las transformaciones ágiles son difíciles, principalmente porque la mayoría de las empresas están muy acostumbradas a seguir estrictamente los procesos. Completar una cierta cantidad de pasos con un determinado conjunto de herramientas, en lugar de desarrollar un producto innovador, se convierte en el objetivo final.

Me ha consternado ver que esta mentalidad da lugar a una "industria ágil" rentable. Como explican los fundadores de Agile, Ward Cunningham y Jon Kern, muchas empresas venden software que, según afirman, ayudará a las empresas a "volverse ágiles". Pero volverse ágil significa adoptar una filosofía, no usar software y seguir el programa que prescribe.

Lograr el equilibrio adecuado no se trata de eliminar procedimientos, sino de encontrar aquellos que mejor apoyen los objetivos de desarrollo de cada equipo. Para uno de mis clientes, una gran organización de tecnología empresarial, implementé Disciplined Agile, un enfoque desarrollado en IBM. Combina muchas prácticas de múltiples marcos, incluidos Scrum y Kanban. Utiliza el desarrollo iterativo, pero tiene un poco más de proceso que Agile tradicional, especialmente en la fase inicial, porque está destinado a llenar los vacíos que deja Scrum. Disciplined Agile funcionó para este cliente porque la organización estaba muy orientada a los procesos. Me permitió reunirme con los equipos a mitad de camino, obtener su aceptación y persuadirlos para que adoptaran un flujo de trabajo de Scrum.

Incorporé reuniones de refinamiento de tareas pendientes, reuniones de revisión y scrums diarios para facilitar la colaboración dentro y entre equipos. El refinamiento del Backlog es parte de la Guía Scrum, pero las reuniones de refinamiento no lo son. Los agregué para permitir una conversación saludable sobre por qué planeamos implementar funciones específicas en los próximos sprints, lo cual es útil para los novatos de Agile. También elegí la nomenclatura "hitos", un término utilizado en la gestión de proyectos de Waterfall, porque era más familiar para el cliente. Las revisiones y las interacciones diarias de Scrum son elementos convencionales de la Guía de Scrum, pero las hice más estructuradas en términos de programación, duración y flujo.

Además, mientras que una adherencia estricta a Scrum haría que cada persona se dedicara por completo a uno de los roles enumerados en la Guía de Scrum, había personas en los equipos de mis clientes cuyos conjuntos de habilidades no encajaban perfectamente en un rol. Usar el método Disciplined Agile me permitió dividir las responsabilidades de estos puestos entre varios miembros del equipo y crear un proceso que aprovechó las fortalezas de las personas involucradas.

Entrega de software sobre documentación

Otra razón por la que prefiero los flujos de trabajo personalizados de Scrum o Kanban al cumplimiento estricto de cualquier marco es que me dan la oportunidad de agregar el producto mínimo viable (MVP) al plan como objetivo. Derivado de Lean, la práctica de crear un MVP es consistente con el desarrollo iterativo y se ha convertido en una técnica popular entre los practicantes de Agile. Permite que un equipo entregue software de alta calidad y otros bienes a los usuarios de manera eficiente y luego los perfeccione en función de los comentarios. Aplicarlo como parte de un enfoque híbrido basado en gran medida en Scrum o Kanban ha mejorado las habilidades de mis equipos para crear productos que satisfagan las necesidades de los clientes.

Actualmente estoy trabajando con una empresa nueva con sede en EE. UU. y estoy empleando este método para crear un mercado de criptomonedas para NFT. Nos estamos enfocando en crear el MVP, por lo que solo estamos escribiendo la documentación mínima necesaria por ahora. Si bien este enfoque es efectivo para una amplia gama de productos, es especialmente útil para las criptomonedas y las NFT, que se encuentran en una nueva categoría experimental que está cambiando rápidamente. En lugar de redactar especificaciones y características completas y tener que cambiarlas repetidamente antes del lanzamiento, podemos dedicar ese tiempo a incorporar los comentarios de los usuarios para mejorar el desarrollo de nuestro mercado.

Colaboración sobre contratos

La organización tecnológica de gran empresa antes mencionada se basó en gran medida en los contratos para muchos proyectos de costo fijo. Los contratos describían los métodos que utilizarían para completar el trabajo, así como las personas específicas que serían responsables de cada tarea. Una vez firmados, los contratos no podían modificarse sin un largo proceso de solicitud.

Parte de la transformación que lideré priorizó la colaboración sobre estos acuerdos rígidos. El plan que implementamos reemplazó los contratos con documentos de una página. Cada uno declaró que acordamos usar Agile para trabajar en colaboración, con nuestros clientes, así como con nuestros compañeros de equipo y colegas de diferentes equipos, entre las fechas de inicio y finalización designadas. Lo que saliera de la colaboración sería el resultado. No incluí detalles sobre cuáles podrían ser los productos terminados. Debido a que estábamos solicitando comentarios de los clientes e incorporándolos en el desarrollo de nuestro producto, eliminar las especificaciones de nuestro documento del plan nos hizo más receptivos a sus respuestas y los incentivó a trabajar con nosotros de manera más activa.

Para lograr que la gerencia participara, les pedí que me dejaran liderar una prueba de concepto con un pequeño equipo que trabajaba con un pequeño cliente, que había expresado su preocupación de que los tiempos de desarrollo eran demasiado largos, incluso antes de que los cambios requeridos agravaran el problema. Al hacer que este cliente colaborara directamente con nuestro propietario del producto, pudimos realizar cambios a mitad del desarrollo y reducir significativamente los tiempos de entrega.

Estos resultados persuadieron a la gerencia para que me permitiera implementar el plan en más equipos. En general, el contrato simplificado y nuestro flujo de trabajo Agile redujeron el tiempo necesario para desarrollar y llevar las características del producto al mercado.

Adaptabilidad sobre marcos

Otro cliente mío, una empresa de tecnología de la salud, tampoco logró un equilibrio en términos de reconocer la importancia de ambos lados de un valor ágil, es decir, responder al cambio en lugar de seguir un plan. En este caso, sin embargo, había cometido el error opuesto al de mi cliente de tecnología empresarial: en lugar de seguir un proceso de manera demasiado rígida, había sobre indexado la flexibilidad mientras descuidaba en gran medida el proceso. Los ingenieros rara vez sabían en qué deberían estar trabajando porque no había prioridades ni cronograma. Perdieron tiempo y productividad tratando de resolver eso cada día y completaron tareas menos importantes antes que las más cruciales.

Propuse la implementación de Scrum al CEO y al CTO, explicando que los sprints obligarían a los ingenieros a ser disciplinados y planificar en incrementos de dos semanas, en lugar de decidir en qué trabajar cada día. Además, les aconsejé que contrataran a un propietario del producto, lo que solucionaría la falta de responsabilidad del equipo sobre el producto. Pedí a los ejecutivos que me dieran tres o cuatro meses para trabajar con sus equipos antes de que esperaran ver resultados.

Habiendo obtenido su aprobación, primero presenté los valores y principios de Agile, luego entrené al equipo en la cartera de productos y las diferentes técnicas para organizarla, incluida la creación de epopeyas e historias de usuarios, y la creación de subtareas. Las técnicas y reuniones que incluimos en nuestro flujo de trabajo son desviaciones del Scrum tradicional en el sentido de que no aparecen en la Guía de Scrum. Los integré en el plan porque las epopeyas, las historias y las subtareas resonaron en los equipos durante el entrenamiento y las reuniones promovieron debates productivos.

También incluí el concepto de velocidad, una adición tardía a XP que mide las estimaciones de esfuerzo total para todas las historias de usuario en cada iteración del producto. Sin embargo, utilicé el término "capacidad", que prefiero porque enfatiza cuánto pueden recoger los miembros del equipo de trabajo en lugar de qué tan rápido pueden completar las tareas.

Para la estimación, comencé con la talla de camiseta, una técnica que mide proyectos y tareas como pequeños, medianos y grandes; a medida que el equipo avanzaba, cambié a puntos de historia, una técnica de estimación más tradicional. Los puntos de la historia a menudo son mal utilizados por equipos no iniciados en Agile, que intentan convertirlos en horas o días de trabajo, centrándose excesivamente en los plazos y juzgando a las personas en función de su capacidad para cumplir con los plazos.

El tamaño de la camiseta es más abstracto, lo que facilita que los equipos eviten este escollo. Sin embargo, también es menos preciso. Entonces, una vez que el equipo entendió cómo estimar en términos relativos, los pasé a la técnica más sofisticada.

Cuando el equipo completó dos sprints, la alta gerencia pudo ver a sus empleados trabajando de manera más productiva y comunicándose de manera más efectiva. Los desarrolladores estaban interactuando con las partes interesadas y la gerencia ejecutiva por primera vez. Se habían reunido con el equipo de atención al cliente y habían comprendido cómo las funciones que habían implementado estaban mejorando la vida de los usuarios.

Este enfoque pronto condujo a un aumento en la calidad del software de la empresa y una reducción en el tiempo de entrega de nuevas funciones de meses a semanas.

¿Cuál es el futuro de Agile?

La pandemia de COVID-19 creó una nueva realidad en la que los equipos ya no podían compartir la ubicación, que era la forma preferida de trabajar dentro de Agile cuando se concibió. Sin embargo, la idea de que debe seguir siendo así es un mito: a medida que el trabajo remoto se ha convertido en algo común, queda claro que la comunicación cercana es completamente posible con el software de videoconferencia. Los equipos con los que estoy trabajando ahora están completamente distribuidos y estoy impartiendo capacitación de forma remota. Algunos equipos incluso optan por trabajar de forma asincrónica, utilizando herramientas como Notion y Loom, así como complementos de Slack como Standuply.

El modelo distribuido de colaboración es el nuevo mundo del trabajo, con la agilidad en su centro. El equilibrio entre el trabajo y la vida que se brinda a los equipos remotos tiene un impacto positivo en la moral y el bienestar mental, lo que aumenta la productividad y la calidad; pone a las personas por encima de los procesos y es flexible y adaptable, lo que lo convierte en ágil por excelencia.

Los entrenadores ágiles, los maestros de Scrum y los gerentes de proyectos deben volver a las raíces de la filosofía y presentarla como lo hicieron los redactores del manifiesto: un conjunto flexible y dinámico de pautas de desarrollo y entrega. Deben enseñar a los ejecutivos y líderes de equipo que, si bien pueden inspirarse en la gestión de proyectos, en realidad no están administrando nada en Agile: están guiando a los equipos y liberándolos para que hagan su mejor trabajo.