Últimamente, en las organizaciones que han adoptado métodos ágiles se escuchan con demasiada frecuencia afirmaciones que empiezan con “Como somos ágiles…”. Normalmente hay que echarse a temblar ante lo que viene después: “Como somos ágiles no documentamos”, “como somos ágiles no hace falta planificar”, “como somos ágiles no seguimos estándares”, “como somos ágiles, desplegamos, aunque no esté probado, el software”, “como somos ágiles no tenemos requisitos”, y un largo etcétera.
Como comentaba en un post anterior, parece que estamos viviendo una moda repentina por la adopción de métodos ágiles pero, como toda moda, hay quien la adopta con convencimiento y quien se conforma con seguir una convención estética. Desperdiciar la oportunidad de ser verdaderamente ágiles para quedarse solo en lo superficial es un enorme desperdicio. Quienes lo hacen así se exponen a invertir recursos y tiempo en aplicar nominalmente unas técnicas que podrían resolver sus problemas, pero acaban volviendo al insatisfactorio estado anterior… hasta la próxima moda.
Son los mismos que piensan que la agilidad es un “todo vale” y que ágil es solo rápido, aunque en su caso este “rápido” quiere decir sin orden ni concierto, para cumplir fechas como se pueda pero sin atender al contenido. Trataré de aclarar qué es y qué no es “ágil” y empezaré desmontando un mito: será una moda, pero no estamos hablando de algo realmente nuevo.
Los métodos ágiles tratan de dar respuesta a los problemas históricos del desarrollo de proyectos, cuya raíz está en la incertidumbre. Por eso, la primera reacción siempre ha sido incrementar el control: contar con requisitos detallados desde el primer momento, usar técnicas para valorar la complejidad del trabajo y estimar el esfuerzo necesario y disponer de herramientas que controlen el proceso y midan la calidad. Sin embargo, esta aproximación falla por la base: apenas hay proyectos software en los que los requisitos sean completos y estables antes de empezar el trabajo; las estimaciones siguen llenas de errores; las herramientas no han mejorado por sí solas la contribución de las personas al trabajo.
Así que cincuenta años después de la primera gran iniciativa para atajar estas dificultades, los proyectos siguen terminando fuera de plazos y coste, sin cumplir las expectativas de los clientes y sin mejoras apreciables en la calidad… hasta que llegaron los métodos ágiles.
En 1986, Takeuchi y Nonaka describieron una forma de trabajo en la que un equipo transversal aborda las distintas fases de la misma forma que los jugadores de rugby afrontan una melee (scrum en inglés): empujando con decisión y al unísono. Esta idea se trasladó a la industria del software y en 1995 se empezó a formalizar en artículos y libros. La gran diferencia con respecto a la forma de trabajar anterior es que se renuncia a unos requisitos de partida completos y estables, se trata de convivir con el cambio y la incertidumbre. Los requerimientos pueden evolucionar y el proceso se adapta a trabajar con esa variabilidad. En lugar de rechazar los cambios, se consideran algo natural y saludable.
El “Manifiesto Ágil”, publicado en 2001, plasma en cuatro puntos esenciales las ideas y el sentir general de esta comunidad:
-Valorar a los individuos y sus iteraciones frente a procesos y herramientas. Tenemos que reconocerlo: un proyecto es, en gran medida, una serie de iteraciones entre personas que dan lugar a un producto.
-Valorar más el software (producto) que funciona, que una documentación exhaustiva. Se trata de poner las cosas en su sitio y evitar la tentación de dar demasiada importancia al proceso de sacar adelante un producto (encarnado en la documentación), frente a lo realmente importante, que es el objeto del proyecto: el producto.
-Valorar más la colaboración con el cliente que la negociación de un contrato. La forma más productiva de sacar adelante un trabajo es establecer un marco de confianza y colaboración con quien lo encarga. Lo contrario son los contratos defensivos que tanto abundan en la industria.
-Valorar más la respuesta al cambio que el seguimiento de un plan. Ya lo hemos dicho: asumimos la incertidumbre y abrazamos el cambio. Los planes son necesarios, pero se deben poder cambiar.
Todo esto está muy bien, pero entonces ¿dónde queda la rapidez?
En la forma tradicional de abordar proyectos software se parte de una suposición irreal: el cliente sabe exactamente y de antemano qué es lo que quiere, y el equipo estima el esfuerzo y tiempo necesario.
Admitámoslo: eso no ha ocurrido (casi) nunca. En realidad el cliente tiene una serie de ideas con un nivel irregular de detalle de lo que quiere, y será durante el proceso de construcción, y a medida que vaya interactuando con el producto, cuando comprenda exactamente qué es lo que quiere obtener al final del proceso. Lo mismo ocurre con el equipo de trabajo: se trata de un proceso de aprendizaje y descubrimiento mutuo. El cliente va descubriendo el producto que quiere, a la vez que el equipo descubre qué es en realidad lo que lucha por salir de la cabeza del cliente.
Este proceso de descubrimiento solo puede ser progresivo y adaptativo a partir de las tres únicas certezas de todo proyecto: para cuándo se quiere y con qué recursos se cuenta. La tercera, que no depende de ningún elemento externo y es inamovible, es la calidad, que debe ser siempre máxima e indiscutible.
Así que ágil quiere decir además flexible y con calidad: no partimos de axiomas rígidos, sino que hay una constante evolución y adaptación. El producto va agregando capacidades que se evalúan para asegurar que se está siguiendo el camino deseado. Para reducir la incertidumbre, se fragmenta en pequeños ciclos de construcción, evaluación y análisis. Se prioriza para centrar el esfuerzo en lo verdaderamente importante. Y se revisa continuamente para mejorar la forma de trabajo y hacerla más eficiente y productiva.
Ágil es flexible… pero lo cierto es que “ágil” es también “veloz”. Ahora bien, la velocidad no está en simplificar procedimientos, ahorrarse formalidades o saltarse indiscriminadamente elementos básicos de cualquier proyecto como planificar, elaborar adecuadamente el trabajo o no escatimar en calidad.
¿Dónde está la clave entonces? Hemos hablado de priorizar, de calidad y de mejora continua. Todo ello define una forma productiva de trabajo, y ser más productivos es una forma de liberar antes el producto que queremos. Veamos cómo.
Priorizar es una forma fundamental de concentrar esfuerzos en lo esencial y dejar para otra ocasión lo accesorio: si queremos que nuestra tienda web permita comprar productos, ya llegará más adelante el momento de compartirlo en las redes sociales. ¿Necesitamos que desde el principio estén presentes todas las sofisticadas funcionalidades de un producto? ¿No es mejor garantizar que está al menos lo imprescindible para cumplir su cometido básico? Priorizar es una forma de eliminar aquello que es superfluo y centrarse en lo realmente necesario. Y esto es una forma de productividad, porque permite obtener el máximo valor con el esfuerzo disponible, y es una forma de acelerar: el producto cumplirá su cometido básico sin aditamentos ni florituras para llegar lo antes posible al mercado, donde recibirá el feedback de sus clientes, y esto generará nuevos requisitos y mejoras.
La calidad también permite ganar velocidad. Corregir un problema de diseño es muy rápido cuando se está ideando el producto y muy costoso y posible fuente de introducción de otros errores cuando está implementado.
¿Parece una pérdida de tiempo dedicarse a probar y corregir el producto en construcción? Pruebe a arreglar errores cuando está en manos de los usuarios.
El esfuerzo y tiempo necesario para solventar errores se dispara a medida que se avanza en las etapas de construcción y es máximo con el producto desplegado.
La mejora continua, una de las actividades básicas de todo método ágil, también permite optimizar, mejorar la forma de trabajo, reducir actividades innecesarias… lo que se traduce en mayor productividad y satisfacción del equipo de trabajo. Porque ¿quién quiere trabajar de forma no productiva, sentir que pierde el tiempo? Las personas que sienten que su trabajo merece la pena, que tiene utilidad y no se desperdicia su tiempo y su esfuerzo son personas productivas, y por ello también veloces.
El orden que impone un método ágil también implica mejoras en la velocidad: equipos que trabajan al unísono y empujan en la misma dirección, con ritmos constantes y conocidos, con las mínimas reuniones o “ceremonias” necesarias que conforman un entorno familiar y estable. Nada que ver con la “rapidez” que se usa como excusa para trasladar la “prisa” por obtener resultados, que solo resulta en desorden y desconcierto. Ese orden, aunque pueda parecer superficial, se interioriza, no se impone ni abruma como en un método tradicional, y contribuye a incrementar la velocidad.
En conclusión, los métodos ágiles no aportan rapidez, sino que son sinónimos de flexibilidad y velocidad. Y alguien se preguntará ¿y no es lo mismo velocidad que rapidez? Pues no, hay un matiz muy importante: “veloz” implica una medida, “rápido” transmite solo una sensación. La agilidad se puede medir y, por eso, puede poner foco en la productividad. La eliminación del desperdicio, la mejora continua, centrarse en lo fundamental es cuantificable y, lo que es más importante, se puede comparar para que el incremento de velocidad sea tanto el hilo conductor como el resultado buscado de la mejora continua.
Así que, por favor, cuando se aplique Scrum, Kanban, Lean o cualquier otro de los métodos ágiles, debe hacerse con pasión, con interés y con determinación para obtener sus verdaderos beneficios, no solo una etiqueta que sirva para unirse al viento de la moda de management de turno.
Se trata de poder decir “Como somos ágiles… documentamos para mejorar la calidad de nuestras entregas”, “como somos ágiles… planificamos para saber ser flexibles frente a los cambios”, “como somos ágiles… seguimos estándares para mejorar la ’mantenibilidad’ y calidad del producto”, “como somos ágiles… desplegamos cada vez más rápido software probado y mejorado en cada entrega”, “como somos ágiles… tenemos requisitos pero no nos cuesta cambiarlos”.
Como somos ágiles… somos flexibles y veloces construyendo productos con la máxima calidad.
Imagen: kentoh/shutterstock
Soluciones y Sectores
Te puede interesar
-
Telefónica Empresas en Advanced factories: sus fortalezas en Industria 5.0
Junto con el Mobile World Congress, Advanced Factories es cita obligada de Telefónica Empresas en el contexto de transformación ...
-
5G en logística: aplicaciones y beneficios
5G en el sector logístico resulta un gran aliado para acelerar la transformación de las empresas del sector. Ya ...
-
NB-IoT, una tecnología madura más allá del sector del agua
El pasado 11 de marzo Canal de Isabel II celebró, junto a los principales operadores de telecomunicaciones -Telefónica entre ...
