Introducción

En esta serie de artículos trataré de ser lo más sintético posible para no aburrir con la lectura.

Voy a escribir sobre hechos que he vivido y personas con las que he tenido el honor de interactuar, trabajar y aprender.

La intención de escribir estos artículos no es abrir un debate. Tomando al Martín Fierro (1) diré que lo hago porque creo, con toda humildad, que “si hablo de este modo por encontrarlo oportuno, no es para mal de ninguno, sino para bien de todos”.

La Teoría del Todo.

Nadie es dueño de la verdad. “La verdad no es nada más que, simplemente, un prototipo de nuestra mente” alguien escribió. La noción y el significado de los términos ágil y agilidad se han enfrentado a esta situación durante años.  De la definición tradicional (de acuerdo con el diccionario de la RAE – Real Academia Española) donde ágil se define como algo “capaz de moverse con soltura y rapidez. Rápido, inteligente, astuto” y la agilidad se define como “la calidad o el estado de ser ágil” ambas palabras tienen definición propia, inmediata y personal para casi todo el mundo.

Como escribí en el primer artículo de esta serie de entregas Ágil y agilidad nacieron como alternativa superadora a Lean (2) tratando de encontrar una solución a la necesidad de encontrar una manera de lograr la supervivencia de la organización. Como dijo Charles Darwin “en la lucha por la supervivencia prevalecen los que logran adaptarse al entorno cambiante”. Esto no es nuevo. Desde los primeros humanos agrupados para un propósito, las organizaciones han existido en un entorno cambiante que requería adaptación, dónde adaptación significa “moverse con soltura y rapidez” de un estado actual a otro estado de deseado para sobrevivir, crecer y desarrollarse. Es decir transformarse. Ágil y agilidad tienen que ver con eso. Todos somos ágiles desde que la primera especie apareció en este planeta. Primer tema importante de entender para desmitificar varias de las definiciones de ágil y agilidad que se encuentra por ahí.

El uso de esos términos en el contexto de la organización se denominó agilidad organizacional o Agile Enterprise. Nacieron en el USA DoD/NSF Agility Forum en 1990 a partir de predicciones que se basaban en observaciones sobre que el entorno empresarial se estaba volviendo menos estable, que las fuerzas impulsoras hacia una mayor incertidumbre se estaban acelerando y que las organizaciones debían estar equipadas para operar en esas condiciones. Se pensó entonces en un horizonte de 25-30 años hacia adelante para generar un nuevo modelo de organización y se definió Ágil como “Una forma de pensamiento y acción cuyo foco es el incremento del valor para el cliente y la calidad”. Una definición que asumía tener ya lista la definición de “cliente”, “valor” y “calidad” tomando desde la Teoría de la Calidad la que mejor se adaptaba a la situación organizacional actual pensando en la situación organizacional deseada en el futuro.

Pero al mismo tiempo, como escribí en el segundo capítulo de esta serie de entregas, se generaban algunas iniciativas para crear una comunidad de práctica que resolviese el mismo problema aplicado en el entorno que se consideraba el habilitador de negocios clave en el futuro: el desarrollo de productos y soluciones basadas en software. La OOSPLA (3) fue la usina generadora de ideas, prácticas, métodos, enfoques, marcos, etc. que derivó en el acuerdo que se plasmó en el Manifiesto para el Desarrollo de Software Ágil (4).

Todo esto nace porque se había reconocido que, centrarse en prácticas comerciales específicas para ser más competitivos y flexibles para reaccionar a los cambios ambientales, no sería suficiente en ese nuevo mundo futuro de 25-30 años hacia adelante. La flexibilidad se conseguía, entre otras cosas, en capturar la reducción del tiempo de ciclo, la personalización masiva, las empresas virtuales, la reingeniería de procesos, la organización del aprendizaje, la capacitación y la educación sistémicos, la productividad de los recursos. Básicamente Lean (2) representaba el marco que brindaba la flexibilidad necesaria basada en esos puntos. Flexibilidad a nivel organizacional significa “Reaccionar ante situaciones esperadas e hipotéticas.”.  Ser flexible permite el éxito cuando ocurren eventos hipotetizados o cojeturados dónde de algún modo se hizo una planificación previa para poder enfrentarlos.

Pero la flexibilidad no es agilidad.

También en el USA DoD/NSF Agility Forum agilidad se definió como “Reaccionar ante una gran variedad de eventos inesperados (reactivo) y crear eventos inesperados (proactivo).”.  Ser ágil permite el éxito  al enfrentar circunstancias inesperadas y no planificadas. Como Rick Dove, líder del Agility Forum, escribió “la agilidad convierte ese futuro inesperado y no planificado, que podría ser considerado un enemigo, en una oportunidad”.

Lo que hace la diferencia en el enfoque que tomaron el Agility Forum y los “Trabajadores del Software” es la consideración temprana de un factor crítico de éxito para obtener agilidad organizacional mediante la implementación del concepto Ágil: el uso del pensamiento sistémico para considerar a la organización como un sistema adaptable y abierto.

La necesidad de utilizar la Teoría General de los Sistemas (5) para la gestión de la organización fué el resultado de las organizaciones que trataron de adaptarse a los rápidos cambios en el entorno empresarial relacionados con los cambios tecnológicos, económicos y sociales en la segunda mitad del siglo XX. Los sistemas son necesarios y son creados para apoyar la estrategia de la organización poniéndola en acción. Las personas, los procesos y la información trabajan juntos para apoyar las funciones empresariales que son el medio para responder al estímulo ambiental. Para lograr esto los sistemas tienen que ser independientes pero altamente cohesivos, compartiendo información consistente y colaborando para apoyar los objetivos de la organización. Por eso es fundamental tener en cuenta los componentes y las relaciones lo que significa tener en cuenta la arquitectura empresarial.

La agilidad permite a una organización hacer cualquier cosa que quiera hacer, cuando quiera o tenga que hacerlo. Se puede ejercer repetidamente como una estrategia de negocio, así como inherentemente una competencia de existencia sostenible. La base de la agilidad organizacional es la capacidad de responder y crear cambios ambientales (lo que Rick Dove llamó “Response Ability” (6) (“Capacidad de Respuesta”)) mediante la creación de estructuras adaptables y el uso del conocimiento organizacional. Lo que alguna vez tuve la oportunidad de presentar en algunos congresos “Arquitectura Lego®”.

Para entender la diferencia entre flexible y ágil permítanme utilizar el deporte. En algunos deportes es suficiente con ser flexible (o al menos la relación entre flexible y ágil es altamente favorable a flexible) porque el entorno es suficientemente estable en el sentido que los cambios no son inesperados y no planificados. Pero en otros, la situación cambia. Voy a tomar el tenis, mi otra pasión, lo que más he investigado y estudiado al margen de dedicarme plenamente a su práctica y enseñanza, al punto de compromiso personal de haber sido ex jugador ATP y haberme certificado y trabajado como entrenador de nivel Profesional I acreditado por la UPSTA, ITF y AAT.

Piensen en los mejores tenistas del mundo como Novak Djokovic, Roger Federer, Rafael Nadal, Andy Murray y otros. Si prestan atención cuando los ven jugando un partido de tenis y ven que siempre están en el lugar correcto con un mínimo esfuerzo posiblemente, la mayoría de las veces, Uds. quizá piensen "es increíble. Parece que la pelota va directamente al lugar donde están". Lo que podría ser obvio es que el nivel de condición física y fuerza, que hace que sus estructuras corporales sean "capaces de moverse con soltura y rapidez", les permite jugar así. Pero lo que generalmente no es obvio es que están aplicando sus conocimientos ("rápido, inteligente, astuto") para crear el futuro mediante el uso del golpe correcto para obtener la siguiente bola del oponente, la respuesta, en la dirección y el lugar que quieren. Y por si acaso la situación de juego actual no les permite hacer eso utilizan sus conocimientos para anticiparse a la respuesta del rival.

Cuando las organizaciones logran la agilidad organizacional se enfrentarán a la misma situación debido a la reconfiguración de las estructuras organizacionales y la capacidad de encontrar formas adecuadas de aplicar sus conocimientos. Y no depende de la estructura. O acaso un luchador de Sumo no es ágil?. Y cuando hablo de organización nuevamente hago énfasis en la organización como sistema dónde cada componente y sus relaciones trabajan por igual hacia el objetivo. Cuando esto no se entiende, cuando no se entiende que “cualquier cosa” que se incorpora al sistema impacta a la totalidad, se empiezan a buscar alternativas de solución para mejorar el deterioro del sistema, tales como algunas que entran dentro de la categoría de métodos o marcos (frameworks) para escalar.

Algunos conceptos adicionales basados en la experiencia.

Ahora permítanme escribir algunas líneas de algunos temas claves que a mí me ayudaron a implementar Ágil para lograr las transformaciones necesarias y lograr agilidad que tal vez ayudará:

• Tener una comprensión clara sobre qué es Ágil. Hay muchos malentendidos en el mercado. Algunas personas piensan que Ágil es un conjunto de métodos o metodologías, algunas personas piensan que Ágil está solamente destinado a la creación productos de software o TI, algunas personas piensan que Ágil se define por de Manifiesto para el Desarrollo de Software Ágil (4), algunas personas piensan que Ágil no es compatible con el concepto de proyecto / programa / portafolio que muchas de las organizaciones han definido, y así siguiendo. El primer desafío es generar una comprensión clara sobre Ágil en todos los niveles dentro de la organización. Créanme, es un trabajo duro de hacer.

• Evaluar el impacto de implementar Ágil. Como otras iniciativas, Ágil transformará la estructura organizativa o arquitectura empresarial. Como mencioné antes, todos los componentes de la organización y sus relaciones se verán afectados.  Como todo emprendimiento que se realiza en busca de una solución debería comenzar con un análisis entre la arquitectura empresarial actual (que refleja la estrategia actual) y la arquitectura empresarial futura deseable (que se pondrá en marcha de acuerdo con la estrategia futura que incluye la estrategia empresarial Ágil). Esta es la clave para encontrar las necesidades que son la base para definir la situación problemática a resolver cuando se realiza la transformación necesaria para ganar agilidad organizacional mediante la implementación de Ágil.

• Hacer la transformación por evolución no por revolución. Lo peor que se puede hacer es tratar de poner todo esto en su lugar creando una revolución en la organización, donde revolución significa "transformar todo lo necesario de una sola vez". Hay mucho dentro de la organización que se puede reutilizar o se puede aprovechar para pasar al nuevo estado. Principalmente conocimiento organizacional que es uno de los pilares de Ágil. Las revoluciones son siempre “sangrientas”.

• Recordar: "la agilidad no viene en una lata" como escribió Rick Dove (6) .  En mi opinión, lo peor que se puede hacer es seguir algún tipo de “receta” tratando de copiar exactamente aquello que funcionó en otro lado. Debería ajustarse la implementación utilizando las herramientas, métodos y técnicas que mejor se adapten a su situación actual pensando en la situación futura a alcanzar.

• La cultura organizacional es el facilitador del cambio, pero debe recordarse que es un componente más dentro de la arquitectura empresarial. Una cosa importante a tener en cuenta es que nadie encontrará la cultura organizacional formalmente definida en un pedazo de papel. Dentro de la cultura organizacional he visto y experimentado que el factor crítico de éxito para implementar Ágil y lograr agilidad es la confianza. En mi experiencia personal utilizar la definición de Cliente como “el próximo en la cadena del proceso” de Richard Schomberger (7) junto con promover que cada componente de la arquitectura empresarial confíe en sí mismo y en su par puede definir una empresa ágil o no, más que ninguna otra cosa.

Conclusión Final sobre Ágil (Agile) y agilidad (agility).

Al final de día, si lo pensamos, nada nuevo bajo el sol.

Todo ocurre como en la vida misma.

Referencias

1. “El Gaucho Martín Fierro”, Martín Fierro - Wikipedia
2.  Womack, James P.; Jones, Daniel T.; Roos, Daniel (1990), Machine that Changed the World. New York: Rawson Associates, ISBN 9780892563500
3. Object-oriented Programming, Systems, Languages, and Applications (OOPSLA), Object-oriented Programming, Systems, Languages, and Applications (OOPSLA) (sigplan.org)
4.  Manifiesto por el Desarrollo Ágil de Software (agilemanifesto.org)
5. Von Bertalanffy, Ludwig (1976). Teoría general de los sistemas. Fundamentos, desarrollo, aplicaciones. México: Fondo de Cultura Económica. ISBN 9681606272.
6. Dove, Rick (2001), Response Ability: The Language, Structure, and Culture of the Agile Enterprise. New York: Willey, ISBN 9780471350187

7. Schonberger, Richard J (1986), The Lessons Of Simplicity Applied. New York: Free Press, ISBN 0029292700

Introducción

En esta serie de artículos trataré de ser lo más sintético posible para no aburrir con la lectura.

Voy a escribir sobre hechos que he vivido y personas con las que he tenido el honor de interactuar, trabajar y aprender.

La intención de escribir estos artículos no es abrir un debate. Tomando al Martín Fierro (1) diré que lo hago porque creo, con toda humildad, que “si hablo de este modo por encontrarlo oportuno, no es para mal de ninguno, sino para bien de todos”.

Resumen del Capítulo Uno: Génesis

En la entrega anterior escribí sobre la génesis de Agile (ágil) y agility (agilidad) que se dió en el marco del USA DoD/NSF Agility Forum en la Universidad de Leihigh en 1990 ante la necesidad de, tomando como base la teoría general de los sistemas aplicada a las empresas, identificar un problema emergente que fuese común y fuese clave para competir en el futuro (un horizonte de 25-30 años hacia adelante) y que se convertiría en el siguiente diferenciador, ya que una vez que Lean (15) se difundiera y se utilizara ampliamente dejaría de ser un diferenciador. Es decir, Agile nació como alternativa superadora a Lean.

En este capítulo escribiré sobre “el Mundo Paralelo” que se estaba desarrollando con el mismo fin: pensando en el cliente, cómo generar los productos con la calidad esperada para agregar el valor esperado y de esta forma diferenciarse para alcanzar los objetivos básicos de supervivencia, crecimiento y desarrollo.

Mundos Paralelos.

Sin intención de meterme con la historia de las computadoras, me permito decir que considero que la primera computadora apta para el uso comercial aparece entre 1950 y 1957. Pero es con la llegada de los lenguajes de programación, allá por 1960, dónde comienza a visualizarse a la computadora como herramienta para resolver el problema que se generaba en el ámbito empresarial debido al trabajo intensivo de realizar cálculos generalmente ligados a la administración de los negocios. Esos cálculos convertían datos en información que era clave para la toma de decisiones.

Las personas que trabajaban en los centros de cómputo entendían los cálculos (o al menos lo intentaban) y generaban una solución basada en software que los realizaba eliminando el trabajo intensivo.

Durante muchos años, quizá hasta mediados de los 80, el usuario final, el que esperaba recibir el resultado de los cálculos, no tenía posibilidad de interactuar con la máquina o, si lo hacía, solo podía ver el resultado final. Para utilizar una palabra de moda, hasta mediados de los 80, el usuario final no podía ser “empoderado” ya que el estado de la informática en su conjunto no lo permitía. Y los resultados obtenidos, la mayoría de las veces, no eran los esperados.

Por aquel entonces se escuchaban dos “frases célebres”: el usuario final decía “nunca recibo lo que necesito” y el personal del centro de cómputos decía “el usuario nunca sabe lo que quiere”. En definitiva, a diferencia de lo que pasaba con otros productos, en líneas generales no se lograba cumplir con los conceptos básicos de calidad. Al menos con entregar “lo que se espera y es apto para su uso” desde la percepción del usuario final.

El grupo de los trabajadores de los centros de cómputo que se dedicaba a generar los productos de software eran conscientes de que esa “grieta” entre lo que se obtiene y lo que se espera debía ser cerrada porque de esta forma no se liberaba el valor esperado. Comenzaron a pensar de qué manera, con los recursos informáticos disponibles, se podía imitar las mejores prácticas relativas a la calidad que se utilizaban en otros dominios tales como la manufactura. Y comenzó a tomar fuerza la idea de incorporar prácticas de la ingeniería para crear productos de software enfocados en liberar valor para el cliente final a través de lograr el nivel de calidad necesario.

Empezaron a descubrirse “nuevas formas de desarrollar software” a través de diferentes ciclos de vida (cascada, espiral, iterativo, etc.,) y nuevos métodos a partir de esos ciclos de vida (por ejemplo, Desarrollo Rápido de Aplicaciones, RAD (2) en inglés).

Acá una simple reflexión al margen. Se confunde ciclo de vida secuencial (sequential) con ciclo de vida cascada (waterfall) y este último se ha ganado muy “mala prensa”. Humildemente recomiendo buscar la publicación original de Royce (3) porque creo que muchos van a sorprenderse. O al menos, muchos dejarán de “pegarle palos” al ciclo de vida en cascada esgrimiendo razones muchas veces sin sustento y perdiendo oportunidades al utilizar otros ciclos de vida que no se ajustan al proceso de generar la solución esperada.

Nace la OOSPLA.

Cómo se sabe, la intención primaria de generar un producto de software es realizar modelos de la realidad. Ya muy temprano, allá por el año 1967, se comenzaron a generar leguajes de programación que permitieran modelar la realidad representándola a través de objetos, dónde los objetos son entidades que poseen comportamiento y características. Esta posibilidad, sumada a la evolución que había hecho la informática hacia las interfaces gráficas, las computadoras personales y los dispositivos tales como el ratón (mouse), permitió acercar al usuario final con los programadores para achicar la brecha que permitiera mitigar el “nunca obtengo lo que necesito” y “el usuario no sabe lo que quiere”. Es decir, todo lo relacionado a la orientación a objetos aparecía, sin duda, como la respuesta a la búsqueda de “nuevas formas de desarrollar software” con foco en el cliente.

En 1986 se realiza la primera conferencia de OOPSLA (4) (Programación, sistemas, lenguajes y aplicaciones orientados a objetos) que se llevó a cabo en Portland, Oregón. OOPSLA era una conferencia anual de investigación creada por el Grupo de Interés Especial para Lenguajes de Programación (SIGPLAN) que pertenece a la Asociación de Maquinaria de Computación (ACM) y fue la usina de todo lo relacionado a Agile y agility.

Ahí se debatía, se trabajaba, se vivía todo aquello que se visualizaba cómo el futuro de la generación de productos de software porque como alguien predijo en aquellos días “en el futuro, todas las empresas y organizaciones, sin importar el dominio en el que actúen o el producto o servicio que ofrezcan, serán empresas de tecnología y software”.

Todos aquellos que tuvimos la oportunidad de participar estábamos “codo a codo” con aquellos que hoy son considerados “cellebrities” del mundo Agile. Y todas esas personas estaban interesadas en la retroalimentación para aprender y mejorar y escuchaban y debatían cada punto que les acercábamos.

En la OOSPLA se generaron muchas de las cosas que son la base de todo lo que hoy se utiliza. Y pasar esto por alto, es el peor error que se puede cometer, en mi humilde opinión. Si me permiten, recomiendo enfáticamente leerlos. Cito algunos que me parecen un hito:

• Tom Gilb, considerado “el padre” de Agile, presenta su método EVO (5) mostrando el próximo paso hacia la creación de productos de software con foco en el cliente.
• Mary y Tom Poppendieck presentan “Lean Software Development” (6) que produce “un antes y un después” en los métodos de construcción de productos de software tomando las prácticas de calidad de “Lean Manufacturing” (15).
• Alistar Cockburn presenta “Crystal Clear” (7). Ahora que tanto se habla de mindset, equipos auto-administrados, etc. Alistar presentó en ese momento una posible solución al complejo mundo de generar equipos orientados a la utilización del enfoque ágil. Y funciona.
• James Coplien presenta “Patrones Organizacionales para el Desarrollo de Software Ágil” (8) mostrando que ágil es un tema de estructura (arquitectura) organizacional, ya que las organizaciones son sistemas abiertos y adaptables y que, adaptando la cita del gran Ortega y Gasset, “uno es uno y su circunstancia”.
• Rebecca Wirfs-Brock presenta el Diseño Basado en Responsabilidades (9) que es la base de varios de los temas que hoy se consideran casi un “estándar de facto”, tales como las historias de usuario (user stories).
• Ken Schwaber presenta SCRUM (10) (dicho sea de paso, si buscan el paper de la primera versión verán que es casi “irreconocible”) un método que se había desarrollado y probado junto con Jeff Sutherland con el aporte de Mike Beedle.
• Kent Beck, que ya había revolucionado el mundo de los métodos colaborativos presentando XP (11), presenta TDD (12).
• Durante la conferencia del año 2000, después de mucho debatir y sostener posiciones, los que luego se reunirán para crear el “Manifiesto por el Desarrollo Ágil de Software” (13), se ponen de acuerdo en unir esfuerzos y compatibilizar enfoques y visiones porque al final del día, como ellos mismos dijeron, tenían un objetivo común: darle al cliente lo que el cliente necesita.

Y sin duda estoy dejando de lado muchos otros hitos pero sobre todo muchas otras personas que fueron clave en la creación y evolución de las “nuevas formas de desarrollar software” hacia lo que luego se denominó o etiquetó como Agile, entre otros Ivar Jacobson, Grady Booch, James Rumbaugh, Kenny Rubin, Adele Goldberg, Arie Van Bennekum, Ward Cunningham, Marin Fowler, Ron Jeffries, Steve Mellor, Dave Thomas y otros. Recomiendo buscar los trabajos de estas personas porque contienen las respuestas a la mayoría (por no arriesgar escribiendo “a todos”) los inconvenientes y desafíos que se presentan cuando se intenta utilizar Agile para la generación de cualquier tipo de solución, basada en software o no.

Y en el tema del Manifiesto, comentarios adicionales que me parecen clave para entender de qué se trata todo esto:

1. La palabra “software” aparece en el nombre por una razón. Si no, solo se llamaría “Manifiesto Ágil” y nada más.
2. Muchas veces se pasa por alto, no se presta atención, no se trata de entender el párrafo final de la enumeración de las razones del Manifiesto, que dice: “Esto es, aunque valoramos los elementos de la derecha, valoramos más los de la izquierda”.
3. La mayoría de las veces veo que se pasa por alto, no se presta atención, no se trata de entender el apartado “Sobre el Manifiesto”, sobre todo su párrafo nueve que dice:

“El movimiento Agile no es anti-metodología, de hecho, muchos de nosotros queremos devolverle credibilidad a la palabra metodología. Queremos restablecer el equilibrio. Adoptamos el modelado, pero no para archivar algún diagrama en un repositorio corporativo polvoriento. Aceptamos la documentación, pero no cientos de páginas de tomos que nunca se mantienen y que rara vez se usan. Planificamos, pero reconocemos los límites de la planificación en un entorno turbulento. Aquellos que calificarían a los defensores de XP o SCRUM o cualquiera de las otras metodologías ágiles como "hackers" ignoran tanto las metodologías como la definición original del término hacker.”

Por qué es importante entender esto

Es importante porque la utilización de los conceptos Agile y agility en software siempre estuvieron totalmente de acuerdo con el origen que, como escribí en el capítulo uno de esta entrega, son el foco en la calidad y el cliente en el marco de la concepción sistémica.

Tomando en su origen las prácticas de la manufactura Lean (15) evolucionaron hacia encontrar formas que permitieran generar productos de software que alcanzaran y superaran las expectativas de los usuarios finales, aún aquellas inesperadas y no planificadas de antemano porque, como bien señala la primera ley de las “Leyes de la Evolución del Software” de Lehman (14), la conocida como “Ley del Cambio Continuo”, “Un programa que se usa en un entorno real necesariamente debe cambiar o se volverá progresivamente menos útil y menos satisfactorio para el usuario”. Es decir, al mismo instante que se entrega una solución ya está cambiando. Pero no solo la solución, cambia el sistema en su conjunto. Y Agile se trata no solo de reaccionar si no de tomar ventaja generando esos cambios. Al final del día, es la regla básica de los sistemas (sistemas, no solo sistemas-software). Por lo tanto, no tiene sentido pensar que la utilización del enfoque Agile en el software estuvo disociado del origen que se dio a nivel empresarial buscando una alternativa a Lean (15). O lo que es peor, en mi opinión, no tiene sentido intentar disociarlo buscando definiciones o explicaciones que intenten diferenciarlo del origen de alguna forma. Hecho que lleva al fracaso de cualquier intención de utilizar Agile para ganar en agility como estrategia para sobrevivir, crecer y desarrollarse.

Referencias

1. “El Gaucho Martín Fierro”, Martín Fierro - Wikipedia

2. Kerr, James M.; Hunter, Richard. “Inside RAD: How to Build a Fully Functional System in 90 Days or Less”. McGraw-Hill. ISBN 0-07-034223-7.

3. "Managing the Development of Large Software Systems", Proceedings of IEEE WESCON 26 (August): 1–9.

4. Object-oriented Programming, Systems, Languages, and Applications (OOPSLA), Object-oriented Programming, Systems, Languages, and Applications (OOPSLA) (sigplan.org)
5. Gilb, Tom, "Evolutionary Development", SIGSOFT Software Engineering Notes. 6 (2): 17. ISSN 0163-5948

6. Poppendieck, Mary; Poppendieck, Tom. “Lean Software Development: An Agile Toolkit”. Addison-Wesley Professional. ISBN 978-0-321-15078-3.

7. Cockburn, Alistair, “Crystal Clear: A Human-Powered Methodology for Small Teams”  Addison-Wesley Professional ISBN 978-0201699470

8. Copilen, James O; Neil Harrison. “Organizational Patterns of Agile Software Development”, Pearson; ISBN-13 ‏ : ‎ 978-0131467408

9. Wirfs-Brock, Rebeca; McKean, Alan.  “Diseño de objetos: roles, responsabilidades y colaboraciones”, Addison-Wesley,  ISBN 0-201-37943-0

10. scrum.doc (jeffsutherland.org)

11. Beck, Kent. “Programación eXtrema explicada: Aceptando el cambio”. Addison-Wesley. ISBN 978-0321278654

12. Beck, Kent. “Desarrollo guiado por pruebas: Mediante Ejemplos”, Addison-Wesley., ISBN 978-0321146533

13.  Manifiesto por el Desarrollo Ágil de Software (agilemanifesto.org)

14. Lehman, Meir M. “Programs, Life Cycles, and Laws of Software Evolution”. Proc. IEEE 68 (9): 1060-1076.
15.  Womack, James P.; Jones, Daniel T.; Roos, Daniel (1990), “Machine that Changed the World”, New York: Rawson Associates, ISBN 9780892563500

Introducción

En esta serie de artículos trataré de ser lo más sintético posible para no aburrir con la lectura.

Voy a escribir sobre hechos que he vivido y personas con las que he tenido el honor de interactuar, trabajar y aprender.

La intención de escribir estos artículos no es abrir un debate. Tomando al Martín Fierro (1) diré que lo hago porque creo, con toda humildad,  que “si hablo de este modo por encontrarlo oportuno, no es para mal de ninguno, sino para bien de todos”.

La génesis de Agile y Agility.

En la década de 1980, el mundo admitió que los conceptos japoneses de manufactura Lean (2) condujeron a una capacidad de fabricación competitiva superior. Los principales fabricantes de todo el mundo estaban luchando para ponerse al día y tratar de igualar o al menos alcanzar esa capacidad competitiva. En el Departamento de Defensa de los Estados Unidos (DoD) estaban convencidos de hacer algo superior a ponerse al día solamente y  fueron a buscar la ayuda de la Fundación Nacional de Ciencias (NSF) con un propósito: hacer el esfuerzo de tratar de identificar lo que vendría después, especialmente porque los japoneses ya estaban trabajando hacia un próximo paradigma, tratando de iniciar lo que ahora se conoce como los consorcios de Sistemas de Fabricación Holónica (3), investigando sistemas compuestos de holones: agentes inteligentes, autónomos y cooperativos. Esto dio origen a un proyecto  en la Universidad de Lehigh (USA) dónde trece compañías fueron invitadas a enviar “pensadores” para realizar una  prospectiva de cómo sería el mundo, tomando un horizonte de 35-50 años hacia adelante, en el que las empresas deberían alcanzar sus objetivos básicos de supervivencia, crecimiento y desarrollo.

Para lograrlo, trabajaron con el propósito de identificar un problema emergente que fuese común y fuese clave para competir en el futuro y que se convertiría en el siguiente diferenciador, ya que una vez que Lean se difundiera y se utilizara ampliamente dejaría de ser un diferenciador.  Ese problema se identificó como la capacidad de responder con eficacia y competencia a entornos operativos con creciente incertidumbre e imprevisibilidad porque en esos entornos los eventos que sucederían tendrían la característica de ser no planificados e inesperados. Pero a su vez, no sólo responder o reaccionar sino también generar esos eventos inesperados y no planificados para los competidores. A esa capacidad la definieron y etiquetaron en el estudio como “agilidad”, tomando como base la definición del término “ágil” que se había acuñado previamente en el paper “Agile Manufacturing” publicado un tiempo antes.

A raíz del estudio, para dar el próximo paso, en el año 1991 se  generó en la misma Universidad el Foro de Agilidad, conocido como USA DoD/NSF Agility Forum, (mucho tiempo activo con el nombre de Agile Manufacturing Enterprise Forum) con el fin de explorar la naturaleza de la empresa ágil y los sistemas ágiles en forma independiente del dominio en el que actuaran, entendiendo la palabra “sistemas” desde la Teoría General de los Sistemas aplicada a las organizaciones (4).  El trabajo en proceso fue socializado ampliamente para obtener la retroalimentación con grupos como NIST, DARPA, la Junta de Ciencias de Defensa, la Asociación de Industrias Aeroespaciales, y otros. En el trabajo original se  desarrollaron visiones conceptuales de empresas ágiles en cuatro dominios comerciales diferentes: automotriz, de procesos, de semiconductores y de telecomunicaciones. Pero luego, al ver el potencial, se decidió convocar a más de 300 empresas de todos los rubros y diferentes tamaños para trabajar en refinar el modelo teórico a partir de la aplicación práctica ampliando el enfoque a sistemas ágiles de todo tipo tomando como base que las empresas y organizaciones son sistemas abiertos y adaptables desde el punto de vista de la Teoría General de los Sistemas. Estos talleres teórico-prácticos duraron aproximadamente tres años y permitieron refinar y aumentar los marcos originales. Como parte del trabajo se desarrolló un modelo de referencia empresarial ágil, que incluye un modelo de madurez de capacidades y un proceso de análisis para medir qué tan ágil es una empresa en 24 prácticas  diferentes. Rick Dove fue el Líder de todo este proyecto y publicó la mayoría de los resultados en su libro “Response Ability” (5).

Con la “etiqueta” y el concepto ágiles en juego, en 1993 Hewlett Packard fue el primero en iniciar un programa para educar a sus clientes y posteriormente llevar al mercado el soporte de TI bajo la bandera de Agile Enterprise. El Programa de Investigación de Comando y Control del Departamento de Defensa de USA (DoD’s Command and Control Research Program) comenzó a explorar y utilizar lo que llamaron “comando y control ágil”, y el Manifiesto Ágil por el Desarrollo de Software (6) adoptó la etiqueta ágil como apropiadamente descriptiva y fundamentalmente consistente con sus conceptos.

Por lo tanto, ágil y agilidad nació como un enfoque superador a Lean o al menos buscando una alternativa a Lean y eso lo hace diferente. En la cronología, un enfoque empresarial centrado en los dominios de automotriz, de procesos, de semiconductores y de telecomunicaciones vino primero. Luego se modificaron los fundamentos ágiles para que fueran independientes del dominio extendiéndolos a ser aplicados en cualquier tipo de sistema (de nuevo, entendiendo las organizaciones como sistemas abiertos y adaptables).

Los trabajos de investigación y desarrollo del tema continuaron sobre todo impulsados por el International Council on System Engineering (INCOSE) que fundó el grupo de trabajo llamado “Agile Systems and Systems Engineering” porque se visualizaba que en el futuro, cuando la tecnología acompañara, “todas las empresas y organizaciones, sin importar el dominio en el que actúen o el producto o servicio que ofrezcan, serán empresas de tecnología y software”.

 Pero quién más contribuyo al desarrollo de los conceptos fue el dominio del desarrollo de software que adoptó la etiqueta ágil con un profundo efecto de conciencia popular. En este dominio, ágil consigue hoy el empleo amplio; porque la comunidad de desarrollo de software ya estaba trabajando en forma natural para un nuevo paradigma de generación de soluciones más allá de la cascada a gran escala desde mucho antes de 1986, anticipándose también al futuro. Pero esto será el tema del capítulo 2,  mi próxima entrega.

Por qué es importante entender esto

La importancia de entender que ágil y agilidad son conceptos que surgen con base en la concepción sistémica es clave para no fracasar en el intento por utilizarlos. Básicamente, porque de otro modo se pierde de vista que en todo sistema cualquier “cosa” que se introduzca impacta a todos sus componentes y a todas las relaciones entre esos componentes.

Ágil y Agilidad son temas de arquitectura empresarial porque todo sistema tiene definida una arquitectura ya que está compuesto por componentes y relaciones. La estrategia a seguir para alcanzar los objetivos básicos de sobrevivir, crecer y desarrollarse es clave para definir esa arquitectura.

Suponer que ágil y agilidad es un tema de “mindset” o de utilización de métodos y marcos o…. es lo mismo que pensar que mente y cuerpo pueden aislarse y considerarse por separado para tener éxito en sobrevivir, crecer y desarrollarse como ser humano.

Y cuando se toman esos caminos, por la razón que sea, como se está viendo actualmente, es cuando muchos empiezan a buscar “la bala de plata” (7).

Referencias

1. “El Gaucho Martín Fierro”, Martín Fierro - Wikipedia

2.  Womack, James P.; Jones, Daniel T.; Roos, Daniel (1990), Machine that Changed the World, New York: Rawson Associates, ISBN 9780892563500

3.  Oscar Amaury Rojas Alvarado, Juan Martín Velasco, Edgar Alfonso Chacón (2013), Principios de un Modelo Dinámico para Integración Empresarial: Un enfoque desde los Sistemas Holónicos de Manufactura – HMS , España, Editorial Académica Española, ISBN 9780892563500

4. Von Bertalanffy, Ludwig (1976). Teoría general de los sistemas. Fundamentos, desarrollo, aplicaciones. México: Fondo de Cultura Económica. ISBN 9681606272.
5. Dove, Rick (2001). Response Ability: The Language, Structure, and Culture of the Agile Enterprise,. USA, Willey, ISBN: 978-0-471-35018-7.

6. Manifiesto por el Desarrollo Ágil de Software (agilemanifesto.org)

7. Brooks, Frederick P. Jr. (1995). "Chap. 17". 'No Silver Bullet' Refired. The Mythical Man Month (Anniversary Edition with four new chapters ed.). Addison-Wesley. ISBN 0-201-83595-9.

Short article published into PMI´s PM Network official newsletter
Key references:
-USA DoD NSF/Agility Forum, Leihigh University, 1990
A four year long work started in 1990 to find an alternative to Lean (that is because Lean and Agile are not the same). It was a theorical-practical work where the top 250 companies in the USA related to several business domains have interacted along the four years. The main result were the formal definition of Agile and agility terms.
-Rick Dove´s work because he was the forum leader. Most of the deliverables created in the forum can be found here: Response Ability: The Language, Structure, and Culture of the Agile Enterprise, https://books.google.com.ar/books/about/Response_Ability.html?id=M3wnwrol2YgC&redir_esc=y

English:

http://www.pmnetwork-digital.com/pmnetwork/april_2016?pg=73#pg73

Spanish:

 http://www.pmnetwork-spanish.com/pmnetworksp/abril_2016?pg=68#pg68

Short article about practical experiences to implement and working into Agile environments.

 
PMI: http://www.pmnetwork-digital.com/pmnetwork...2&folio=50#pg52 
Slideshare: https://www.slideshare.net/contesl/pm-netw...ile-in-practice 
Facebook: https://www.facebook.com/bawarp.bawarp 
Wordpress: https://bawarp.wordpress.com/2017/12/06/agile-in-practice/