Escalando Ágil (Con Giovanni Asproni De Zuhlke Engineering Limited)

Lee la transcripción:

Estamos probando la transcripción automática de nuestros podcasts con un programa de software. Por favor, disculpa cualquier error ya que el bot no es 100% preciso.

Ben Aston:

Bienvenido al DPM Podcast, donde vamos más allá de la teoría para ofrecerte consejos prácticos para liderar mejores proyectos digitales. Gracias por escucharnos, soy Ben Aston, fundador de The Digital Project Manager. Así que, todos están entusiasmados con Ágil, pero ¿cómo lo haces funcionar en varios equipos o proyectos? ¿Cómo se acelera el proceso y en qué puede salir mal? ¿Y cómo evitar que salga mal desde el principio? Sigue escuchando el podcast de hoy para comprender cómo podemos escalar la entrega ágil y cómo lograr que Ágil funcione a gran escala. Este podcast es presentado por Clarizen, el líder en software de gestión de proyectos y carteras empresariales. Visita clarizen.com para más detalles.

Hoy me acompaña Giovanni Asproni. Es el consultor principal en Zuhlke Engineering Limited. Probablemente lo pronuncié mal, pero él está basado en Londres. Es arquitecto de software, programador, coach, consultor, con amplia experiencia en diferentes sectores como la telecomunicación, la banca, el petróleo y el gas. Ha asistido a muchas conferencias y ha contribuido a varios libros. Así que, Giovanni, gracias por acompañarnos.

Giovanni:

Hola. Gracias por invitarme.

Ben Aston:

¿Y cómo deberíamos pronunciar el nombre de tu empresa?

Giovanni:

En realidad es un nombre suizo, debería pronunciarse Zuhlke.

Ben Aston:

Ah, ya veo. Bueno, nunca lo habría dicho bien.

Giovanni:

Yo mismo lo pronuncio mal todo el tiempo, así que no te preocupes.

Ben Aston:

Genial. Entonces, cuéntanos un poco a qué te dedicas ahora mismo, lo estábamos comentando antes, pero ¿cómo sería un día típico para ti?

Giovanni:

Bueno, un día típico para mí, por lo menos en estos días, es bastante ocupado. Empecé a principios de junio un nuevo proyecto, en el que estoy siguiendo mis propios consejos, lo cual es muy sabio. Sí, después de [inaudible 00:01:50] con un gran cliente de Zuhlke, junto con algunos colegas hicimos una evaluación de un programa de gran escala que tienen, hablamos de 500 personas, 57-60 equipos, algo así, y ahora estamos implementando parte de las recomendaciones, básicamente dotándolos de un sistema para recoger métricas de proyectos y programas y gestionar todo el esfuerzo mucho mejor. Así que está bastante ocupado, estoy haciendo… liderazgo técnico y requisitos, informando a todos los niveles de gestión en la empresa cliente, y también escribiendo algo de código cuando es necesario.

Ben Aston:

Genial, cuéntanos un poco sobre ese proceso de evaluación por el que pasan. Me parece interesante que no solo lleguen a una empresa diciendo "tienen que hacer Scrum", e intenten aplicarlo, sino que primero se hace una evaluación, ¿verdad?

Giovanni:

Sí.

Ben Aston:

¿Cómo es ese proceso?

Giovanni:

En una evaluación, intentamos entender qué está pasando, básicamente–

Ben Aston:

Sí.

Giovanni:

Hablamos con personas, representantes de los equipos, de la gerencia en todos los niveles e intentamos averiguar qué ocurre en el terreno, también revisamos procesos de los equipos, vemos cómo confirman código en el [inaudible 00:03:16], las acciones de calidad–

Ben Aston:

Sí.

Giovanni:

Hablamos con la dirección para conocer su visión. Así creamos un panorama de la situación porque este tipo de proyectos grandes suelen tener muchas similitudes, pero los detalles concretos suelen ser muy distintos.

Ben Aston:

Entonces, en cuento a tus recomendaciones, después de realizar estas evaluaciones en una empresa grande, ¿qué tan distintas suelen ser tus recomendaciones cuando se trata de implementarlas? ¿Termina siendo siempre lo mismo? Giovanni:

No, depende de lo que hallamos. Tengo que decir que algunas cosas tienden a repetirse, porque–

Mm-hmm (asintiendo).

Giovanni:

Simplemente porque tendemos a cometer los mismos errores de siempre.

Ben Aston:

Sí.

Giovanni:

Por darte un ejemplo: normalmente cuando las empresas hacen crecer sus programas a gran escala —hablamos de 100 personas, 200, en este caso 500. He visto llegar a 1,300 en un solo producto— lo hacen para avanzar más rápido, pero por lo general no tienen herramientas para saber si lo que están haciendo realmente está generando alguna ventaja.

Ben Aston:

Mm-hmm (asintiendo). Hablaste de herramientas, ¿cuáles usas para evaluar si la ampliación añadiendo recursos da resultado?

Giovanni:

Revisamos varias cosas; en mi artículo, cuando hablo de los requisitos previos para escalar, buscamos esos elementos. Intentamos verificar si todos entienden su función, si reman en la misma dirección. Te sorprendería ver cuán diferente puede ser la percepción de los objetivos del proyecto.

Ben Aston:

Mm-hmm (asintiendo)

Giovanni:

Terminan yendo en direcciones distintas. Así que buscamos uso de métricas, tienes equipos, tienes personas. ¿Cómo sabes que avanzan más rápido sin basarte en sensaciones y sí en datos reales, por ejemplo?

Ben Aston:

Mm-hmm (asintiendo). Sí.

Giovanni:

Miramos el diseño del sistema, la arquitectura y si se adapta a la estructura de los equipos. Hay muchas cosas, canales de comunicación, que en proyectos grandes suelen volverse muy formales y la gente es incapaz de resolver problemas rápidamente.

Ben Aston:

Sí, sí. Volviendo a tu experiencia de escalar Ágil o de trabajar en equipos ágiles: ¿te animas a contarnos cuál ha sido tu mayor metedura de pata y lo que aprendiste de eso? ¿Dónde te equivocaste y cómo podemos evitar todos lo mismo?

Giovanni:

Tengo una reciente. No fue un desastre grande, pero sí una metedura de pata de cierto modo. Me enviaron a solucionar algunas situaciones con equipos nuestros y del cliente. En Zuhlke trabajamos a menudo integrados en la organización del cliente.

Ben Aston:

Cierto.

Giovanni:

Y muchas cosas salieron bien, pero una situación política interna en la empresa terminó el proyecto por razones equivocadas. La lección es que a veces, incluso si crees estar al tanto, no ves venir algunas cosas.

Ben Aston:

Sí.

Giovanni:

Tuvimos un problema de juegos políticos y quedamos en medio.

Ben Aston:

Mm-hmm (asintiendo).

Giovanni:

Así que…

Ben Aston:

Sí, la política siempre es importante, por mucho que no quisiéramos.

Giovanni:

Bueno, sí, la política en sí no es buena ni mala, ¿sabes?

Ben Aston:

Sí.

Giovanni:

Cuando hay humanos juntos hay política. La cuestión es cómo la usas.

Ben Aston:

Mm-hmm (asintiendo) Definitivamente. Ahora, ¿qué consejo darías a alguien que quiere empezar a trabajar de forma ágil y cuyo cliente no lo ha hecho antes? ¿Cuál sería tu principal consejo?

Giovanni:

El consejo principal sería entender y aclarar expectativas. Cuando la gente dice que quiere un proyecto ágil, ¿qué quiere decir? ¿Qué necesidad hay? ¿Qué problema intentan solucionar?

Ben Aston:

Sí.

Giovanni:

Porque la agilidad no es el objetivo, es un medio. Lo que suelo encontrar es que deciden que quieren ser ágiles porque oyeron que otras empresas lo hacen y les va bien, pero eso es perder el foco.

Ben Aston:

Mm-hmm (asintiendo)

Giovanni:

Así que es gestión de expectativas y clarificación.

Ben Aston:

Sí. Me gusta mucho y es fundamental que el objetivo no es el proceso, sino entregar valor.

Giovanni:

Sí.

Ben Aston:

Y entregar valor de manera eficiente y en última instancia logar resultados, no solo centrarse en el cómo. De eso se trata. ¿Qué herramientas usas tú, ya sean tecnológicas o analógicas, al evaluar e implementar Ágil en equipos?

Giovanni:

Una herramienta muy analógica es mi Moleskine. Cuando hablo con la gente para evaluar un proyecto, generalmente no estoy con tecnología porque abrir un portátil crea una barrera entre tú y la persona.

Ben Aston:

Sí, sí.

Giovanni:

Usar un cuaderno es mucho menos intimidante. Mi herramienta principal es bolígrafo y Moleskine.

Ben Aston:

Sí.

Giovanni:

Luego paso mis notas al software. Uso uno que se llama Scapple. Permite escribir y conectar ideas sin restricciones de estructura de árbol, es más como un arbusto o bosque de notas, lo cual encuentro útil. Es importante no solo escuchar, sino también leer el ambiente y observar si el interlocutor está relajado, tenso o diciendo algo en lo que no cree.

Ben Aston:

Mm-hmm (asintiendo)

Giovanni:

Y otro consejo es hacerlo en un entorno seguro. Por ejemplo, si necesito hablar con desarrolladores sobre su visión del proyecto, dejo claro que no quiero managers en la sala. También lo hago con los managers aparte, porque aunque digan que son una empresa abierta, en la práctica siempre es más complicado.

Ben Aston:

Sí.

Giovanni:

La seguridad es fundamental.

Ben Aston:

Sí. Y volviendo a las herramientas de software para la gestión ágil: ¿recomiendas alguna en particular?

Giovanni:

Depende mucho. Si todos están siempre en la oficina, una pizarra va muy bien. Se le puede sacar una foto para dejar constancia. Si la gente trabaja desde casa o de manera remota, mejor herramientas electrónicas. Una muy común es Jira. No me encanta porque es lenta y tiene sus problemas, pero es mejor que la pizarra para equipos distribuidos.

Ben Aston:

Sí.

Giovanni:

Así que depende del contexto.

Ben Aston:

Entonces, además de tu Moleskine, y ¿dijiste que la herramienta de notas se llama Scapple?

Giovanni:

Scapple. S-c-a-p-p-l-e. Scapple.

Ben Aston:

Vale, Scapple. ¿Hay alguna otra herramienta que hayas descubierto recientemente?

Giovanni:

No realmente. De hecho, ni las busco. Estoy en una etapa profesional en la que prefiero mantenerlo simple.

Ben Aston:

Sí.

Giovanni:

Así que recomiendo la herramienta más sencilla que cumpla el trabajo.

Ben Aston:

Definitivamente. Hablemos de tu artículo, que es muy interesante sobre cómo escalar Ágil. Es bien sabido que añadir más personas a un proyecto de software no necesariamente aumenta la productividad, de hecho, puede bajarla. Así que debe haber otra forma de hacer más cosas. Giovanni ha escrito un gran artículo sobre reglas, leyes del escalado, requisitos y consideraciones de estructura. Si no lo has leído, ve a thedigitalprojectmanager.com y échale un ojo.

Volvamos al principio: ¿por qué es importante y quién debería preocuparse por escalar Ágil? Tú eres consultor en el tema, pero ¿por qué es tu trabajo? Cuéntanos por qué es importante.

Giovanni:

Diría que es importante saber de escalado porque tarde o temprano te enfrentarás a ello. Incluso en empresas medianas, pero sobre todo en grandes, los proyectos suelen crecer en número de personas. En general, mi recomendación es: no lo escales salvo que sea necesario. Primero resuelve tu situación actual y pregúntate por qué quieres escalar. Si no cumples los requisitos previos, olvídalo: solo tendrás un lío mayor. Te aseguro que en todos los grandes proyectos que he visto, incluyendo el de mil trescientas personas, solo necesitas veinte o treinta para hacer bien el trabajo. Así que asegúrate de ser eficiente antes de crecer.

Ben Aston:

Cuando hablamos de escalar Ágil, la clave es mantenerlo lo más pequeño y ágil posible para maximizar la eficiencia, claridad de propósito y entrega de valor. Pero, más allá de eso, ¿los procesos que estableces para escalar son únicos o cada equipo necesita adaptar su estructura?

Giovanni:

El "talla única" nunca funciona, menos aún en proyectos grandes. Cuando tienes cientos de personas y decenas de equipos, seguramente tendrás equipos con distintas necesidades y estilos. Dicho esto, hay un mínimo de uniformidad necesario, sobre todo para informes y transparencia en la información para la dirección. Sugiero dejar que cada equipo trabaje a su manera, pero tener una interfaz uniforme para el reporte de progreso.

Ben Aston:

¿Cómo es ese sistema de reporte? ¿Cómo uniformas el seguimiento?

Giovanni:

Hay varias formas. En vez de imponer Scrum a todos, algunos equipos tal vez necesitan flujos basados en eventos, por ejemplo si dan soporte a usuarios. Pero a nivel general puedes medir historias, funcionalidades, épicas… Se pueden hacer todo tipo de análisis, incluso desde el código, para ver cómo interactúan los equipos.

Ben Aston:

Hablando de buen y mal escalado: ¿qué ejemplos pondrías?

Giovanni:

Para mí, el mal escalado es cuando la dirección decide añadir gente para ir más rápido. Eso es muy típico. Planificar solo en función de la capacidad no sirve. Sugiero implicar a los equipos y líderes técnicos en la decisión de cuándo realmente necesitan crecer. Solo ellos saben si hace falta o no.

Ben Aston:

Así que consciencia.

Giovanni:

Sí, y añadiría que es fundamental tener claro el rol de cada uno. En proyectos de software los únicos indispensables son los que programan y algunos usuarios que usan el sistema. Todos los demás (incluidos project managers y consultores) son opcionales según el contexto y deben centrarse en facilitar la labor de los programadores. El project manager, en vez de decir qué hacer, debe preguntar: “¿Qué necesitas de mí para hacer mejor tu trabajo?”

Ben Aston:

¿Y el mejor caso de escalado Ágil que has visto? ¿Qué lo hizo tan bueno?

Giovanni:

Solo lo he visto funcionar de verdad en sistemas no muy grandes, con cinco o seis equipos, unos 50 desarrolladores y testers. Funcionaba porque todos sabían su papel y con quién hablar. A mayor escala los problemas aumentan y suelen sobrar personas.

Ben Aston:

¿Y sobre los marcos ágiles a escala como SAFe o Large Scale Scrum? ¿Funcionan?

Giovanni:

Sé de algún caso donde funcionó, en el contexto adecuado. Pero no me gustan los marcos "enlatados", porque fuerzan a los proyectos a encajar en su molde y suelen centrarse en la estructura y no en el día a día del equipo. Además, dan una falsa sensación de control a la dirección, pero no ayudan tanto a quienes hacen el trabajo.

Ben Aston:

Opino igual de Scrum: es solo un marco, pero hace falta adaptar el proceso y el contexto. No hay solución mágica, ni hay que seguir reglas rígidas solo porque “es Scrum”.

Seguir el marco no significa entregar más valor o trabajar mejor o más rápido.

Giovanni:

Totalmente de acuerdo. La primera vez que implementé programación extrema fue acordando con el equipo los objetivos y empezando poco a poco, con pocas prácticas, y luego sumando otras según obteníamos valor. Si usas marcos con muchas prácticas simultáneas como SAFe, es demasiado de golpe. Lo mejor es comenzar pequeño, aprender poco a poco, e ir creciendo y adaptando el proceso.

Ben Aston:

Si se impone un marco, la gente puede simplemente seguir el proceso “de cara a la galería” y luego trabajar como antes, con más burocracia y menos eficiencia.

Giovanni:

Exacto. Como consultor veo esto todo el tiempo. Se hacen daily meetings pero nadie escucha, las retrospectivas se vuelven sesiones de queja sin acción, todo por cumplir el marco y no por dar valor. Muchas empresas implantan el “modelo Spotify” pero ni siquiera Spotify lo usa tal cual, ellos adaptan su proceso continuamente.

Ben Aston:

Lo bueno del modelo Spotify es que parece tener sentido visualmente, pero al final debemos crear un proceso adaptado a nuestro equipo y contexto. Lo más importante es el contexto y no hay que usar una receta universal.

Giovanni:

Eso es fundamental. Hay un libro que recomiendo mucho, “Seis reglas sencillas”, cuya primera regla es: antes de hacer cualquier cambio, conoce lo que hace tu gente. No asumas. A partir de ahí se puede construir algo que tenga sentido para la organización.

Ben Aston:

Para los project managers que no programan ni son usuarios, ¿qué recomendación les darías?

Giovanni:

Lo más valioso que pueden hacer es entender qué necesita el equipo de ellos, preguntar cómo pueden ayudar. Y recomiendo también confiar en que la gente está haciendo lo mejor que puede en su contexto. No los juzgues ni des por hecho nada; pregúntales, tendrás muchas formas de ayudar. Y mucho trabajo de gestión (presupuestos, cronogramas, documentación) es fundamental pero a los desarrolladores generalmente no les gusta.

Ben Aston:

Nadie quiere ser responsable del presupuesto, el cronograma o el alcance. En Ágil se habla poco de eso pero son temas centrales y los clientes quieren saber cuánto cuesta y cuándo se entrega. [crosstalk 00:39:58]

Giovanni:

Así es, y por eso soy escéptico con la corriente “no estimates”: los clientes quieren y necesitan estimaciones.

Cuando des estimaciones, pide que las den quienes hacen el trabajo. No pidas números más bajos solo por querer una mejor respuesta. Si no te convence pide explicación genuina, pero si esa es la mejor estimación, defiende a tu equipo ante el cliente. Así ganarás su respeto.

Ben Aston:

Tal cual. No se trata de repartir el presupuesto top-down, sino de comunicar que todo es estimación y que trabajamos en tecnología, que es compleja. Hay que desglosar las tareas cuando una estimación parece muy grande y preguntar genuinamente para entender. La función del project manager en entornos ágiles es de comunicación: entre equipos, clientes y stakeholders, para dar máxima claridad y dirección.

Así que Giovanni, gracias por acompañarnos hoy. Ha sido un placer.

Giovanni:

Muchas gracias, fue un placer.

Ben Aston:

¿Y tú qué opinas? ¿Has intentado escalar Ágil? ¿Cómo te fue? ¿Qué funcionó y qué no? Cuéntanos en los comentarios. Si quieres aprender más o avanzar en tu trabajo, únete a nuestra comunidad con la membresía DPM. Ve a thedigitalprojectmanagement.com/membership para acceder a nuestro equipo de Slack, plantillas, talleres, horas de oficina, eBooks y más. Y si te gustó lo que escuchaste hoy suscríbete y deja una reseña honesta de DPM podcast en Apple Podcasts. Hasta la próxima, ¡gracias por escuchar!