Lo ágil vs lo predictivo… ¿todavía?

by Profesor/a UOC | Sep 8, 2020

(Més avall trobareu la versió en català d’aquest contingut.)

En los entornos profesionales y académicos vinculados a la dirección de proyectos, la incorporación de las propuestas ágiles a la cultura organizativa de todo tipo de sectores (también el TIC, evidentemente), sigue generando debate, tal y como nuestro compañero y maestro José Ramon Rodríguez no ha dejado de explicar en muchas ocasiones en este mismo blog. Y como en muchos debates organizativos similares la controversia genera, a pesar de que cada vez menos, defensas numantinas contrapuestas entre los partidarios de los sistemas waterfall, tradicionales o predictivos (predictivos por la necesidad de gestionar en un futuro controlable) y los defensores, a veces evangelistas, de los sistemas ágiles o adaptativos (adaptativos por la necesidad de priorizar los deseos/requisitos del cliente/usuario a medida que se concretan). Los primeros argumentan la necesidad, que a menudo es exigencia del cliente, de garantías de coste, de tiempo, de calidad…; mientras que los segundos ponen los beneficios de la satisfacción de estos mismos clientes como argumento clave. 

A nosotros –y creemos que ya a una mayoría de la profesión- nos parece claro que no se trata de proclamar una metodología ganadora frente la otra, ni de apuntarse acríticamente a una tendencia, la ágil, que, en el otro lado de los radicales, todavía hay quién considera solo una moda. Pensamos que lo que hace falta es identificar cómo tendría que afrontar una organización la mejora de sus sistemas de gestión de proyectos incorporando las mejores prácticas de cada casa; es decir, lo que sea más eficiente en cada situación y momento. De alguna manera (y quizás son debilidades postconfinamiento) asumiendo, como tantos otros antes de nosotros, el pensamiento poético de J.V.Foix de 1947 de “me exalta lo nuevo y me enamora lo viejo” (a pesar de que agile, seamos francos, ya no es tan nuevo).

En el contexto de este debate, en esta entrada queremos volver a intentar explicar de dónde viene todo ello y dar alguna pista de donde estamos. Y en alguna entrada posterior, intentaremos dar algún detalle más de a dónde vamos y con qué reglas.

Lés metodologías ágiles o adaptativas (y muchos de sus nombres como Scrum, XP, Kanban, Lean…) se incorporaron a la ingeniería del software a primeros del siglo XXI, cuando las herramientas de desarrollo de software permitieron la programación orientada a objetos y la programación que se llamó visual. Y también cuando las BBDD relacionales ya habían resuelto definitivamente los problemas de rendimiento que tenían y ya se habían convertido en la solución de mercado mayoritaria. 

La facilidad para poder enmendar, si hacía falta, una definición en la arquitectura de datos, o la facilidad de poder modificar una pantalla, o una función encapsulada, hicieron posible y lógico flexibilizar lo que durante décadas había sido un dogma en la ingeniería del software: primero el análisis, después el diseño y finalmente la programación y pruebas. En definitiva, se dieron las condiciones ideales por que se flexibilizara la producción de software. Es decir: antes de estos saltos tecnológicos era difícil, por no decir imposible, haber puesto en marcha el mundo ágil que tenemos ahora. O dicho de otro modo: la evolución tecnológica volvió a inducir el cambio productivo, en este caso, del propio software.

Era en aquel momento, pues, que podía emerger, de forma casi natural, el planteamiento ágil que quedó representado en su manifiesto. Y tuvo éxito. Y lo acompañó el nacimiento de Scrum, que se hizo muy popular y que sigue ganando adeptos. (Un paréntesis: en el desarrollo de software ¿todo es tan moderno y ágil? ¡No! Quedan algunas aldeas en la Galia tecnológica que muestran la, todavía, diversidad de todo ello: por ejemplo, el mundo COBOL resiste a sus 70 años en algunos valiosos y muy pesantes sistemas de TI de sectores tradicionales) 

Estas situaciones de cambio son habituales en la mejora de los procesos de producción. Por ejemplo, hoy las pruebas de impacto de los vehículos en proceso de diseño (coches, motos,…) ya no necesitan vehículos físicos: el 90% son pruebas virtuales. Por cierto, fue en el interior de los sistemas de producción del sector de la automoción donde nacieron Kanban y Lean, dos de los ágiles indiscutibles. 

Kanban lo hizo en los años 50 en Toyota, con la voluntad de rebajar los stocks, y asegurar que los materiales, dentro del proceso productivo,  están solo cuando hacen falta. Usaba y usa tarjetas (ahora virtuales) que indican lo que hay que producir. Parece claro que fue el precursor del método TPS (Toyota Production System) y posteriormente de sistemas como Just in Time o Lean Management. Tanto en los entornos de producción originales como en los de gestión, su idea es gestionar eficientemente las cargas de trabajo para optimizar el trabajo que hace cada equipo.

Lean también tiene los orígenes en Toyota, pero todavía es más antiguo: 1937. Lo planteó Taiichi Ohno viendo la baja productividad de la industria japonesa frente los nuevos sistemas de producción en cadena en los Estados Unidos. Tiene fuertes relaciones con las ideas de Kanban en el sentido de minimizar los stocks alineando los métodos a las necesidades de los clientes, a pesar de que a Lean, el principio de la mejora continua tiene un peso muy importante. Aquel viejo Lean ha evolucionado también –y volvemos a hablar de gestión de proyectos- hacia el Lean Project Management, que tiene como principio fundamental eliminar todo aquello que no agrega valor al cliente, para centrarse en aquellas actividades actuales que son imprescindibles para producir los resultados que espera el cliente. Y esto, parece claro que ya huele a los planteamientos ágil que conocemos ahora.

Los métodos ágile se han hecho muy populares por necesidades muy de nuestro tiempo como las de los gerentes de un menor time-to-market, o las de los desarrolladores que hacen aplicaciones para móviles, o videojuegos, o productos de animación, o de análisis de novísimos datos… Pero también por la mayor exigencia de empatía con las necesidades de los clientes (empatía que ya se acepta como un must de cualquier proyecto) aligerando lo que a menudo era una enorme angustia cuando se los pedía a los clientes/usuarios que “definieran”, clara e irreversiblemente, lo que querían (requisitos). Esta empatía con el cambio (justificado por la a menudo inevitable indefinición inicial) está en el positivo adjetivo alternativo de adaptativas que se ha dado a estos métodos ágiles.

Pero las metodologías ágile no están libres de pecado original. Y en bastantes casos se implementaron de forma “elefantina” desplazando los otros sistemas de la chatarrería TI, sin un cuidadoso análisis de la realidad organizativa y de sus necesidades. Por eso, después de algunas dolorosas experiencias iniciales, las empresas más inteligentes, como nos dice el informe Pulse 2018 del PMI, tendieron a incorporar progresivamente los nuevos métodos y a menudo con sistemas híbridos, aplicando unas metodologías u otras según una serie de parámetros del proyecto y otras consideraciones de contexto como el tipo de equipos de trabajo, la organización o la financiación.

En el otro lado del debate, las metodologías predictivas (adjetivo que quizás suena mejor que el de clásicas en un entorno tan dado a las modernidades como el TIC), tienen un origen muy y muy diferente, como mínimo sus dos referentes principales, PMBOK y PRINCE2.

PMBOK es una propuesta del PMI que nace en EEUU en 1969 fruto de las inquietudes de un grupo de cinco ingenieros hacia los problemas, especialmente de nomenclatura, de prácticas cotidianas y de comunicación, que iban apareciendo en un entorno donde el trabajo por proyectos empezaba a consolidarse. Desde entonces, la vocación de las buenas prácticas propuestas por el PMBOK ha seguido siempre orientada a la mejora del trabajo de las directoras y directores de proyectos, en base a un trabajo cooperativo que lo ha traído en 2017 hasta su 6.ª edición. Creemos que es muy relevante resaltar que cada edición se mejora a partir de un trabajo entre miles de jefas y jefes de proyectos que voluntariamente trabajan para actualizar y mejorar esta propuesta de buenas prácticas. Quizás por este anclaje en la realidad el PMBOK pone mucho de su foco en identificar aquellos elementos del entorno de las organizaciones que son clave para garantizar el éxito de los proyectos. En este sentido sitúa una buena planificación lo más completa y trabajada en cada momento como un elemento clave en los resultados, definiendo tanto como se pueda el alcance, las tareas, los esfuerzos necesarios, el presupuesto, los riesgos y los interesados, entre otros temas.

PRINCE2 es una propuesta muy centrada en el sector TIC que es donde nació: la CCTA, hoy OGC del gobierno del Reino Unido. No se puede esconder que en su origen tiene un claro propósito predictivo que aparece en el propio nombre del método: “PRoject IN Controlled Environments (PRINCE). Buscaba situar los proyectos, pues, en un entorno controlado y gestionable.  En el caso de PRINCE2, a diferencia de PMBOK, sí se puede hablar de una metodología de gestión de proyectos, con flujos, procesos, documentos, roles, etc… Plantea hasta 7 temas claves: los planes (cuánto, como, cuando), el cambio, la calidad, los riesgos, la organización, el progreso del proyecto y el Bussines Caso.

Llegados aquí y vistos los planteamientos básicos de cada lado e intuyendo su complementariedad, ¿por qué pues el debate entre los mundos adaptativos y predictivos tuvo y tiene momentos de cierta radicalidad? Posiblemente porque el planteamiento ágil se presentó como la solución a los problemas de las metodologías predictivas tradicionales. En algún momento fue casi un planteamiento de bandos, de tifosis, que dio mucho juego (del que todavía se encuentran algunos rastros). Pero esta discusión sobre salvadores y pecadores ya empieza a ser antigua y de poco interés para las nuevas generaciones que ven con naturalidad un mundo hibridizado –líquido que diría el sabio. Además, los principios, siguiendo a Groucho, se pueden ir adaptando también sin demasiados complejos y en la búsqueda del beneficio común. De hecho, tanto PMBoK como PRINCE2, en sus últimas renovaciones, han ido dejándose empapar de las filosofías ágiles: el primero ya tiene publicada, de la mano de Agile Alliance, una “Guía práctica de Ágil”; y el segundo propone artefactos prácticos como el agilómetre  en su Prince2Agile movimiento. Además, el mundo ágil ha desbordado del todo su ámbito natural inicial, el del desarrollo de software, para bañar áreas y proyectos de todo tipo, como por ejemplo, los de transformación organizacional.

Afortunadamente, pues, parece que salimos del mundo de las purezas, para ir al que realmente preocupa a las y los jefes de proyecto, que no son las etiquetas sino los indicadores por los cuales será valorado el éxito de su proyecto.

Nota: hemos ilustrado esta entrada con la portada de la Agile Practice Guide, firmada a dos manos por el PMI y la Agile Alliance, porque creemos que son una buena muestra de lo tendencia a lo híbrido

Pere Mariné Jové, PMP 
Profesor Colaborador de la UOC en Dirección de Proyectos, pmarine@uoc.edu 

Josep Maria Marco-Simó
Profesor de los Estudios de Informática, Multimedia y Telecomunicación de la UOC

Allò àgil vs allò predictiu… Encara?

Entre els entorns professionals i acadèmics vinculats a la direcció de projectes, la incorporació de les propostes àgils a la cultura organitzativa de tota mena de sectors (també el TIC, evidentment), segueix generant debat, tal i com el nostre company i mestre José Ramon Rodríguez no ha deixat d’explicar en moltes ocasions en aquest mateix blog. I com en molts debats organitzatius similars la controvèrsia genera, tot i que cada cop menys, defenses numantines contraposades entre els partidaris dels sistemes waterfall, tradicionals o predictius (predictius per la necessitat de gestionar en un futur controlable) i els defensors, de vegades evangelistes, dels sistemes àgils o adaptatius (adaptatius per la necessitat de prioritzar els desitjos/requisits del client/usuari a mida que es van concretant). Els primers argumenten la necessitat, que sovint és exigència del client, de garanties de cost, de temps, de qualitat…; mentre que els segons posen els beneficis de la satisfacció d’aquests mateixos clients com argument clau. 

A nosaltres –i creiem que ja a una majoria de la professió- ens sembla clar que no es tracta de proclamar una metodologia guanyadora front l’altra, ni d’apuntar-se acríticament a una tendència, la àgil, que, en l’altre costat dels radicals, encara hi ha qui considera només una moda. Pensem que el que cal és identificar com hauria d’afrontar una organització la millora del seus sistemes de gestió de projectes incorporant les millors pràctiques de cada costat; és a dir, el que sigui més eficient en cada situació i moment. D’alguna manera (i potser són debilitats postconfinament) assumint, com tants altres abans de nosaltres, el pensament poètic de J.V.Foix al 1947 de “m’exalta el nou i m’enamora el vell” (tot i que agile, siguem francs, ja no és tan nou).

En el context d’aquest debat en aquesta entrada volem tornar a intentar explicar d’on ve tot plegat i donar alguna pista de on estem. I en alguna entrada posterior, intentarem donar algun detall més de cap on anem i amb quines regles.

Les metodologies àgils o adaptatives (i molts dels seus noms com Scrum, XP, Kanban, Lean…) es van incorporar a la enginyeria del programari a primers del segle XXI, quan les eines de desenvolupament de programari van permetre la programació orientada a objectes i la programació que es va dir visual. I també quan les BBDD relacionals ja havien resolt definitivament els problemes de rendiment que tenien i ja s’havien convertit en la solució de mercat majoritària. 

La facilitat per poder esmenar, si calia, una definició en l’arquitectura de dades, o la facilitat en poder modificar una pantalla, o una funció encapsulada, van fer possible i lògic flexibilitzar el que durant dècades havia estat un dogma en la enginyeria del programari: primer l’anàlisi, després el disseny i finalment la programació i proves. En definitiva, es van donar les condicions ideals per que es flexibilitzés la producció de programari. És a dir: abans d’aquests salts tecnològics era difícil per no dir impossible haver posat en marxa el món àgil que tenim ara. O dit d’una altra manera: l’evolució tecnològica va tornar a induir el canvi productiu, en aquest cas, del propi programari.

Era en aquell moment, doncs, que podia emergir, de forma quasi natural, el plantejament àgil que va quedar representat en el seu manifest. I va tenir èxit. I el va acompanyar el naixement de Scrum, que es va fer molt popular i que segueix guanyant adeptes. (Un parèntesi: en el desenvolupament de programari tot és tan modern i àgil? No! Queden algunes aldees a la Gàl·lia tecnològica que mostren la, encara, diversitat de tot plegat: per exemple, el món COBOL resisteix als seus 70 anys en alguns valuosos i molt pesants sistemes de TI de sectors tradicionals) 

Aquestes situacions de canvi són habituals en la millora dels processos de producció. Per exemple, avui les proves d’impacte dels vehicles  en procés de disseny (cotxes, motos,…) ja no necessiten vehicles físics: el 90% són proves virtuals. Per cert, va ser en el sí dels sistemes de producció del sector de la automoció que van néixer Kanban  i Lean, dos dels àgils indiscutibles. 

Kanban ho va fer als anys 50 a Toyota, amb la voluntat de rebaixar els estocs, i assegurar que els materials, dins del procés productiu, hi són només quan calen. Feia i fa servir targetes (ara virtuals) que indiquen allò que cal produir. Sembla clar que va ser el precursor del mètode TPS (Toyota Production System) i posteriorment de sistemes com el Just in Time o Lean Management. Tant en els entorns de producció originals com en els de gestió, la seva idea és gestionar eficientment les càrregues de treball per optimitzar la feina que fa cada equip.

Lean també té els orígens a Toyota, però encara és més antic: 1937. El va plantejar Taiichi Ohno veient la baixa productivitat de la industria japonesa front els nous sistemes de producció en cadena als Estats Units. Té fortes relacions amb les idees de Kanban en el sentit de minimitzar els estocs alineant els mètodes a les necessitats dels clients, tot i que a Lean, el principi de la millora continua té un pes molt important. Aquell vell Lean ha evolucionat també –i tornem a parlar de gestió de projectes- cap el Lean Project Management, que té com a principi fonamental eliminar tot allò que no agrega valor al client, per centrar-se en aquelles activitats actuals que són imprescindibles per produir els resultats que espera el client. I això, sembla clar que ja fa olor als plantejaments àgil que coneixem ara.

Els mètodes àgils s’han fet molt populars per necessitats molt del nostre temps com les dels gerents d’un menor time-to-market, o les dels desenvolupadors que fan aplicacions per a mòbils, o videojocs, o productes d’animació, o d’anàlisi de novíssimes dades… Però també per la major exigència d’empatia amb les necessitats dels clients (empatia que ja s’accepta com un must de qualsevol projecte) alleugerant el que sovint era una enorme angoixa quan se’ls demanava als clients/usuaris que “definissin”, clara i irreversiblement, el que volien (requisits). Aquesta empatia amb el canvi (justificat per la sovint inevitable indefinició inicial) està en el positiu adjectiu alternatiu d’adaptatives que s’ha donat a aquests mètodes àgils.

Però les metodologies àgils no estan lliures de pecat original. I en força casos es van implementar de forma “elefantina” desplaçant els altres sistemes de la xatarreria TI, sense una acurada anàlisi de la realitat organitzativa i de les seves necessitats. Per això, després d’algunes doloroses experiències inicials, les empreses més intel·ligents, com ens diu l’informe Pulse 2018 del PMI, van tendir a incorporar progressivament els nous mètodes i sovint amb sistemes híbrids, aplicant unes metodologies o altres segons un seguit de paràmetres del projecte i altres consideracions de context com el tipus d’equips de treball, la organització o el finançament.

En l’altre costat del debat, les metodologies predictives (adjectiu que potser sona millor que el de clàssiques en un entorn tant de modernitats com el TIC), tenen un origen molt i molt diferent, com a mínim els seus dos referents principals, PMBOK i PRINCE2.

PMBOK és una proposta del PMI que neix al EEUU al 1969 fruit de les inquietuds d’un grup de cinc enginyers vers els problemes, especialment de nomenclatura, de pràctiques quotidianes i de comunicació, que anaven apareixent en un entorn on el treball per projectes començava a consolidar-se. Des de llavors, la vocació de les bones pràctiques proposades pel PMBOK ha estat sempre orientada a la millora de la feina de les directores i directors de projectes, en base a un treball  cooperatiu que ha portat al 2017 fins la seva 6a. edició. Creiem que és molt rellevant ressaltar que cada edició es millora a partir d’un treball entre milers de caps de projectes que voluntàriament treballen per actualitzar i millorar aquesta proposta de bones pràctiques. Potser per aquest ancorament en la realitat el PMBOK posa molt del seu focus en identificar aquells elements de l’entorn de les organitzacions que són clau per garantir l’èxit dels projectes. En aquest sentit situa una bona planificació el més complerta i treballada en cada moment com un element clau en els resultats, definint tant com es pugui l’abast, les tasques, els esforços necessaris, el pressupost, els riscos i els interessats, entre d’altres temes.

PRINCE2 és una proposta molt centrada en el sector TIC que és d’on va néixer: el CCTA, avui OGC del govern del Regne Unit. No es pot amagar que en el seu origen té un clar propòsit predictiu que apareix en el propi nom del mètode: “PRoject IN Controlled Environments (PRINCE). Buscava situar els projectes, doncs, en un entorn controlat i  gestionable. En el cas de PRINCE2, a diferencia de PMBOK, sí es pot parlar d’una metodologia de gestió de projectes, amb fluxos, processos, documents, rols, etc… Planteja fins a 7 temes claus: els plans (quant, com, quan), el canvi, la qualitat, els riscos, l’organització, el progrés del projecte i el Bussines Case.

Vists els plantejaments bàsics de cada costat i intuint la seva complementarietat, ¿perquè doncs el debat entre els mons adaptatius i predictius va tenir i té moments de certa radicalitat? Possiblement perquè el plantejament àgil es va presentar com la solució als problemes de les metodologies predictives tradicionals. En algun moment va ser quasi un plantejament de bàndols, de tifosi, que va donar molt de joc (del que encara es troben alguns rastres). Però aquesta discussió sobre salvadors i pecadors ja comença a ser antiga i de poc interès per a les noves generacions que veuen amb naturalitat un món hibriditzat –líquid que diria el savi. A més, els principis, seguint Groucho, es poden anar adaptant també sense massa complexes i en bé del benefici comú. De fet, tant PMBoK com PRINCE2, en les seves darreres renovacions, han anat deixant-se amarar de les filosofies àgils: el primer ja té publicada, de la mà de Agile Alliance, una “Guía pràctica de Ágil”; i el segon proposa artefactes pràctics com l’agilómetre en el seu Prince2Agile moviment. A més, el món ágil ha desbordat del tot el seu àmbit natural inicial, el del desenvolupament de programari, per banyar àrees i projectes de tota mena, com per exemple, els de transformació organitzacional.

Afortunadament, doncs, sembla que sortim del món de les pureses, per anar al que realment preocupa a les i els caps de projecte, que no són les etiquetes sinó els indicadors pels quals serà valorat l’èxit del seu projecte.

Pere Mariné Jové,  PMP
Professor Col·laborador de la UOC en Direcció de Projectes, pmarine@uoc.edu

Josep Maria Marco-Simó

Professor dels Estudis d’Informàtica, Multimèdia i Telecomunicació de la UOC