Cómo Hacer que Ágil Funcione con Metagility (con David Bishop de Agile Worx)

Lee la transcripción:

Estamos probando transcribir nuestros podcasts con un programa de software. Por favor, disculpa cualquier error tipográfico, ya que el bot no es 100% preciso.

Ben Aston: Déjame adivinar, hacías las cosas en cascada y no funcionó, y entonces intentaste con Ágil y bueno, tampoco fue tan bien.

Así que ahora estás mezclando y combinando. Tienes algo de Ágil y algo de cascada y estás intentando encontrar algunos toques finales para mejorar. Bueno, sigue escuchando el podcast de hoy sobre metagility. Puede que aprendas un par de cosas sobre cómo un playbook ágil puede usarse para combinar lo mejor de ambos mundos.

Gracias por escucharnos. Soy Ben Aston, fundador de The Digital Project Manager. Bienvenido al podcast de DPM. Tenemos la misión de ayudar a los gerentes de proyectos a tener éxito, ayudar a las personas que gestionan proyectos a brindar mejores entregas. Estamos aquí para ayudarte a llevar tu gestión de proyectos al siguiente nivel. Revisa thedigitalprojectmanager.com para conocer la formación y los recursos que ofrecemos mediante la membresía. Este podcast es presentado por Clarizen, el líder en software de gestión de proyectos y portafolio empresarial. Visita Clarizen.com para más información.

Hoy me acompaña David Bishop y el Dr. David Bishop es un tecnólogo. Es consultor. Es un emprendedor de investigación e instructor con más de 25 años de experiencia en el sector Telco, transporte, gobierno y servicios públicos. Es el CEO y fundador de Agile Worx, LLC. Puedes consultarlo en Agile-worx.com. Son una empresa que ofrece herramientas de software de gestión de programas y proyectos, formación y servicios de consultoría. Y es el autor de Metagility: Managing Agile Development for Competitive Advantage. Así que muchas gracias por acompañarnos hoy, David.

David Bishop: Gracias por invitarme.

Ben Aston: Y quiero profundizar en la idea de construir un marco desde cero. ¿Puedes contarnos un poco sobre tu trayectoria y cómo decidiste que el mundo necesitaba un nuevo framework? ¿Cuál es tu experiencia que te llevó a ese punto?

David Bishop: Claro. Llevo en el negocio del desarrollo tecnológico unos veinticinco años, principalmente como arquitecto y jefe de sistemas, desarrollando soluciones con nuevas tecnologías. Y en el negocio de IT, así como en IATA, telecomunicaciones, etc. Como comentaste antes, hace unos 10 años empecé a trabajar con una empresa profundamente inmersa en IoT industrial y uno de los mayores retos era adoptar metodologías Ágiles.

Ben Aston: Correcto.

David Bishop: La razón de eso era porque sus clientes lo pedían al estar en una industria tecnológica emergente. Aunque la industria era conocida, la tecnología era nueva. Intentaban integrarse en ese sector, compitiendo contra muchos otros desarrollando nuevas tecnologías de redes inteligentes con varias comunicaciones RF.

Detrás de todo ello estaba la tecnología. Intentaron adoptar Agile varias veces porque era vital sacar sus productos al mercado lo antes posible. Lo intentaron muchas veces, con consultores muy caros, pero fracasaron estrepitosamente. Una y otra vez. Y yo era parte de ello. Ayudaba en el desarrollo de esos productos y también en la adopción de Agile en el proceso. Y pensé que debía haber otra manera de hacerlo.

¿Por qué los consultores inteligentes que contratamos tenían tantos problemas? Me di cuenta de que, aunque Agile ha tenido mucho éxito y sin duda es una gran idea, presenta carencias. Una de ellas son los inconvenientes con equipos distribuidos, grandes equipos, así como entornos de desarrollo y productos complejos. Eso puede ser un gran desafío para quien intenta adoptar metodologías Agile en su forma pura.

Ben Aston: Totalmente. Cuéntanos un poco más sobre tu experiencia con esos proyectos. Me interesa saber cómo era en el día a día. Puedo entender la imagen global de los retos de implementar Agile, pero ¿cómo se veía eso en el día a día dentro del proyecto? ¿Cuáles eran las señales de advertencia de que algo no iba bien?

David Bishop: Había una resistencia tremenda en algunos equipos. No sólo una resistencia leve, era auténtica oposición y quejas de que el proceso no funcionaba y no podría funcionar. Esto era porque se trataba de un entorno de sistemas embebidos. Como se desarrollaban productos de IoT industrial, eran dispositivos, no sólo software. Los dispositivos se componen normalmente de hardware, firmware y software, desarrollados por equipos, departamentos o incluso empresas distintas.

Pero al final, todos esos componentes debían probarse y lanzarse como un producto cohesivo. Eso es lo que hacía la empresa. Y ahí es donde hoy ocurre gran parte de la innovación. Hace veinte años, cuando surgió el manifiesto Ágil, todo era software. Ahora no es sólo software.

Ahora es sobre dispositivos, dispositivos inteligentes, medidores inteligentes, coches conectados, tu propio teléfono… Todo es un sistema embebido hoy en día. Así que las empresas que desarrollan esos productos tienen los mayores problemas con la agilidad debido a la complejidad. Y en el día a día, trabajábamos con los consultores. Decían: “tenéis a vuestros equipos de software trabajando a dos semanas, haciendo dailys, pero no conseguimos que los de hardware hagan lo mismo. No lo ven necesario”.

Ben Aston: Exacto.

David Bishop: Y los de firmware igual. Decían: “no tiene mucho sentido para nosotros, no funciona igual”. Y era cierto, porque los equipos de software iban mucho más rápido, podían desarrollar en iteraciones. Pero eso no funcionaba igual para hardware, cuyos productos tenían ciclos de lanzamiento de 12 a 18 meses.

Integrar nuevos chipsets y probar el hardware lleva mucho tiempo. Además, la mayoría de las organizaciones que desarrollan sistemas embebidos suelen estar en industrias muy reguladas, con alto cumplimiento normativo y supervisión gubernamental.

Si piensas en medidores inteligentes, coches inteligentes o sistemas de aviónica, imagina qué está en juego: posibles pérdidas de vidas o fallos catastróficos. Deben cumplir estándares mucho más altos de calidad, rendimiento y éxito que una simple aplicación web o ecommerce.

Ben Aston: Eso es cierto.

David Bishop: Ahí es donde predominó Agile: en industrias donde más pronto se asimiló la metodología.

Ben Aston: Si quieres leer más sobre el origen de Metagility, puedes revisar la publicación en thedigitalprojectmanager.com. Ahí se narra cómo fue evolucionando la creación del libro. En vez de indagar en esa historia, quiero profundizar en el propio marco y ver qué podemos aplicar a nuestros proyectos. Creo que esto es muy relevante, pues muchos hemos probado elementos de cascada.

Hacemos cosas secuencialmente porque parece lógico, dependiendo de nuestros stakeholders y estructura de engagement. Pero también probamos cosas de Agile, colaboramos y trabajamos iterativamente. Hay bits y piezas que tomamos. Creemos en la filosofía de iterar y entregar valor frecuentemente.

Construir, testear, aprender. Pero también debemos trabajar de forma secuencial. Quiero hablar de metagility y cómo aplicarlo en nuestros proyectos. La realidad es que la metodología Agile es popular. Es ampliamente aceptada como la mejor manera de gestionar desarrollo de software. Pero el significado de Agile es abierto a interpretación.

Como comentamos, es un reto para la mayoría de las empresas. Así que este enfoque híbrido, aunque raras veces se considera la mejor solución, es de hecho el resultado por defecto para muchos, al intentar combinar marcos y métodos de trabajo con las restricciones de cada organización. Como comentábamos: el ciclo de hardware es más largo, el middleware va en medio…

Construir para lanzar a la misma cadencia es el reto. Pasa también en desarrollo web donde UX y diseño pueden trabajar rápido, pero desarrollo tarda más tiempo. Quiero hablar sobre las limitaciones de los métodos Agile actuales, lo que mencionas en tu libro.

Cuando identificas esas limitaciones (ciclos, lanzamientos, cadencia), ¿puedes profundizar en esos límites? Comparemos, por ejemplo, a nivel alto de SAFe y bajo de Scrum. ¿Cuáles ves tú como limitaciones?

David Bishop: Cuando analizas esos frameworks como Scrum, Kanban y otros, DSDM, LeSS, DA (Disciplined Agile, recientemente adquirido por PMI), todos intentan abordar el problema desde distintos ángulos.

Ben Aston: Sí, no compro un framework, está bien.

David Bishop: Ponen el foco en diferentes razones para asimilar Agile. La gente suele tener un enfoque equivocado. Hay mucho hincapié hoy en adoptar Agile porque mejora la cooperación o la eficiencia. Eso está bien.

Pero, el verdadero objetivo de Agile era la competencia. Ser el número uno en tu mercado. El manifiesto Agile deriva del Lean manufacturing, técnicas del sistema Toyota originadas en un artículo de 1979. ¿Qué logó Toyota? Pasó de fabricar coches malos a ser el fabricante líder mundial.

La agilidad busca replicar ese éxito. Muchos frameworks, según mi opinión, lo olvidan. SAFe se enfoca en el nivel de empresa, tratando de agilizar todas las áreas, hasta legal o RRHH.

La idea es agilizar todo la empresa y esperar mejoras incrementales. Pero se enfoca demasiado en los procesos y la documentación extensiva, que recuerda a los largos SOP del pasado. En cierto modo, es lo opuesto a lo que Agile pretende.

Ben Aston: Exactamente.

David Bishop: Mientras Scrum se enfoca en equipos, Kanban en procesos, y pueden combinarse incluso con metagility y safe. Metagility se centra en el motor de desarrollo del producto: gestión de productos, proyectos, equipos de desarrollo y pruebas, cómo se desarrollan e interpretan los requisitos, cómo se lanzan y colaboran con el cliente para máxima calidad.

Si quieres ganar la carrera, te enfocas en motor y transmisión, no en los vidrios eléctricos. Algunos frameworks se concentran demasiado en la periferia, no en lo esencial para ser número uno.

Eso es lo que hace metagility. A partir de estudios de caso, identifica lo que hicieron bien las empresas más ágiles para que otros puedan replicar los resultados.

Ben Aston: Tú lo describes como un enfoque integral para gestionar una nueva y efectiva “raza” de identidad. ¿Es metagility un marco de entrega, una metodología o un playbook?

David Bishop: Prefiero llamarlo marco. Te lleva a través del proceso, y el primer paso en metagility es determinar qué tipo de adaptación ágil necesitas. En realidad, antes de eso, el libro enseña a pensar diferente, usando métodos científicos para la toma de decisiones de negocio.

También analiza cómo el manifiesto Agile ha cambiado según los hallazgos de la investigación. Pero al llegar a la parte de transformación ágil, lo primero es: ¿qué tipo de adaptación Agile implementar? ¿Puramente Agile? ¿Un enfoque híbrido? ¿O quedarse con cascada? A veces es lo mejor.

Hay mucha investigación peer-reviewed sobre este punto, que la mayoría de los consultores ignoran. Barlow publicó un estudio sobre cómo tomar esa decisión.

Eso se incluye en el libro, como un gráfico, mostrando que el tipo de implementación depende de la complejidad y tamaño del equipo. En casos con sistemas embebidos, productos complejos, equipos distribuidos, un enfoque híbrido bien ejecutado puede funcionar genial.

El enfoque híbrido suele ser visto negativamente porque muchos piensan en implementaciones fallidas. Pero eso es accidente, no diseño. Si se hace a propósito y con base científica, es muy valioso.

Ben Aston: Para quien no ha leído el libro, ¿cómo funciona el marco y cuáles son sus componentes?

David Bishop: En el libro hay un enorme esquema que detalla todo. Lo esencial de metagility es decidir el enfoque de transformación.

Ben Aston: ¿Y cómo se evalúa?

David Bishop: Usando la gráfica de Barlow incluida en el libro, que determina la decisión según tamaño de los equipos y complejidad del producto, así como el nivel de interdependencia entre equipos.

Esa complejidad indica si debes ir a un enfoque híbrido o más ágil. Metagility detalla los pasos para asimilar Agile por defecto. Por ejemplo, tus equipos de software pueden hacer sprints de dos semanas y dailys, los de firmware hacen sprints de 30 días y los de hardware, con sus ciclos largos, tal vez ni sprints tienen, sino algo más parecido a cascada, pero con técnicas como prototipado rápido para no frenar a los otros equipos. Lo importante es mantener el flujo durante todo el proceso.

Metagility detalla cómo los equipos adoptan conceptos Agile o cascada, usando “stage gating” como control y asegurando sincronización. El marco recomienda las métricas e interacciones, desglosando las interacciones en seis categorías (basadas en los casos de mayor éxito), y explica cómo implementarlas. Se convierte en una guía detallada para gestionar implementaciones ágiles híbridas.

Ben Aston: ¿Y cómo determinas la mezcla adecuada de características Agile? Sabemos que la gente suele rechazar el cambio. ¿Cómo determinas qué combinación es la adecuada y cuándo es suficiente el status quo o si hace falta una revolución en el proceso?

David Bishop: Usando métodos científicos y research de “engaged scholarship” o investigación participativa. Muchas veces las empresas toman decisiones por intuición o consenso, pero para una transformación tan desafiante como Agile, se necesitan métodos científicos más profundos. La investigación muestra que los entornos de sistemas de información son muy contextuales, lo que funciona en una empresa no necesariamente sirve en otra.

Al aplicar estudios de casos interpretativos y etnografías, puedes identificar qué es generalizable en diferentes organizaciones. Así descubres prácticas que sí funcionan universalmente. Pero lleva tiempo.

Ben Aston: Entonces no es un marco “talla única”, sino personalizable. Pero eso plantea el reto de cómo evaluar si una implementación es realmente metagility y cómo medir su éxito.

David Bishop: Exacto, y eso da pie al siguiente punto: la teoría de la “Vorticidad Ágil”. Además del enfoque híbrido y las conclusiones sobre interacciones, Metagility incorpora la teoría de vorticidad ágil surgida del research. Es una respuesta a la pregunta de cuán ágil es tu organización. Por años, la industria no tuvo forma de medir la agilidad, y Metagility lo proporciona, como explico en detalle en el libro. Permite medir el éxito.

Ben Aston: Entonces, en las organizaciones que han implementado tu marco, ¿qué impacto has visto? Hablamos al inicio de convertirse en el número uno en el sector y ganar competitividad. ¿Cómo lo has visto reflejado?

David Bishop: La mayoría de los estudios de caso fueron en sistemas embebidos, el sector más desafiante. Esas empresas han logrado la posición de líderes de mercado o muy cerca de ello. Se traduce en mayor cuota de mercado, más dispositivos en uso que la competencia, etc. Para nuevos mercados, ya seas gran empresa o start-up, la clave es obtener rápidamente cuota crítica antes que tus competidores.

Y Agile—en concreto Metagility—es la mejor forma de lograrlo: reduce ciclos de lanzamiento, mantiene calidad y satisfacción del cliente, y logra salir al mercado rápidamente.

Ben Aston: ¿Y dónde no funcionó bien la implementación de metagility? ¿Qué retos habéis visto, especialmente si falló?

David Bishop: Hay dos motivos. Uno esencial es el apoyo ejecutivo. Sin respaldo desde la alta dirección, cualquier transformación, ya sea digital o ágil, fracasa. Es clave que entiendan el objetivo y el impacto en los resultados.

El segundo motivo es la mala gestión de requisitos. Muchas veces, al abordar una transformación Ágil se pone el foco en desarrollo y pruebas, pero poco en los analistas de negocio o propietarios del producto. Estos deben cambiar la forma de definir requisitos. En cascada se trata de “recopilar requisitos”, en Ágil se desarrollan requisitos continuamente con el cliente. Si se queda en lo típico de intentar no olvidar nada y documentar todo, se produce deuda técnica y el proyecto fracasa ( por esto fallan las transformaciones Agile). En Metagility también puede darse si no cambias el método de trabajar requisitos.

Ben Aston: Totalmente. Si el proceso de requisitos se trata de recopilar, nunca acabas. Pero si soy nuevo en metagility, y me convence el enfoque de combinar diferentes cadencias y equipos, ¿por dónde empezar para obtener el mayor beneficio?

David Bishop: Debes establecer nuevas relaciones de colaboración con clientes. Uno de los pilares del manifiesto Agile es la colaboración con el cliente sobre la negociación contractual. La investigación hoy muestra que contrato y colaboración son realmente lo mismo, es un proceso continuo de negociación a todos los niveles entre stakeholders y el cliente. Es crítico encontrar clientes dispuestos a colaborar profundamente. Las organizaciones más exitosas seleccionan estratégicamente a sus clientes, rechazando incluso algunos, y sólo se asocian con los que comparten la visión de innovación y colaboración. Esa relación de confianza y visión compartida es el primer paso clave.

Ben Aston: Muy cierto. Muchas veces, por obtener negocio, aceptamos cualquier cliente, pero para entregar verdadero valor necesitamos el modelo de colaboración correcto y confianza. Eso permite innovación, y va mucho más allá que un simple contrato. Gracias, David, por acompañarnos y contarnos sobre metagility, ha sido muy útil.

David Bishop: Muchas gracias.

Ben Aston: Y me encantaría saber tu opinión. Si has leído el libro Metagility, cuéntanos en los comentarios. Si no lo has hecho, dejaremos un enlace. David, si la gente quiere saber más sobre metagility y tu libro —pondremos el enlace a Amazon—, ¿a dónde deben ir?

David Bishop: Puedes buscar “metagility” en Google y aparecen muchos recursos, o ir a Agileworx.com (Agile-worx.com) para ver nuestro trabajo. También tenemos cursos presenciales, que por ahora están aplazados hasta otoño, de agosto a noviembre, aunque podrían pasar a formato virtual. Consulta metagility.technology para la agenda, inscribirse a cursos o contactarme a David@agileworx.com (Agile-worx.com). Estoy disponible y reviso emails con frecuencia.

Ben Aston: Perfecto. Gracias, David. Y si quieres aprender más y avanzar en tu carrera, únete a la membresía DPM en thedigitalprojectmanager.com/membership. Obtendrás acceso a nuestro equipo de Slack donde debatimos sobre temas como este, además de acceso a plantillas, talleres, sesiones AMA, horas de oficina, ebooks y más. Si te ha gustado lo que escuchaste, suscríbete y mantente en contacto en thedigitalprojectmanager.com. Hasta la próxima, gracias por escucharnos.