Este principio incluye tres puntos principales. El primero es satisfacer al cliente. Si producimos planes y documentación perfectas, pero sólo deleitamos a la oficina de gestión de proyectos (PMO) o al grupo de aseguramiento de la calidad (QA), hemos fracasado, nuestra atención debe centrarse en el cliente.

El segundo punto es la entrega temprana y continua. Debemos estructurar el proyecto y al equipo de desarrollo para que ofrezcan valor temprano y con frecuencia. Esto puede ser difícil si la gente es reacia a entregar trabajo incompleto, y hace falta valor y apoyo para que todos se sientan cómodos con esta idea. Sin embargo, debemos llegar a este punto, si queremos enterarnos de los problemas cuando aún estamos a tiempo de solucionarlos. Es mejor equivocarse desde el principio y tener tiempo para corregirlo que descubrir el problema mucho más tarde, cuando ya se ha construido mucho más sobre una base defectuosa.

El punto final es que lo que estamos entregando es software valioso (es decir, sistemas), no productos de trabajo semiterminados, elementos de la EDT, documentación o planes. Debemos centrarnos en el objetivo final. En el caso de los proyectos de software, se trata del software; en otros tipos de proyectos, el objetivo final será el producto o servicio que el proyecto pretende ofrecer o mejorar.

Los cambios pueden ser magníficos para un proyecto, por ejemplo, si nos permiten ofrecer una función de última hora y alta prioridad. Sin embargo, en los proyectos no ágiles, los cambios se ven a menudo de forma negativa; pueden considerarse "ampliación del alcance" o culpables de que el proyecto se desvíe del plan. En muchos proyectos no ágiles, los procedimientos de control de cambios son tan rigurosos que sólo se aceptan los más prioritarios. En esos proyectos, gran parte del tiempo y el esfuerzo se dedican a registrar y gestionar las solicitudes de cambio.

Este tipo de gestión rigurosa del cambio es problemático para cualquier proyecto en un entorno altamente cambiante, como el desarrollo de software, por lo que la metodología ágil acepta que se produzcan cambios. De hecho, la metodología XP aboga por que "abracemos el cambio".

En lugar de crear un mecanismo muy complejo para suprimir o procesar los cambios, los métodos ágiles utilizan un enfoque ligero y de alta visibilidad, por ejemplo, actualizando y priorizando continuamente los cambios en la lista de tareas pendientes. Los métodos ágiles, bien entendidos y de gran visibilidad para gestionar los cambios mantienen el proyecto adaptable y flexible el mayor tiempo posible. Si aceptamos los cambios que inevitablemente se producirán y establecemos una forma eficaz de gestionarlos, podremos dedicar más tiempo a desarrollar el producto final.

A pesar de nuestras mejores intenciones y de saber que los primeros comentarios son valiosos, es humano querer que nuestro trabajo esté lo más completo posible antes de compartirlo. Sin embargo, nos hacemos un flaco favor a nosotros mismos si retenemos nuestro trabajo durante demasiado tiempo. Es mejor recibir comentarios pronto y a menudo, para evitar ir por mal camino.

Este principio subraya la importancia de poner el trabajo en un entorno de pruebas y recibir comentarios. Las pruebas frecuentes y la retroalimentación son tan importantes que los desarrolladores de software utilizan herramientas de integración continua para proporcionar retroalimentación sobre cualquier código que hayan escrito y que rompa la compilación. Los equipos ágiles necesitan información sobre lo que han creado hasta el momento, para saber si pueden continuar o si es necesario cambiar de rumbo.

Entregar en un plazo breve también tiene la ventaja de mantener el compromiso del propietario del producto y el diálogo sobre el proyecto. Con entregas frecuentes, tendremos regularmente resultados que mostrar al cliente y oportunidades de obtener su opinión. A menudo, en estas demostraciones nos enteramos de nuevos requisitos o cambios en las prioridades de la empresa, que constituyen valiosas aportaciones para la planificación.

Las frecuentes demostraciones mencionadas anteriormente son un ejemplo de cómo los representantes del negocio y los desarrolladores trabajan juntos a lo largo del proyecto. El contacto diario cara a cara con el cliente es uno de los principios más difíciles de garantizar desde el punto de vista práctico, pero merece la pena presionar para lograrlo. Los documentos escritos, los correos electrónicos e incluso las llamadas telefónicas son formas menos eficientes de transferir información que las interacciones cara a cara.

Trabajar a diario con representantes del negocio nos permite conocerlo mucho mejor que lo que se puede lograr con una serie de reuniones de recopilación de requisitos. Así que de esta manera podemos proponer mejor soluciones y alternativas a los requisitos de la empresa. Los representantes de la empresa también aprenden qué tipos de soluciones son caras o lentas de desarrollar, y qué características son baratas. Con este conocimiento ellos pueden empezar a afinar sus requisitos.

Cuando no es posible mantener interacciones diarias entre los representantes de la empresa y el equipo de desarrollo, los métodos ágiles intentan que los dos grupos trabajen juntos con regularidad de alguna manera, quizá cada dos días o cualquier otro tipo de participación frecuente que funcione. (Los equipos ágiles utilizan un "cliente proxy", en el que un analista de negocio [BA] experimentado y familiarizado con los intereses de la empresa actúa como sustituto, pero no es la opción ideal).

Como veremos más adelante, los datos de estimación de software recopilados por el modelo COCOMO II han revelado que contar con las mejores personas es significativamente más importante para un proyecto que disponer de los mejores procesos y herramientas, por un factor de 10 a l. Por tanto, si nos aseguramos de contar con personas inteligentes y motivadas en el equipo, es probable que el éxito y la eficacia de nuestro proyecto dependan en gran medida de ello.

Aunque no siempre podamos elegir al equipo de nuestros sueños, podemos motivar y potenciar a los miembros del equipo que tenemos. Dado que el equipo de desarrollo es un factor tan importante, los métodos ágiles promueven los equipos capacitados. Las personas trabajan mejor cuando se les da autonomía para organizar y planificar su propio trabajo. Los métodos ágiles abogan por liberar al equipo de la microgestión de completar tareas en un diagrama de Gantt. En su lugar, se hace hincapié en la artesanía, la colaboración entre iguales y el trabajo en equipo, lo que se traduce en mayores índices de productividad.

Los proyectos de trabajo intelectual implican a miembros del equipo que tienen áreas de especialización únicas. Estas personas hacen su mejor trabajo cuando se les permite tomar muchas de las decisiones cotidianas y la planificación local del proyecto. Para los líderes, esto no significa abdicar de su participación o abandonar al equipo a su suerte, sino que reconocemos que los miembros de nuestro equipo son expertos en lo que hacen y les proporcionamos el apoyo que necesitan para garantizar su éxito.

Los documentos escritos son excelentes para crear un registro duradero de acontecimientos y decisiones, pero su elaboración es lenta y costosa. En cambio, la comunicación cara a cara nos permite transmitir rápidamente mucha información de una forma más rica que incluye las emociones y el lenguaje corporal.

En una conversación cara a cara, las preguntas pueden responderse inmediatamente, en lugar de "estacionarse" con la esperanza de que haya una explicación posterior, o de que la respuesta se aclare más tarde. Por ejemplo, si en lugar de que una persona lea este capítulo, ella hablara directamente con un experto en la materia, se podrían saltar rápidamente todo lo que esa persona ya sabe, y se podrían enfocar en las áreas sobre las que se esa persona necesite aprender más. Los documentos escritos tienen que asumir un punto de partida más bajo para poder cubrir un público más amplio.

Por supuesto, esta recomendación de conversaciones cara a cara no puede aplicarse a todas las comunicaciones de un proyecto, pero los equipos ágiles intentan seguirla siempre que sea posible. Este es un ejemplo de cómo los métodos ágiles deben personalizarse o adaptarse a cada proyecto, balanceando las comunicaciones cara a cara, e introduciendo un nivel adecuado de documentación escrita.

Al adoptar el "software en funcionamiento" (o "sistemas en funcionamiento") como medida primaria de progreso, cambiamos nuestra perspectiva y nos centramos más en los resultados de trabajo que en la documentación y el diseño. En la metodología ágil, evaluamos el progreso basándonos en el producto o servicio emergente que estamos creando. Preguntas como "¿Qué parte de la solución está hecha y aceptada?" son preferibles a "¿Está completo el diseño?", ya que queremos centrarnos en la usabilidad y la utilidad más que en el progreso conceptual.

Expresiones como "Lo que mides (pruebas), es lo que está terminado" y "Lo que obtienes como terminado es lo que has medido (probado)" son aplicables en este caso, ya que la medición refuerza la característica de funcionalidad. Si una función no puede medirse o probarse, es decir, si no "funciona", no se considera completa. Este énfasis en un producto que funcione ayuda a garantizar que el cliente acepte las funciones, en lugar de marcar los elementos como "desarrollo finalizado" cuando aún no se han aceptado como "terminados".

Esta definición del progreso como "sistemas de trabajo" crea una visión del proyecto orientada a los resultados. Los entregables provisionales y el trabajo parcialmente completado no obtendrán ningún reconocimiento externo. Por tanto, debemos centrarnos en el objetivo principal del proyecto: un producto que aporte valor a la empresa.

Los métodos ágiles tratan de maximizar el valor a largo plazo. Muchas de las técnicas de desarrollo rápido de aplicaciones (RAD) que precedieron a los métodos ágiles promovían -o al menos aceptaban- largos e intensos periodos de creación de prototipos antes de las demostraciones. El problema del enfoque RAD, consistente en trabajar en equipo durante muchas horas y mucho tiempo, es que la gente empieza a agotarse y a cometer errores. No es una práctica sostenible.

En lugar de largos e intensos periodos de desarrollo, los métodos ágiles reconocen el valor de un ritmo sostenible que permita a los miembros del equipo mantener un equilibrio entre trabajo y vida privada. Un ritmo sostenible no sólo es mejor para el equipo, sino que también beneficia a la organización. Las largas jornadas de trabajo provocan deserciones, lo que significa que la organización pierde talento y conocimientos valiosos. Contratar e integrar a nuevos miembros en un equipo es un proceso lento y costoso.

En cambio, trabajar a un ritmo que pueda mantenerse indefinidamente genera un equipo más feliz y productivo. Los equipos felices también se llevan mejor con los representantes de la empresa que los equipos con exceso de trabajo. Hay menos tensión y las relaciones de trabajo mejoran. Algunos métodos ágiles, como XP, recomendaban anteriormente mantener una semana laboral regular de 40 horas como principio rector. Hoy en día, la mayoría de los métodos no establecen límites específicos, pero sí recomiendan prestar mucha atención al nivel de esfuerzo que realiza el equipo para garantizar un ritmo sostenible.

Aunque queremos que el equipo de desarrollo trabaje duro y aporte mucho valor, también tenemos que ser conscientes de que el diseño debe ser limpio, eficiente y abierto a los cambios. La excelencia técnica y un buen diseño permiten al equipo de desarrollo comprender y actualizar el diseño con facilidad.

Un equipo ágil necesita equilibrar sus esfuerzos para ofrecer características de alto valor con una atención continua al diseño de las soluciones. Este equilibrio permite que el producto aporte valor a largo plazo sin que resulte difícil de mantener, cambiar o ampliar. Es preferible la limpieza y el mantenimiento preventivo a tener que solucionar problemas. Esto ayuda a que el proyecto se desarrolle sin problemas y acelera el progreso del equipo.

En el mundo del software, una vez que el código base se enreda, la organización pierde su capacidad de responder a las necesidades cambiantes. En otras palabras, pierde agilidad. Por eso hay que dar al equipo de desarrollo tiempo suficiente para acometer la refactorización del código. La refactorización es la limpieza y simplificación que hay que hacer en el código para garantizar su estabilidad y mantenimiento a largo plazo.

Las funciones más fiables son las que no construimos, ya que no hay nada que pueda ir mal con ellas. Y, en el mundo del software, hasta el 60% de las funciones que se construyen se utilizan con poca frecuencia o nunca. Dado que muchas de las funciones que se construyen no se utilizan nunca y que los sistemas complejos tienen un mayor potencial de ser poco fiables, los métodos ágiles se centran en la simplicidad. Esto significa reducir los requisitos a sus elementos esenciales.

Los proyectos complejos tardan más en completarse, están expuestos a un horizonte de riesgo más largo y tienen más puntos potenciales de fallo y oportunidades de sobrecostes. Por eso, los métodos ágiles buscan "lo más sencillo que pueda funcionar" y recomiendan construir primero esa solución. Este planteamiento no pretende impedir que se amplíe y elabore el producto, sino que simplemente dice: "Construyamos primero la versión sencilla".

Este principio puede sonar extraño, dependiendo de cómo se lea literalmente. En esencia, viene a decir que, para sacar lo mejor de las personas, hay que dejar que se autoorganicen. A la gente le gusta autoorganizarse; le permite encontrar el enfoque que mejor se adapta a sus métodos, sus relaciones y su entorno. Comprenderán y apoyarán el enfoque porque han contribuido a crearlo. El resultado será un trabajo mejor

Sin embargo, es posible que se pregunte por qué este principio dice que las mejores arquitecturas, requisitos y diseños provienen del equipo del proyecto, en lugar de los mejores arquitectos, analistas de negocio y diseñadores de la organización, que pueden no estar en el equipo. La respuesta a esta pregunta es que nuestras arquitecturas, requisitos y diseños funcionan mejor cuando los ponen en práctica quienes los originan. Aunque las recomendaciones externas puedan tener más mérito técnico sobre el papel, si se aplican de forma distinta a la prevista originalmente, o sin el convencimiento del equipo, a la larga tendrán menos éxito.

Otro factor que apoya este principio es que los miembros de un equipo de proyecto autoorganizado son los que están más cerca de los detalles técnicos del proyecto. Por tanto, son los más capacitados para detectar problemas de ejecución y oportunidades de mejora. Así, en lugar de tratar de educar a personas externas sobre la estructura evolutiva del proyecto, los métodos ágiles aprovechan la capacidad del equipo para diagnosticar y mejorar de la mejor manera posible las arquitecturas, requisitos y diseños del proyecto. Al fin y al cabo, los miembros del equipo son los más informados sobre el proyecto y los más comprometidos con él.

Recopilar las lecciones aprendidas al final de un proyecto es, francamente, demasiado poco y demasiado tarde. En lugar de eso, tenemos que recopilar las lecciones aprendidas cuando aún son aplicables y procesables. Esto significa que tenemos que recopilarlas durante el proyecto y, lo que es más importante, asegurarnos de que hacemos algo con lo que hemos aprendido para ajustar la forma en que completamos el resto del proyecto.

Los métodos ágiles emplean revisiones frecuentes, llamadas "retrospectivas", para reflexionar sobre cómo están funcionando las cosas en el proyecto e identificar oportunidades de mejora. Estas retrospectivas suelen hacerse al final de cada iteración, lo que garantiza que el equipo tenga oportunidades periódicas de revisar su proceso. Una ventaja de hacer retrospectivas con tanta frecuencia es que no nos olvidamos de los problemas y las cuestiones. Esto es más efectivo comparado con una única revisión de las lecciones aprendidas al final de un proyecto, en la que se pide a los miembros del equipo que recuerden durante un año o más lo que les fue bien y los problemas que tuvieron.

Otra desventaja de recopilar las lecciones aprendidas sólo al final de un proyecto es que éstas no serán realmente útiles para la organización hasta que llegue otro proyecto con un dominio empresarial o técnico o una dinámica de equipo similares. Y en ese momento, es fácil descartar las lecciones aprendidas en un proyecto anterior por no ser aplicables a la situación actual. En un proyecto ágil, captamos las lecciones aprendidas a medida que avanza el proyecto, por lo que no podemos fingir que no son aplicables. Sabemos que son relevantes, y estamos motivados para afinar y ajustar nuestro proceso en consecuencia.