Seamos sinceros, las metodologías ágiles han existido desde siempre, esto no es una moda. Una prueba de ello es que muchos de nosotros, al trabajar con estas, sentimos que esto ya las conocemos instintivamente. Entonces, ¿por qué le ponemos nombre? ¿por qué es necesario enseñarlas? a mi parecer esto se hizo para un crear orden lógico a la hora de construir nuevos proyectos, tomando patrones de comportamiento de especialistas que se dedican a esto, cayendo en cuenta que es la aplicación del método científico en los negocios o si queremos ser mas simple es aplicar el sentido común sin desperdiciar recursos ni tiempo.

¿Pero si desde antes existían las metodologías ágiles, que proyectos en la historia las han aplicado? Es por ello que les he traído este este articulo de Martyn Puddephatt, que tradujimos, donde  habla un poco más de lo que comentaba anteriormente y además nos cuenta de varios proyectos históricos que fueron 100% Agile. Aquí vamos:

_________________________________________________________

Mucha gente cree que Agile es simplemente «la última moda de la administración». Muy a menudo se burlan de la idea de convertirse en Agile porque «algo más vendrá pronto y lo reemplazará». Bueno, hoy quiero plantear la respuesta, que no será así, y que en realidad ha existido por mucho tiempo, simplemente no lo sabías.

Oficialmente, Agile nació en febrero de 2001 cuando 17 desarrolladores se reunieron en un resort en Snowbird, Utah, para hablar sobre su frustración de crear software que simplemente no cumplía con lo que el usuario necesita. Así que se unieron para encontrar 4 valores y 12 principios por los cuales les gustaría vivir cuando se desarrolla el software, y así nació el Manifiesto Ágil de Scrum. Eso fue hace 17 años y en el gran esquema de cosas que son bastante nuevas, pero en el mundo de la tecnología que es antiguo. En ese marco de tiempo, nacieron tecnologías completas, ganaron uso generalizado y quedaron obsoletas por la nueva tecnología (R.I.P WAP). Entonces te preguntaras ¿ el hecho de que Agile se haya mantenido así durante mucho tiempo en una industria que se mueve más rápido que cualquier otro en la historia, debería ser la primera alarma que no llegará a ningún lado pronto?

Antes de hablar de cuánto tiempo estará Agile vigente hoy en día, lo que quiero hacer con este artículo es que al menos a una persona pueda comprender primero que los valores y principios fundamentales en los que Agile se cree que se derivan, es de algo que todos conocemos desde hace mucho tiempo y que la mayoría ha olvidado, el siempre esquivo, sentido común. Para hacer eso, los llevaré a un recorrido guiado por la historia para ver algunos proyectos increíblemente exitosos de los años 50, 40 y 30, todos los cuales se entregaron siguiendo un conjunto de valores que coinciden muy de cerca con Agile y otras Metodologías ágiles «modernas».

.  .  . 

1956 – Proyecto Submarino Polaris

Polaris fue un proyecto militar estadounidense para desarrollar un submarino que lanzaría misiles de combustible sólido y tendría la capacidad de hacerlo desde el agua. Todo lo cual era una tecnología innovadora en ese momento. Originalmente, esto tenía un plazo de entrega de 9 años y terminó en 3. Un hecho poco conocido sobre el proyecto Polaris es una gran cantidad de información acerca de por qué fue tan exitoso. William Raborn requirió una gran cantidad de dinero del Congreso para que el proyecto fuera exitoso y sabía que estarían muy atentos a la entrega para asegurarse de que estaba en buen camino, por lo que desarrolló algo llamado PERT (Técnica de Revisión de Evaluación del Programa) gráficos que rastrearían todas las cosas que se podrían hacer en conjunto, para mostrar cuál era el camino crítico hacia la finalización del proyecto. Pero William Raborn fue tan bueno en la venta de estos gráficos al Congreso, que después del éxito de Polaris, fueron adoptados en la gestión general de proyectos y cualquier persona con una calificación de Prince 2 probablemente estaría bastante familiarizada con estos gráficos. 

PERT Chart

Hubo muchas razones para el éxito de Polaris, así que echemos un vistazo a algunas de las claves:

• El director técnico del proyecto, Levering Smith, recibió total autonomía sobre el alcance del proyecto. Comprendió categóricamente qué era lo que el ejército estaba tratando de lograr y el valor que estaban tratando de entregar. Ahora esto suena muy similar a un rol de trabajo que vemos hoy en Agile, el del Product Owner.
• Smith se enfocó en la entrega incremental, se enfocó en construir un sistema operacional lo antes posible para comenzar a aprender de él. Entonces, uno de los primeros obstáculos fue ¿cuán grande debería ser el submarino? Bueno, los misiles que necesitamos lanzar son X grandes, entonces hagámoslos X grandes y luego averigüemos si es necesario que sean más grandes a medida que aprendemos más. No se olvide, todo lo que estaban haciendo era una tecnología innovadora. Esto nuevamente suena muy familiar en la forma en que entregamos el software en Agile, iterativamente. Entregue el MVP (producto mínimo viable) y comience a recibir comentarios para mejorarlo.
• Smith les dio a los equipos técnicos plena autonomía sobre cómo entregaron los subsistemas. No les dijo cómo hacerlo, se centró en el QUÉ y el POR QUÉ y les dejó que lo resolvieran. De hecho, tendrían 3 equipos de subcontratistas trabajando en cada subsistema, y ​​quien entregue la mejor solución obtendría el trabajo. Esto es algo constante en los equipos ágiles autoorganizados. Dando al equipo la autonomía para resolver los problemas y dejar que se centren en el CÓMO.
• Smith creía que la calidad y la confiabilidad eran primordiales. Después de todo, usted está construyendo un arma que tendrá muchos marineros viviendo a bordo, no se puede reducir la calidad cuando hay vidas en juego. Así que ordenó que cada subsistema tuviera que tener las pruebas que se iban a aprobar primero, y luego el subsistema creado para aprobar esas pruebas. Los ingenieros que lean esto deberían reconocerlo de inmediato como lo que llamamos TDD hoy en día. Otro principio de Scrum es que la calidad es fija, también es algo que se menciona regularmente en el Manifiesto Ágil.
• Finalmente, cada persona que trabaja en ese proyecto estaba completamente comprometida con lo que estaba haciendo. En lo que a ellos respecta, estaban salvando el mundo, y hay muy poco que pueda motivarte más que eso. A menudo hablamos de hacer todo lo posible para involucrar a la fuerza laboral, hacer que crean en la visión de la empresa. Esto es menos una cuestión ágil y más un tema de liderazgo, pero pensé que valía la pena incluirlo.

.  .  . 

1943 – Programas de desarrollo avanzado de Lockheed Martin

En ese momento en la historia de Lockheed Martin, sus programas de desarrollo avanzado estaban dirigidos por un hombre llamado Kelly Johnson, quien fue citado como el creador de KISS (Mantenlo simple, estúpido) e involucrado en algunos de sus planos más innovadores, incluido el U2, SR-71 Blackbird y el F-22 Raptor, muchos de los cuales todavía están en uso hoy en día. Este departamento se llamó «skunkworks», que es un término definido por wikipedia como:

La designación «skunk works» o «skunkworks» se usa ampliamente en los campos de negocios, ingeniería y técnicos para describir a un grupo dentro de una organización con un alto grado de autonomía y sin trabas por parte de la burocracia, con la tarea de trabajar en proyectos avanzados o secretos. . ”

Te has dado cuenta de que la parte clave es «se les otorga un alto grado de autonomía y no están obstaculizados por la burocracia», y la razón de ello, si le preguntaras al Director de Marketing de Xero, Andy Lark, es: «la burocracia mata la creatividad y la innovación» y la innovación fue la palabra en juego para estos departamentos. ¿No les parece curioso que supieran que no era posible innovar cuando hay muchos trámites burocráticos en los años 40? y es una lección que tenemos que volver a aprender hoy en día.

Kelly Johnson vivió por sus «14 Reglas de Gestión». No los veremos a todos porque algunos de ellos son muy específicos del trabajo que hicieron, pero veremos los pocos que realmente se destacan y cómo se ven muy similares a los valores y principios fundamentales en Agile:

• “El gerente de Skunk Works debe delegar el control prácticamente completo de su programa en todo aspecto al equipo. Solo deberá informar el progreso a un presidente de división o superior» Una vez más, vemos que el rol de Product Owner se describe mucho antes de que Scrum o Agile estuvieran cerca de ser una idea.
• «Se debe de proporcionar un sistema de liberación gráfico lo suficientemente flexible para hacer lo cambios pertinentes en cualquier momento del proyecto». Esta regla coincide casi perfectamente con uno de los Valores Ágiles, “Responder a un cambio a lo largo de un plan” y también de manera cercana al Principio Ágil, “ Bienvenidos los cambios de requisitos, así sea finalizando el desarrollo. Los procesos ágiles aprovechan el cambio cómo una ventaja competitiva para cliente «.
• “Debe haber una revisión mensual de costos que cubra no solo lo que se ha gastado, sino también los costos proyectados para la conclusión del programa. No habrá libros con 90 días de retraso y no se debe sorprender al cliente con sobrecargas repentinas». Ellos sabían en ese momento, que no podía simplemente establecer un presupuesto y luego usarlo, tenían que inspeccionar y adaptar regularmente y, lo que es más importante, gestionar las expectativas. Vemos esto en el Agile Value:  «Colaboración con el cliente sobre la negociación de contratos».
• “El sistema de inspección actualmente en uso por Skunk Works,  ha sido aprobado tanto por la Fuerza Aérea como por la Armada, cumple con la intención de los requisitos militares existentes y debe usarse en nuevos proyectos. Poner más responsabilidad de inspección a los subcontratistas y proveedores, así no duplicar la inspección.» Esta es una requisito bastante específico, pero la parte clave es el bit en negrita al final. Si algo ya tiene un sistema probado y en funcionamiento, no duplique el esfuerzo y confiemos en lo que dice. Este es un principio básico en Lean, «Eliminar desperdicios» y un tema de conversación muy regular en Scrum, Kanban y Lean Startup.
• “Al contratista se le debe delegar la autoridad para probar su producto final en vuelo. Él puede y debe probarlo en las etapas iniciales. Si no lo hace, pierde rápidamente su competencia para diseñar otros vehículos ”. Kelly también creía que la calidad era primordial, pero también creía en la importancia de fallar rápido y que el equipo responsable del trabajo debería responsabilizarse de la calidad. Esto se relaciona con muchos de los principios y valores Agile: «El software funcionando es la medida principal de progreso» y «La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad», pero también la «Integración de calidad». Es un diferenciador clave entre la entrega en cascada tradicional y un enfoque ágil, ya que la calidad es fija.

Enfoque tradicional en cascada comparado con el enfoque ágil

• “Debe haber confianza mutua entre la organización y el contratista, con una cooperación y enlace muy estrechos todos los días. Esto reduce los malentendidos y la correspondencia a un mínimo absoluto». Incluso en 1943 sabían que la forma más eficiente de colaborar era hablar a diario, y esto era antes de los días de correo electrónico o Internet, por lo que la mayoría de los que hablarían cara a cara, esto es algo que es muy importante en Agile y que se menciona en dos de los principios, “Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto” y “El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es la conversación cara a cara». También era algo que era obvio para Jeff Sutherland y Ken Schwaber cuando desarrollaron Scrum, de ahí la necesidad del Daily Meetings.

.  .  . 

1931 – Empire State Building

Tiempo para un poco de participación de la audiencia. Te doy algunos datos sobre el Empire State: tiene 102 pisos, 443.2 m de altura, la construcción comenzó el 17 de marzo de 1930. Ahora responde ¿Cuánto tiempo supones que se tardó en construir? Y no lo busques en Google.

No voy a fingir que haré un truco de magia y te deslumbraré con mi respuesta: estoy seguro de que cuando te diga que en realidad tomó solo 13 meses desde que pusieron la primera viga de acero hasta cuando abrieron las puertas al público, hay una alta probabilidad de que tu mandíbula simplemente golpee el piso, ya que se te es imposible de imaginar que haya tardado tan poco. Te cuento que el exterior se completo en solo 6 meses y además se entregó con 18% por debajo del presupuesto. En caso de que no me creas, aquí va la prueba:

Lapso de tiempo de la construcción del Empire State.

Entonces, lo primero que me vino a la mente cuando me enteré de esto, que lo considero una proeza de ingeniería, es ¡¿cómo diablos lo lograron ?! Bueno, vamos a ver el detalle:

• En primer lugar, desacoplaron todos los sistemas involucrados para que pudieran trabajar de forma independiente. El concreto, las molduras metálicas exteriores, las ventanas y la caliza exterior eran completamente independientes. La única dependencia era la estructura de acero que tenía que estar en su lugar antes de que se pudiera realizar cualquier otro trabajo. Así que esto significaba que nadie estaba atascado esperando a que se completara un componente antes de que pudieran empezar con el siguiente. Esto es muy cierto en la forma en que creamos equipos Scrum, buscando construir equipos multifuncionales que sean capaces de entregar una pieza de valor de extremo a extremo sin dependencias externas.

Ejemplo de la Lista de Acero utilizada

• En segundo lugar, ponen una gran cantidad de atención en el flujo de trabajo. Se enfocaron en un piso a la vez, abriéndose camino hacia el edificio. Aquí hay un ejemplo del programa de acero utilizado para la construcción y puede ver cómo hicieron el diseño inicial, el diseño final, luego ordenaron el acero, luego se entregó y finalmente se puso el acero, piso por piso. Este gráfico representa una información que todos estamos muy acostumbrados a ver en un formato que usamos hoy en día, tal como esto:

Cómo podría verse el calendario del acero en un tablero Kanban

• En tercer lugar, se centraron en el flujo de caja. Ellos invirtieron para reducir el costo de la demora. Ellos sabían categóricamente que todos los días que se atrasaban en el programa, perderían $ 10,000 dólares (que no era una pequeña cantidad de dinero en ese entonces). Entonces, si podían gastar dinero para asegurarse de que eso no sucediera, lo harían. Por ejemplo, instalaron una línea de tren en cada piso para acelerar el movimiento de los materiales.
• Finalmente, se enfocaron en las restricciones. El tiempo se fijó, teanían que abrir el 1 de mayo de 1931, porque es cuando su contrato de arrendamiento comenzaría por estar abierto al público y por cada día que se pasara de la fecha se les les cobraría $ 10,000 dólares. El costo fue fijo, lo único que tenían era $ 35 millones ¡BUUUUUUUH! y no lo digo solo por ser malo, realmente es una muy cantidad de dinero para un edificio. Esto fue durante el apogeo de la Gran Depresión, aseguraron este dinero justo antes de que comenzara y ya nadie les prestaría, eso fue todo, eso era todo lo que tenían. Entonces, ¿qué hicieron? Ellos diseñaron el edificio para cumplir con el calendario. Lo que cambió fue el alcance y las características, que es algo que hemos visto antes.

Si puedo resumir esto en algo breve sería esto; Agile no es nada nuevo, es solo una reaparición de algo que ya sabíamos y se reduce a estas 3 cosas:

1. Céntrese en las restricciones reales y diseñe el trabajo para cumplir con ese cronograma
2. Dar autonomía al equipo para innovar.
3. Entregar de forma incremental para validar y ajustar según sea necesario

Entonces, la próxima vez que alguien te diga que «Agile es solo una moda» y «pronto será reemplazado por algo nuevo», dile que lean esto y esperamos que podamos ayudar a reaparecer el sentido común de una persona a otra.

Artículo original en Inglés