La Amalgama del PMI + Agile Alliance

Agile, Project Management

La Amalgama del PMI + Agile Alliance

El pasado 3 de enero de manera oficial se confirmó una gran noticia: El Project Management Institute (PMI) ha firmado un acuerdo para integrar a Agile Alliance. El comunicado oficial puedes leerlo (link: https://www.agilealliance.org/agile-alliance-joins-project-management-institute-pmi/ text: aquí), entre otras cosas menciona: “El futuro de la gestión de proyectos, centrado en el éxito del proyecto impulsado por el valor entregado, no puede depender de distinciones rígidas entre los enfoques de entrega. La integración de Agile Alliance dentro de PMI solidifica aún más el liderazgo de PMI en la transformación de la profesión de proyectos. PMI Agile Alliance se beneficiará del alcance y los recursos globales de PMI, mientras que los miembros de PMI obtendrán un mayor acceso al liderazgo intelectual, las herramientas y los recursos de Agile, mejorando su desarrollo profesional y permitiendo un mayor éxito de los proyectos.” Para encuadrar un poco más de qué va todo esto: # El origen del PMI El PMI, fundado hace más de 50 años, el 3 de octubre de 1969 para ser exactos, ha sido la autoridad y referente a nivel mundial en gestión de proyectos. Durante décadas, la forma (ahora llamada “tradicional”) de gestionar proyectos de manera metodológica ha sido dictada por el PMI. (image: pmi-logo-1998-2024.webp) Es la casa de la prestigiosa certificación (link: https://www.pmi.org/certifications/project-management-pmp text: PMP o Project Management Professional), y un montón de certificaciones más… en gestión de riesgos, del cronograma o de tiempo, gestión de programas, de portafolios, etcétera. Además de incluir en años más recientes, certificaciones en Agilidad. **Nota #01:** El enfoque tradicional o **enfoque predictivo**, se refiere a la manera secuencial y por etapas de gestionar un proyecto, lo que se conoce de manera no oficial pero ampliamente difundida como** “Waterfall” o “Cascada”** (si te interesa conocer un poco más a profundidad sobre Gestión de Proyectos en Cascada, puedes leer el artículo que escribí al respecto (link: https://leonelzapien.com/blog/gestion-de-proyectos-en-cascada-waterfall text: aquí)). # El origen de Agile Alliance (link: https://www.agilealliance.org/ text: Agile Alliance), por otro lado, organización sin fines de lucro, fue fundada en 2001 después de la creación del (link: https://agilemanifesto.org/ text: Manifiesto Ágil ) por algunos de los firmantes del propio manifiesto (si te interesa conocer un poco más a profundidad sobre el Manifiesto Ágil, puedes leer el artículo que escribí al respecto (link: https://leonelzapien.com/blog/23-aniversario-n-manifiesto-agil text: aquí)), y fue creada “para personas que desarrollan software y ayudan a otros a desarrollar software para explorar, compartir ideas y experiencias”, con el propósito de propagar la adopción del mindset o mentalidad ágil, es decir, de un **enfoque adaptativo**. (image: agile-alliance-logo.webp) Al contrario del (link: https://www.pmi.org/ text: PMI), o de otras instituciones como (link: https://www.scrumalliance.org/ text: Scrum Alliance), (link: https://www.scrum.org/ text: Scrum.org), (link: https://www.scruminc.com/es/ text: Scrum Inc.), y una larga lista de etcéteras… **Agile Alliance no ofrece ninguna certificación**, y, de hecho, en un sentido promueve la experiencia en Agile sin necesidad de obtener una certificación necesariamente. (Si te interesa conocer un poco más a profundidad sobre Agile, puedes leer el artículo que escribí al respecto (link: https://leonelzapien.com/blog/que-es-agile text: aquí)), # La evolución del PMI y de Agile Por un lado, la gestión de proyectos tradicional evangelizada por el PMI no funciona muy bien que digamos en cierto tipo de proyectos (en entornos volátiles, inciertos, complejos, ambiguos, frágiles, que generan ansiedad, no lineales e incomprensibles… sí, todo eso). Por el otro lado, un hecho innegable es ante el crecimiento del movimiento Agile, el PMI se vio en la necesidad de incorporar también la perspectiva ágil a su catálogo. En su momento agregó la certificación (link: https://www.pmi.org/certifications/agile-acp text: PMI-ACP (Agile Certified Practitioner)), y en 2019 adquirió (link: https://www.pmi.org/disciplined-agile/ text: Disciplined Agile), con lo cual amplió su portafolio y profundizó en el enfoque ágil con certificaciones como Scrum Master, Agile Coach y Value Stream. **Nota #02:** Por cierto, como parte de la reestructuración y evolución que el PMI está haciendo, para este primer y segundo cuarto del 2025, estará liberando el **nuevo path de certificaciones de Disciplined Agile**, entre los cambios es reajustar la certificación de Scrum Master… pero una cosa a la vez, en cuanto haya novedades sobre este tema, pasaré por aquí con un artículo al respecto. El caso es que el entorno llevó al PMI a evolucionar, lo cual está en realidad bien. Por el otro lado, un movimiento que está tomando fuerza es el que plantea **“Agile is dead” o “Agile ha muerto”**. Muy personalmente no considera que sea así ni que no lo sea, sino todo lo contrario, simplemente que es necesaria una evolución para Agile también. Agile debe de evolucionar, al igual que el PMI, y también está tremendamente bien. Por un lado, **se tergiversó el tema con certificaciones para todo, al “por mayor”**, y por el otro lado, se ha logrado desviar un poco del enfoque en el mindset, en aportar valor, Agilidad no solo es mover post-its por un tablero y hacer retrospectivas temáticas de Harry Potter o los Avengers. Entonces, la evolución es más que necesaria. Es bonito y está bien. # La verdad es que no todo es Agile Pero siendo muy abiertos y evitando ser puristas, tampoco todo funciona con Agile o enfoque predictivo, es decir, con entregas incrementales y de manera iterativa… aquí me encanta poner un ejemplo que mi buen amigo (link: https://www.linkedin.com/in/sebastian-lopreto/ text: Sebastián Lopreto), desde Bariloche, Argentina, siempre menciona: “Cuando vos vas al dentista porque te van a extraer una muela (presuponiendo que el diagnóstico está hecho y no ha de otra opción), ¿le dices que te la quite de un tirón, o que te la quite de a poco, de manera incremental y cada dos semanas, hasta que tengas toda la muela fuera de tu boca?” Así que, aunque muchos “agilistas extremistas o puristas” pudieran decir que algo es agile o no lo es, muy personalmente soy un apasionado Agilista y practicante Lean, pero también soy PMP (de hecho, primero fui PMP antes que Scrum Master. De verdad. Hace casi 12 años que obtuve la certificación de PMP, y unos meses después la de Scrum Master de Scrum Alliance), así que siento que puede aportar bastante el conocer a profundidad ambas perspectivas, y, por lo mismo, siempre he dicho que debemos de utilizar la herramienta más adecuada a cada contexto. Volviendo al punto de si algo es agile (adaptativo) o es cascada (predictivo), el PMI pone sobre la mesa además el **“enfoque híbrido”**, en el cual conviven el enfoque predictivo con elementos del enfoque adaptativo, combina trabajo predictivo o en cascada con ágil.… Pero ¿No va esto contra toda la naturaleza del Manifiesto Ágil?… De nuevo: tal vez sí, tal vez no, tal vez todo lo contrario. (image: hibrido-01.webp) La verdad es que, como siempre digo, todo depende del contexto: Ser Agile no significa utilizar (link: https://leonelzapien.com/blog/que-es-scrum text: Scrum) o Extreme Programming, en esencia es un conjunto de valores y principios que, si se viven y se aplican, no importa que sea con un marco de trabajo, método o cualquier otra herramienta. He visto de primera mano los enfoques híbridos, y la verdad es que aportan muchos beneficios. Considero que se puede abordar conociendo ampliamente ambos enfoques, contextualizando con respeto cada herramienta, y de nuevo: Funcionan muy bien. # Ok, lo inimaginable ha ocurrido y se han unido el PMI y Agile Alliance… entonces, ¿ahora qué sigue? He escuchado opiniones muy encontradas. He escuchado a algunos puristas del PMI decir que están sumando a unos “hippies” al instituto. He escuchado a algunos puristas Agile darse de topes en la cabeza y decir que va contra la esencia Agile. Muy personalmente, veo mucho potencial en esta unión. En la “vida real”, siendo un apasionado Agilista y practicante Lean, aplicaba varias herramientas del mundo del PMI en mi día a día. Respetando sus formas, claro. Y funciona de las mil maravillas. (image: pmi-agile-alliance-01.webp) Así que, aunque solo el tiempo dirá si este movimiento ha sido acertado… algunos posibles “pros” y “contras” (dependiendo de cómo lo veas) pudieran ser: ### Posibles Pros: **1. Expansión a otros sectores.** El PMI tiene amplia presencia en industrias donde Agile no ha llegado (o no ha sobrevivido). Este apalancamiento podría ayudar a llevar Agile a esos recónditos lugares. (**Por ejemplo, el PMI acaba recientemente de sacar una certificación específica para la industria de la Construcción,** ¿sabías de esto?, ahora tomemos este ejemplo y consideremos las posibilidades en industrias que requieren cierta especialización). **2. Flexibilidad para la ocasión (¿Certificaciones híbridas?):** Como ya hemos mencionado, no todo es predictivo, no todo es adaptativo. También está lo “híbrido” justo a la mitad. Tal vez pueda ayudar esta amalgama. **3. Impulso (a través de recursos):** El PMI tiene una estructura sólida, esto quizá pudiera brindar de cierta formalidad a la Agilidad. **4. Mayor catálogo (¿En toda la industria?):** En última instancia, si hay oferta hay demanda. El catálogo de productos y servicios del PMI se va a reestructurar (vienen cambios en Disciplined Agile, como ya he mencionado), y esto posiblemente lleve a un cambio completo en la industria entera, recordemos en gran poder de apalancamiento del PMI, y tal vez acaben sumándose otras casas certificadoras a la ola. La clave no es un mayor catálogo, sino un catálogo más adecuado al contexto, y reitero que una certificación no garantiza la habilidad, solo tómalo en cuenta. **5. Poder con Infinity (La IA del PMI):** El poder de la IA es innegable, pues bien, **el PMI tiene una IA particular llamada Infinity** (no es genérica como ChatGPT, Gemini, Claude, etc.), esto pudiera ser una catapulta si se hace específica incorporando Agile y enfoques híbridos. ### Posibles Contras: **1. Burocratización:** El 3er Pro, la estructura sólida del PMI, bien podría ser un elemento en contra pues es una posibilidad que se vuelva rígida, lenta e inflexible a la agilidad. **2. Pérdida de la esencia:** El tan mencionado y ambicionado mindset ágil ¿Podrá sobrevivir dentro de la esencia del PMI sin perder a su vez su esencia?, ¿Podrá emerger algo como una esencia combinada, y es esto posible? **3. Disolución:** Una posible línea de certificaciones nuevas del PMI, pudiera diluir el enfoque, como he mencionado anteriormente, vienen cambios este 2025 en Disciplined Agile. # Otros dicen que ambos ya han muerto Una postura satírica y que la verdad me ha dado mucha risa, es la de (link: https://www.comicagile.net/ text: Comic Agile) (famosa empresa conocida a nivel mundial por hacer tiras cómicas que satirizan todo… (link: https://leonelzapien.com/blog/que-es-agile text: Agile), (link: https://leonelzapien.com/blog/que-es-scrum text: Scrum), (link: https://scaledagile.com/ text: SAFe), (link: https://less.works/ text: LeSS), al propio (link: https://www.pmi.org/ text: PMI), etc.), que ha hecho un post (puedes leerlo (link: https://www.linkedin.com/posts/comicagile_agile-projectmanagement-pmi-activity-7281237516727275520-dizk?utm_source=share&utm_medium=member_android text: aquí)), donde menciona que no solo Agile ha muerto, sino que también el PMI. Aquí te comparto su tira cómica al respecto, la cual dice: - Agile Alliance y el PMI uniendo fuerzas es un trato (o un partido) hecho en el cielo - ¿Por qué? - Porque ambos están muertos. (image: comic-agile-pmi-agile-alliance.webp) **Aclaración: Esta es una sátira de Comic Agile y no refleja para nada mi punto de vista**, solo estoy compartiendo la información desde la perspectiva de distintas fuentes de la manera más objetiva posible. Finalmente, Pierre Le Manh, actual presidente y CEO del PMI hace el anuncio oficial sobre esta unión, si te interesa, puedes leerlo (link: https://www.linkedin.com/posts/pierre-le-manh-3a4158_agile-projectmanagement-leadership-activity-7280964881137242112-Dt0c/?utm_source=share&utm_medium=member_android text: aquí). # Conclusiones Pues bien… el hecho es que la unión entre el PMI y Agile Alliance ha ocurrido. Hay muchísimas preguntas sobre lo que podría venir, nuevas… ¿perspectivas, certificaciones, puntos de dolor?, aún estamos en una etapa muy inicial como para saberlo. Personalmente veo esta unión como algo positivo, considero que nunca se ha tratado de **“PMI vs Agile”**, sino de centrarnos en las personas, aportar valor, adaptarnos y utilizar las herramientas adecuadas a cada contexto. **Las expectativas son muy altas y las posibilidades infinitas.** Ahora, veamos lo que está por venir. ### ¿Qué opinas sobre esta unión?

6 de enero de 2025

Agile

A 23 años del nacimiento del Manifiesto Ágil

Hoy, aprovechando la fecha, vamos a platicar un poco sobre lo que se conoce como el “Manifiesto Ágil”, que es la piedra angular con la cual surge oficialmente el movimiento **agile** (traducido al español como **agilidad** o **agilismo**), que nació un 12 de febrero de 2001 (al momento de escribir este artículo, hace 23 años). Su nombre completo es “Manifiesto por el Desarrollo Ágil de Software”, el cual propone 4 valores y 12 principios que destilan en una manera de pensar o mindset, para abordar un enfoque ligero y adaptativo, un enfoque que nos ayude a responder al cambio, el cual es la esencia de la agilidad o agilismo. No te preocupes, no va a ser una charla de historia aburrida (espero), sobre el Manifiesto, pero sí conversaremos algunos puntos relevantes. ¡Comencemos por el principio! (image: agile-manifesto-leonel-zapien-lopez-ideas-agilidad-06.webp) # Contexto Histórico A finales de la década de 1980, estaba en una etapa de crecimiento la industria del software, pero había puntos de dolor en común que personas alrededor de todo el punto sufrían: Problemas con los tiempos de entrega, con la respuesta y expectativa del cliente o usuario final cuando finalmente (después de varios meses o años inclusive), por fin veía su producto anhelado… y la brecha entre lo que él o ella esperaban contra lo que se había construido. Todo esto tenía una causa raíz: Tratar de planear y diseñar de manera anticipada absolutamente todo al detalle, pero todo-todo, lo que el cliente o usuario necesitaría, para después construirlo y que, hasta el final, este cliente o usuario, viera su producto funcionando. Esta es la forma en que se trabaja en la industria por aquel entonces… (lo bueno es que esa manera de trabajar ya ha quedado atrás, ¿verdad?). Bajo esta premisa, diversos especialistas del área de software se reunieron como respuesta a los métodos tradicionales y formales con los que se trabajaba entonces en la industria. Fue un ¡basta ya! a las prácticas tradicionales, un llamado a la acción. # Cada uno estaba experimentando con sus equipos Había un grupo de profesionales en el Desarrollo de Software, cada uno había estado experimentando durante algunos años con maneras alternativas y bastante radicales de trabajar (radicales para la época), de crear productos, y habían estado obteniendo resultados súper reveladores en distintos contextos. Por un lado, había figuras que habían creado marcos de trabajo como **Scrum**, **Extreme Programming (XP)**, **Crystal**, entre otros. Pero eran esfuerzos en mayor medida aislados, cada quien trabajaba en su isla, y la idea era que entre todos estos Rockstars del Desarrollo de Software, cocrearan algo superior y que unificara estas formas nuevas de trabajar. # Todos acuden al llamado Kent Beck, creador del mencionado Extreme Programming (XP), fue quien convocó a una reunión, y dado que en aquella época no había Zoom ni Teams, se programó una reunión presencial. El lugar: **Snowbird, Utah**. El propósito: Tratar sobre técnicas y procesos para desarrollar software. Así lucía Snowbird en aquella ocasión: (image: agile-manifesto-leonel-zapien-lopez-ideas-agilidad-01.webp) Atendieron el llamado un total de **17 expertos nivel Master Jedi**, hicieron un retiro en Snowbird durante un par de días, y el lunes 12 de febrero de 2001, se acuñó el término **Agile** para definir a los métodos y marcos que estaban surgiendo como alternativa a las metodologías tradicionales de desarrollo, a las que consideraban excesivamente “pesadas” y rígidas por su carácter normativo y altísimo grado de dependencia de planificaciones detalladas previas al desarrollo. Lo que se buscaba con estas nuevas maneras de trabajar agrupadas bajo el término Agile era proporcionar en poco tiempo piezas pequeñas de sistemas de software en funcionamiento, para mostrarlas directamente al cliente en periodos cortos de tiempo, obtener retroalimentación rápida, y con esto ayudar a mejorar la satisfacción del cliente. Estos marcos utilizan enfoques flexibles pues aceptan los cambios que puedan surgir en las diferentes etapas del ciclo de vida, en lugar de resistirse a ellos. (image: agile-manifesto-leonel-zapien-lopez-ideas-agilidad-05.webp) (image: agile-manifesto-leonel-zapien-lopez-ideas-agilidad-02.webp) ### Nota #01: El término **Agile** lo podrás encontrar en español traducido como **Agilidad o Agilismo** (Agilismo es un término con el cual concuerdo más, pero es relativamente muy reciente. ¿Por qué Agilismo y no Agilidad?, ya estoy preparando un artículo para conversar sobre esto, próximamente conversaremos). ### Nota #02: Por cierto, de manera inicial, a estas nuevas maneras de trabajar les llamaban “**Marcos ligeros**”, y el nombre Agile no fue la primera opción sobre la mesa, pero las otras opciones estaban ya en uso y había temas de derecho de autor. De esta reunión, los 17 asistentes resumieron los principios sobre los que se basan los métodos alternativos en los que estaban trabajando, y la esencia de esto quedó definida en 4 valores y 12 principios: Lo que ha quedado denominado como Manifiesto Ágil. # 4 Valores y 12 Principios Si bien este movimiento inició en el área de Desarrollo de Software, hoy en día es ampliamente utilizado en diversas industrias por millones de personas y equipos en todo el mundo. Los valores que promulga este manifiesto son: 1. **Individuos e interacciones** sobre **procesos y herramientas**. 2. ** Software funcionando **sobre **documentación extensiva**. 3. **Colaboración con el cliente** sobre **negociación contractual**. 4. **Respuesta ante el cambio** sobre **seguir un plan**. (image: agile-manifesto-4-valores-visual-agile-coach.webp) Los 17 autores del manifiesto aclaran que, "aunque reconocen la importancia de los elementos de la derecha, valoran más los de la izquierda". Esto es fundamental, ya que la Agilidad o Agilismo no dice, por ejemplo, que no se documente nada en absoluto (es por llevarse al extremo que Agile se considera algo “hippie” o “muy informal”), más bien se valoran más los elementos de la derecha. En este sentido, me gusta preguntar a los equipos: “Si nos centramos en el valor y la colaboración, ¿Qué es lo mínimo que necesitamos documentar?”. Estos cuatro valores se asientan en 12 principios: 1. Nuestra mayor prioridad es satisfacer al cliente mediante la entrega temprana y continua de 'software' con valor. 2. Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente. 3. Entregamos 'software' funcional frecuentemente, entre dos semanas y dos meses, preferentemente en el periodo de tiempo más corto posible. 4. Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto. 5. Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo. 6. El método más eficiente y efectivo de comunicar información al equipo de desarrollo, y entre los miembros del equipo, es la conversación cara a cara. 7. El 'software' funcionando es la medida principal de progreso. 8. Los procesos ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida. 9. La atención continua a la excelencia técnica y al buen diseño mejora la agilidad. 10. La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial. 11. Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados. 12. A intervalos regulares el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia. (image: agile-manifesto-12-principios-visual-agile-coach.webp) # ¿Y la evolución del Manifiesto Ágil? El Manifiesto se firmó hace 23 años y en su momento fue “la onda” (como decimos acá en México). Sin embargo, los métodos y marcos de trabajo que alineaba han evolucionado con el tiempo, lo cual está bien y es natural: Por ejemplo, siempre digo que el Scrum de 1995 (cuando fue presentado públicamente al mundo), no es el mismo que el Scrum de hoy, y la prueba está en que la Guía Scrum, el documento que sienta las bases de este marco de trabajo, se ha actualizado varias veces. Lo interesante es que **el Manifiesto Ágil nunca se ha actualizado en todo este tiempo**. (image: agile-manifesto-leonel-zapien-lopez-ideas-agilidad-04.webp) Muy personalmente considero que el Manifiesto debería actualizarse, por ejemplo, cambiar el “**Software funcionado**” por algo más genérico como “**Producto o entregable funcional**” (para quitar el foco de que solo se puede utilizar para desarrollar software). Pero no solo eso, sino ir un paso más allá, cambiándolo a: “**Producto o entregable funcional y valioso**”, ya que, el entregar un producto funcionando es una prioridad para obtener retroalimentación rápida del cliente y/o usuario final… pero el objetivo final no es solo que este producto funcione, sino que aporte **valor** a este cliente o usuario final en cuestión, que resuelva su necesidad, que le haga la vida más fácil. Y todavía un paso más allá es que estos productos o servicios generan un **resultado** que produzca un** impacto** en la vida de las personas. Esto debería ser el enfoque que conduzca el crear un producto o servicio, orientado totalmente en el cliente o usuario. …Y si vamos todavía un paso más adelante, en vez de productos que hagan la vida más fácil para las personas, **busquemos crear productos que enamoren! ** (Lo sé, soy un romántico incorregible, de esos chapados a la antigua 😊) # Conclusiones Si bien el concepto de Agile o Agilidad o Agilismo no es del todo nuevo, pues sus principios han sido ampliamente utilizados desde hace varias décadas, no es sino hasta febrero de 2001 cuando oficialmente nace la agilidad con el Manifiesto por el Desarrollo Ágil de Software. El Manifiesto es un documento histórico que cumple 23 años. Y el mundo de la Agilidad o Agilismo, como su esencia lo define, también ha ido evolucionando. Los diversos marcos de trabajo, métodos y/o herramientas que lo conforman no son los mismos que hace 20 años, todo evoluciona. **Últimamente está muy fresco el tema sobre si la Agilidad ha muerto**. Personalmente no creo que sea así, simplemente debe de evolucionar y nosotros junto con ella. Debemos ser capaces de demostrar su verdadero valor, y quizá los nombres puedan cambiar en el futuro, pero la esencia de la Agilidad o Agilismo probablemente permanezca y nos acompañe, quizá con otro nombre, quizá con un reboot. Todo, finalmente, es evolución. ### Feliz cumpleaños #23 al Manifiesto Ágil 😁 (image: leonel-zapien-lopez-ideas-agilidad-manifiesto-agil-agile-agilidad-agilismo-23-aniversario.webp) # Anexo: Como nota final, el Manifiesto Ágil fue firmado por: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland y Dave Thomas. Puedes leer el Manifiesto Ágil en su sitio original (link: https://agilemanifesto.org/ text: aquí). # Créditos de imágenes * Imágenes de los Valores y Principios del Manifiesto Ágil, son del genial arte de (link: https://www.linkedin.com/in/thevisualagilecoach/ text: Olina Glindevi), desde Estocolmo ((link: https://www.linkedin.com/in/thevisualagilecoach/ text: The Visual Agile Coach)). * Las fotografías de los días en Snowbird, publicadas por Alistair Cockburn (firmante del Manifiesto Ágil).

16 de febrero de 2024

Agile, Kanban

Reconsiderando la Agilidad Organizacional

“La Agilidad Organizacional no es creada poniendo juntos a varios equipos Agile, la Agilidad es creada cuando las interacciones entre los equipos son ágiles.” Klaus Leopold. Estuve leyendo en los últimos días el libro “Reconsiderando Agile”, de Klaus Leopold. Es un libro lleno de aprendizaje, geniales ilustraciones y muy divertido. Aquí comparto un resumen de algunas de las ideas principales de este tremendo libro. Klaus nos lleva de la mano a una organización cualquiera, que quiere comenzar a “implementar agilidad” para estar preparada para el futuro. Este punto es, ya de entrada, un tema muy común cuando se ve la Agilidad Organizacional como una moda, y su implementación como seguir una receta de cocina. En esta organización, después de todo un proceso de transformación, que llevó meses de capacitación, reestructuración y definición de nuevos roles y equipos, los números indicaban que la compañía estaba lejos de ese objetivo inicial:** Llegar más rápido al mercado (esta métrica se conoce como TTM o Time To Market).** ¿Por qué llegar más rápido al mercado es una prioridad? Porque el ciclo que va desde idear una iniciativa o producto nuevo hasta que llega a las manos del cliente, debe de ser lo más corto posible, porque lo que se busca es llegar al cliente para que nos proporcione retroalimentación real de nuestro producto o servicio. Solo así una organización será capaz de inspeccionar y adaptar en base a lo que está entregando a mercado, ser flexibles en base a lo que el mercado demanda. Esto es esencial para sobrevivir. Es en este punto cuando llaman a Klaus (en el libro no menciona a detalle cómo lo llaman, pero de seguro fue por una especie de “batiseñal”). (image: batisenal.webp) Al analizar la situación de esta organización, identifica varios hallazgos críticos para alcanzar esa Agilidad Organizacional que con tanta añoranza buscan. Y para ello, ofrece algunos puntos muy interesantes que les pueden ayudar: # 1. Hacer visibles las dependencias y gestionarlas Todos los equipos y todas las organizaciones tienen dependencias, dependen de otros equipos para poder concluir su trabajo. Esto es normal e inevitable. El problema es que muchas veces estas dependencias externas se traducen en tiempos de espera, es decir, mi equipo depende de otro equipo para que complete determinada tarea que yo necesito y solo ellos realizan, proporcione una validación o aprobación, entre otras cuestiones. Esto genera tiempos de espera, debo de esperar a que el otro equipo tenga capacidad para atender mi solicitud. El primer punto para gestionar las dependencias es hacerlas visibles, el objetivo es eliminar las que más sea posible y reducir el tiempo de espera en aquellas que no puedan eliminarse. Para esto, el primer paso fue generar esta visibilidad mostrando el trabajo de todos los equipos y sus interacciones, esos momentos en que el trabajo “sale” de un equipo para ingresar al flujo de algún otro equipo, y después, cuando este trabajo es completado, cómo “regresa” al equipo original para que esta pueda continuar su trabajo. (image: leonel-zapien-lopez-ideas-agilidad-rethinking-agile-kanban-scrum-klaus-leopold-team-dependencies.webp) Una propuesta para organizar las dependencias fue organizar el trabajo en torno a productos, y visualizar estas dependencias ayuda a hacer más ágil las interacciones entre equipos, que la comunicación fluya lo más rápido y de manera adecuada entre equipos. # 2. Integrar el flujo completo Es muy importante visualizar el flujo de valor completo, es decir, todos los pasos relevantes del proceso que una organización necesita para producir un producto o servicio. Esto fomenta a que no veamos el trabajo que los equipos generan como algo aislado, sino de “punta a punta”. Si lo que queremos es mejorar el tiempo para llegar al mercado (desde idear una iniciativa o producto nuevo hasta que llega a las manos del cliente), entonces tenemos que ver la fotografía completa de este flujo de valor. Lo que sucede antes de que el trabajo llegue a mi equipo, se conoce como **“Aguas arriba” (Upstream)**. Después el trabajo llega a mi puerta (está en mi “cancha”, como decimos acá en México), y por lo tanto comienzo yo a trabajar en esto. Cuando “termino mi parte”, lo paso a la siguiente cancha, a que continúe con su flujo **“Aguas abajo” (Downstream)**, y ahora otro equipo o área puede comenzar su trabajo. (image: leonel-zapien-lopez-ideas-agilidad-rethinking-agile-kanban-scrum-klaus-leopold-01upstream-and-downstream.webp) Si queremos ser ágiles a nivel organización, de poco o nada sirve que a nivel individual cada equipo sea súper-archi-requete-rápido o mega-efectivo o de alto desempeño o “ágil”, si al final del día, lo que sucede aguas arriba o aguas abajo sigue siendo no-ágil. Por eso es necesario visualizar el flujo completo e integrar Upstream y Downstream en un solo flujo de valor. En este sentido, Klaus Leopold nos dice que **“La cuestión no es respecto a cuántos pasos de Upstream son parte de mi flujo de valor, sino cuán rápido esos pasos son”.** Visualizar las dependencias y el flujo completo no es la solución a todos los problemas, lo realmente importante es que detona las conversaciones necesarias para que se den las situaciones que resuelvan estos problemas. Un mejor tiempo para llegar al mercado tiene que ver con tomar decisiones frecuentes que ayuden a mejorar el flujo de trabajo a través de la colaboración entre equipos. (image: leonel-zapien-lopez-ideas-agilidad-rethinking-agile-kanban-scrum-klaus-leopold-01complete-value-stream.webp) # 3. Gestión estratégica del Portafolio La Agilidad Organizacional integra todo el flujo de valor, Upstream y Downstream, ¿Qué tan “aguas arriba” debo comenzar?, desde el nivel superior, donde nace la estrategia. Los niveles directivos deben de integrarse también, por lo tanto, también se debe de visualizar y gestionar todo lo que sucede a nivel portafolio, las iniciativas de negocio que se van a iniciar y su importancia de acuerdo con la estrategia. Esto se llama Gestión estratégica del Portafolio. El objetivo es alinear todo en un flujo continuo, es decir, no iniciar más iniciativas de las que los equipos tienen capacidad de ejecutar. Se busca crear un flujo de trabajo alineado, no generar demasiado WIP o trabajo en progreso, sin importar si hablamos de nivel operativo o estratégico. Recordemos que el objetivo es llegar lo más rápido posible a mercado, para obtener retroalimentación real del cliente o usuario final, para medir ese impacto real, ese valor que nuestro producto o servicio realmente le está entregando, y con esto ajustar lo que sea necesario (pero no solo a nivel equipos o a nivel operativo, sino desde el nivel estratégico). Con esto, se puede crear un continuo alineamiento estratégico. # Fligh Levels (Niveles de vuelo) Finalmente, Klaus Leopold introduce algo que llama el Modelo de Fligh Levels, lo cual describe como "una herramienta que ayuda a visualizar y organizar los distintos tipos de trabajo en una empresa”, desde la estrategia hasta las operaciones. Los tres niveles de vuelo son: ## Nivel 3: Gestión estratégica del Portafolio Una vista a nivel macro de todo lo que sucede en la organización, la estrategia e iniciativas que indican la dirección de la empresa. A este nivel no se tiene tanta definición como para poder ver (y microgestionar) algo tan granular como las actividades operativas. ## Nivel 2: Coordinación El enfoque en este nivel es la coordinación de inicio a fin de las actividades para convertir una idea en valor. Tiene menor visión general que el Nivel 3, pero ve una parte mayor de la fotografía que el Nivel 1. Como habíamos visto, la optimización a nivel equipos no es suficiente, debe de optimizarse también sus interacciones. Aquí es donde se busca optimizar estas interacciones entre equipos. ## Nivel 1: Nivel Operativo Es el nivel de vuelo más a nivel de suelo, a nivel donde los equipos realizan el trabajo diario. El trabajo a nivel equipo debe de ser optimizado (ya si le ponemos nombre, puede ser que los equipos trabajen con Scrum, Kanban, Extreme Programming, o cualquier opción entre los marcos y métodos ágiles existentes… digamos simplemente equipos Lean-Agile. Como habíamos visto, la optimización a nivel equipo es necesaria y se lleva a cabo en este nivel. Es fundamental realizar esto, para poder pasar al Nivel 2 para, digámoslo así: **“Optimizar las interacciones entre equipos optimizados”.** (image: leonel-zapien-lopez-ideas-agilidad-rethinking-agile-kanban-scrum-klaus-leopold-01-fligh-levels.webp) Este modelo de Flight Levels está muy interesante y es súper poderoso, definitivo es un tema que trataré de manera específica en un siguiente artículo. Pinky promise 😉 . # Conclusiones La Agilidad Organizacional no puede florecer si la organización está integrada de islas ágiles, es decir, de equipos optimizados que trabajan de manera “ágil-pero-aislada. Las interacciones entre equipos deben de optimizarse también, me gusta decirlo de esta manera: **“Optimizar las interacciones entre equipos optimizados”.** Por esto, menciona Klaus Leopold, la Agilidad Organizacional no tiene que ver con Equipos Ágiles o Equipos Agile… a nivel local un equipo Scrum o Kanban o Extreme Programming… o simplemente un equipo Lean-Agile, puede trabajar muy pero muy bien, pero ¿Cómo estamos como Organización?, Medimos puntos de historia de usuario entregados o elementos de trabajo completados… pero ¿Cómo andamos en métrica como organización? ¡Cuál es nuestro valor entregado y nuestro Tiempo para llegar al mercado? Comencemos por visualizar y gestionar el flujo de valor completo, desde que una idea se genera hasta que es entregado el producto o servicio al cliente o usuario final. **Si el usuario final no es feliz, poco importa que nuestro equipo sea el mejor equipo Scrum o el mejor equipo Kanban de toda la galaxia.** **¿Qué te parece esta aproximación de Agilidad Organizacional?, Me gustaría escuchar qué opinas.** . ## Referencias: • Rethinking Agile: Why Agile teams have nothing to do with Business Agility. Klaus Leopold (image: leonel-zapien-lopez-ideas-agilidad-rethinking-agile-kanban-scrum-klaus-book-portada.webp) * Todas las imágenes (a partir del punto 1. Hacer visibles las dependencias y gestionarlas), son propiedad de Klaus Leopold y LEANability.

12 de diciembre de 2023

Agile

¿Qué es Agile?

(Imagen: Depositphotos) El concepto de **Agilidad** o **Agile** no es del todo nuevo, pues sus principios han sido ampliamente utilizados desde hace varias décadas, sin embargo, todo comenzó a tomar forma en la industria de Tecnologías de la Información (TI), específicamente en el desarrollo de software, cuando los individuos de este sector se dieron cuenta de que se estaban presentando problemas críticos con la forma tradicional de gestionar proyectos (como la (link: https://www.leonelzapien.com/blog/gestion-de-proyectos-en-cascada-waterfall text: metodología de cascada o waterfall)), problemas que se veían reflejados en retrasos, entregables de mala calidad y baja satisfacción de parte del cliente. La metodología en cascada fue un parteaguas en la forma de trabajar, una propuesta para poner orden en el desarrollo de software, y aunque la idea tiene mucho sentido sentido: analizar el problema antes de diseñar una solución para después implementar ese diseño, en la realidad se tenían diversas áreas de oportunidad al momento de llevarla a cabo. Aun así, esta forma de trabajar dominó la industria durante varias décadas, desde su surgimiento en 1970… pero debía de haber otra forma de hacer las cosas. Durante finales de los años 80 y principios de los 90, comenzaron a surgir nuevas aproximaciones enfocadas en “procesos de peso ligero” (así se llamó inicialmente el enfoque ágil, dato curioso ¿no?), distintos al efecto cascada. Es entonces cuando surgen las primeras señales en Diseño Orientado a Objetos (ODD), Crystal Methods, Extreme Programming (XP) y Scrum. Ya estamos en 1995, y lo mejor está por venir! En febrero de 2001 un grupo de diecisiete líderes de desarrollo de software se reunieron en Snowbird, Utah, donde definieron las mejores prácticas para el desarrollo de software en base a su experiencia. La finalidad era llegar a un punto común sobre las diversas aproximaciones que estaban tomando forma por aquel entonces, y en conjunto formar un manifiesto que antepusiera la unidad. Es así como este grupo de personas elaboraron el (link: https://agilemanifesto.org/iso/es/manifesto.html text: Manifiesto por el Desarrollo Ágil de Software), en el cual propusieron un enfoque diferente para el desarrollo de software. El manifiesto describe cuatro características principales que se deberían de priorizar sobre otras cuestiones: 1. **Individuos e interacciones** sobre procesos y herramientas 2. **Software funcionando** sobre documentación extensiva 3. **Colaboración con el cliente** sobre negociación contractual 4. **Respuesta ante el cambio** sobre seguir un plan De acuerdo con lo establecido, los equipos de desarrollo ágil deberían valorar los elementos del lado izquierdo (en negrita) antes que los del lado derecho, lo cual puede dar lugar a mejores resultados en el desarrollo del software (aunque extrapolado, esto aplica para el desarrollo de cualquier producto). Agilidad o Agile no es una metodología, por lo tanto, no se refiere a una serie pasos que indican qué hacer exactamente durante el proceso de desarrollo de software. Agile es un marco de trabajo, y en su sentido más amplio es un *mindset* o forma de pensar, es un enfoque en la colaboración con base en un conjunto de valores. Algunas de sus principales ventajas son: 1. Mejora la calidad: Minimiza los errores en los entregables, mejora la experiencia y la funcionalidad para el cliente. 2. Mayor compromiso: Mejora la satisfacción de los integrantes y genera conciencia de equipo. 3. Rapidez: Acorta los ciclos de producción minimizando los tiempos de reacción y toma de decisiones. 4. Aumento de la productividad: Al asignar mejor los recursos, y de forma más dinámica, mejora el rendimiento. Los marcos de trabajo ágiles buscan proporcionar en poco tiempo piezas pequeñas funcionales del producto entregable (software en su concepción original), reduciendo el tiempo en que el cliente o usuario “interactúa” con este producto y de esta manera acortando el ciclo de retroalimentación. Esto lleva a que se obtenga directamente del cliente/usuario una respuesta del funcionamiento del entregable, una respuesta que sirve para ver si el camino que se está tomando es el correcto, por un lado, para quienes lo están construyendo (¿lo que se está construyendo es lo que el cliente espera?), y por el otro para el propio cliente o usuario (¿lo que están construyendo es aún relevante para el negocio y realmente lo que necesito?). Si en algún punto el cliente se da cuenta de que la dirección que se está tomando no es vigente por cualquier circunstancia, los cambios son bienvenidos en cualquier momento, y no es necesario esperar hasta el final del proyecto cuando el producto esté terminado para saber si lo que se construyó es lo que se tenía en mente y lo que se necesitaba. **Conclusiones** Si bien el concepto de Agilidad o Agile no es del todo nuevo pues sus principios han sido ampliamente utilizados desde hace varias décadas, este término surge de la industria del desarrollo de software. Aunque desde finales de la década de los 80 comienzan a aparecer las primeras aproximaciones de marcos de trabajo ágiles, no es sino hasta febrero de 2001 cuando oficialmente nace la agilidad con el (link: https://agilemanifesto.org/iso/es/manifesto.html text: Manifiesto por el Desarrollo Ágil de Software). Los marcos de trabajo ágiles de desarrollo de software buscan proporcionar en poco tiempo piezas pequeñas de sistemas de software en funcionamiento para mejorar la satisfacción del cliente/usuario. Estos marcos utilizan enfoques flexibles pues aceptan los cambios que puedan surgir en cualquier momento en lugar de resistirse a ellos.

21 de febrero de 2021

Project Management

Gestión de Proyectos en cascada (waterfall)

De acuerdo con el Instituto de Gestión de Proyectos o PMI por sus siglas en inglés (Project Management Institute, el cual es una organización estadounidense sin fines de lucro que asocia a profesionales relacionados con la Gestión de Proyectos), un proyecto es un esfuerzo temporal, con una fecha de inicio y fin determinadas, y que tiene como finalidad crear un producto, servicio o resultado único. La Gestión de Proyectos se define como un conjunto de conocimientos, habilidades, herramientas y técnicas para describir, organizar y monitorear el avance de las actividades de un proyecto para lograr los objetivos del mismo. Todo proyecto tiene un ciclo de vida que se refiere a la serie de fases por las que éste atraviesa desde su inicio hasta su conclusión, y proporciona el marco de referencia requerido para dirigir el proyecto en cuestión. La mayoría de los proyectos están divididos en estas fases, y sin importar si son pequeños o grandes, todos tienen un ciclo de vida y estructura similar. Las fases de un proyecto consisten de segmentos de trabajo que permiten una fácil gestión del mismo, algunos proyectos pueden tener una sola fase en tanto que otros pueden contener múltiples. Este número de fases puede variar dependiendo de la complejidad del proyecto, así como de la industria en la que se crea el mismo. Los ciclos de vida pueden ser predictivos, iterativos, incrementales, adaptativos o híbridos. Si bien hablaré de diversos ciclos de vida en otras entradas de mi blog, para el tema en cuestión, nos centraremos en este momento en los ciclos de vida predictivos: · **Ciclo de vida predictivo**: El alcance, tiempo y costo del proyecto son determinados en las fases iniciales del mismo, por lo que también se les denomina ciclos de vida en cascada (del inglés “waterfall”). La metodología en cascada es la metodología de Gestión de Proyectos de mayor difusión y uso durante los pasados 40 años, y hasta bien entrada la década de 1990, la mayoría de los proyectos se ejecutaban utilizando esta metodología, donde un proyecto se completaba en etapas separadas y avanzaba paso a paso hacia el lanzamiento último a los clientes finales. El nombre de “cascada” proviene de la similitud en que las fases son representadas, una después de la otra, como se muestra en la siguiente figura: En el método de cascada, cada paso o etapa debe de ser completado al 100% antes de moverse al siguiente, y todas estas etapas deben de ser completadas antes de entregar valor al cliente. Este método es conocido como “conducido por el plan” (del inglés plan-driven) debido al nivel de diseño y conceptualización que se realiza al inicio del proyecto, y se pasa por todas los grupos de proceso de gestión que indica el PMI: Inicio, planeación, ejecución, monitoreo y control, y finalmente el cierre. Este proceso, de levantar todos los requerimientos en la etapa inicial, si bien era funcional hace unas décadas, hoy en día es complicado de mantener debido a la evolución del entorno: El dinamismo de los mercados actuales, proyectos más complejos y ciclos de vida de productos cada vez más cortos. La etapa de análisis era por lo general lenta y tenía un alto grado de imprevisibilidad, lo que resultaba, por un lado, a menudo en un producto final o entregable distinto de lo que el cliente esperaba, y por otro lado, en un retraso de meses o inclusive hasta años para que el cliente viera resultados tangibles. Es por esto que, la tradicional metodología de cascada para la gestión de proyectos ha necesitado evolucionar, a la par que los marcos de referencia ágiles han ido creciendo en popularidad desde la década de 1990, siendo actualmente bastante utilizados (punto que por cierto abordaré a detalle en otras entradas de este blog). ### **Conclusiones** La metodología de cascada ha liderado la gestión de proyectos durante los últimos 40 años, nos ha enseñado la gestión de la integración del proyecto, del alcance, del tiempo, de los costos, de la calidad, de los recursos humanos, de las comunicaciones, del riesgo, de las adquisiciones, y de los interesados o stakeholders. En esta metodología los requerimientos se definen al inicio y se realizan todos los planes subsidiarios para posteriormente comenzar con la ejecución del proyecto, pero las condiciones del entorno actual requieren mejor manejo de la incertidumbre, especialmente en entornos complejos en los cuales los marcos de trabajo ágiles han demostrado ser bastante eficientes, razón por la cual estos marcos de trabajo han ido aumentando en popularidad en los últimos años.

16 de junio de 2020

El bloc de notas de un Agilista Jedi