Cómo encontrar al "Agile Coach" adecuado
En los años 2004 y 2005, cada vez más equipos adoptaban métodos ágiles y, naturalmente, lo primero que necesitaban era asesoramiento y formación. Sin embargo, en muchos casos tuve que acudir a las empresas después de las formaciones para arreglar el desorden que los formadores habían dejado. Erróneamente, en aquel entonces asumi que esto solo sería un problema mientras los nuevos equipos ágiles – especialmente en empresas que desarrollaban software estándar – aún necesitaran adquirir experiencia. Lamentablemente, el problema de los malos formadores y coaches aún no ha desaparecido. Aunque muchas empresas ya han optado por buenos formadores, en mi opinión siguen siendo la excepción.
Como sucede con muchas otras cosas, la responsabilidad de encontrar al mejor formador recae naturalmente en el cliente. Sin embargo, cuando un equipo necesita formación, es muy probable que quienes deban tomar esa decisión aún no tengan experiencia en el tema. La intención de este artículo es, por tanto, ayudar a las empresas de producto a encontrar a los formadores y coaches adecuados para métodos ágiles.
Factores diversos para la búsqueda del Agile Coach adecuado
-
En la mayoría de los casos, el software aún se desarrolla para fines internos (IT) o específicamente para un cliente determinado. Por ello, muchos formadores ágiles simplemente no se desenvuelven bien con empresas que desarrollan soluciones para el mercado masivo. Naturalmente, tampoco quieres ser la empresa en la que un formador así practique. Por eso es importante saber de antemano si el formador potencial entiende la diferencia entre IT (interno), desarrollo de software personalizado y desarrollo de software estándar.
-
En las empresas que desarrollan software estándar existen roles muy diferentes a los de otros tipos de software. Un formador potencial debe comprender el rol del Product Manager, del marketing de producto, del equipo de User Experience, de los diseñadores de interacción, diseñadores visuales e investigadores de usuarios.
-
El formador debe saber cómo funciona la colaboración entre Product Managers y diseñadores UX con el equipo de desarrollo ágil. El formador debería tener experiencia personal con Dual-Track Agile (desarrollo en dos vías) – es decir, con Product Discovery y Product Delivery.
-
En una empresa de software, en ciertos casos hay que ser capaz de hacer compromisos concretos y proporcionar estimaciones fiables sobre los plazos de entrega. Esto debe hacerse con integridad y siendo consciente de que las roadmaps convencionales suelen estar llenas de elementos que realmente no aportan valor al cliente. El formador debe entender cómo se hacen estos compromisos y cómo se gestionan en un equipo de producto.
-
En los equipos de desarrollo de software estándar, la visión del producto es extremadamente importante para crear contexto y motivar al equipo. Un formador de métodos ágiles debe comprender el papel clave de la visión del producto y la estrategia, y también saber cómo encaja con el Product Discovery y Delivery.
-
En el software interno, muchos formadores de métodos ágiles creen que son bastante rápidos si prueban algunas ideas en cada Sprint de dos semanas. En el software estándar, sin embargo, esto se consideraría extremadamente lento. Asegúrate de que tu formador haya entendido que la rapidez es crucial para la innovación y cómo el Dual-Track Agile nos ayuda a validar la mayoría de las ideas sin necesidad de escribir código.
-
En las organizaciones de software estándar existe un ciclo continuo en el que se construye algo (prototipos y producción), se miden los resultados, se aprende de ellos y se repite el proceso. Es muy importante que el formador entienda la importancia de este ciclo, así como de los prototipos, análisis y pruebas A/B para la toma de decisiones, las pruebas y el aprendizaje continuo.
-
Culturalmente, hay una gran diferencia entre los desarrolladores de una organización de IT y los de una organización de software estándar. El formador ágil debe saber que el nivel de experiencia y habilidades de los desarrolladores varía enormemente y que el enfoque debe adaptarse en consecuencia. Muchos de los desarrolladores tienen mucha más experiencia en el desarrollo de productos reales que la mayoría de los formadores. Por ello, los formadores con la actitud equivocada pueden fracasar rápidamente en ganarse el respeto del equipo.
-
Otra gran diferencia radica en que un equipo en una organización de IT debe satisfacer las necesidades de la empresa. El equipo de producto en una organización de software estándar está ahí para desarrollar soluciones para los clientes de una manera que sea viable y rentable para la empresa. Esta no es una diferencia menor. El formador debe comprender que esta no es una organización de servicios orientada a satisfacer las necesidades de la empresa.
-
Finalmente, es crucial que el formador no solo entienda las empresas de software estándar, sino también los requisitos y métodos de los servicios SaaS (Software as a Service) críticos para el negocio. Temas como escalabilidad, fiabilidad, tolerancia a fallos, rendimiento, monitorización y control, automatización de pruebas y deuda técnica ya no son opcionales sino una necesidad absoluta. Además, en el desarrollo de software estándar no hay lugar para un cumplimiento dogmático y ciego de los procesos. Algunas personas confunden en los métodos ágiles los medios para alcanzar un objetivo con el objetivo en sí. El único objetivo que realmente importa es un producto exitoso.
Conclusión
Cuando elijas a un formador o coach de métodos ágiles, recuerda que la empresa para la que trabaja a menudo no es tan determinante como la persona en sí. Verifica al candidato potencial y averigua si cuenta con la experiencia en empresas de software estándar que necesitas.
En general, se puede decir que un formador viene a tu empresa, te explica la teoría y luego se va. Un coach, en cambio, aplica los métodos realmente con tu equipo en tu entorno único.
Este texto proviene del Blog de Marty Cagan y fue traducido por nosotros al alemán.
