¿Cuáles son los factores que obtienen los mejores resultados de un enfoque ágil? Me parece que hay varias vertientes respondiendo a esta pregunta.

En casi todo el mundo, Scrum se levanta como el referente de un agilismo práctico. No me extraña para nada y de hecho lo encuentro super sensato: si el objetivo es incorporar una forma diferente de hacer las cosas a nivel de los equipos de desarrollo y las organizaciones, y los mismos provienen de ambientes altamente orientados a procesos y roles, me parece una decisión inteligente el optar por Scrum como el acercamiento inicial a la agilidad.

Lo contrario sería lanzar una primera version de agilidad en un equipo u organización usando esquemas mucho más radicales y tal vez demasiado libres, como los que por ejemplo propone Extreme Programming (XP) que sugiere prácticas como el PairProgramming. Dichas prácticas, aunque muchos tecnólogos estén de acuerdo sobre su conveniencia desde múltiples aspectos, resultan bastante “radicales” (por decirlo así) especialmente desde el punto de vista del negocio. Y recordemos que el negocio es el que firma los cheques y el que decide.

Esto no impide que luego de “masterizado” Scrum, las organizaciones o equipos comiencen a adoptar nuevas prácticas provenientes de otras vertientes de la agilidad o que inclusive se planteen sus propios paradigmas, ya sean completamente nuevos o adaptados de los diferentes “sabores” de agilidad.

Pensado de esa forma, parece ser buena idea adoptar la agilidad de forma incremental, tomando en cuenta para esto las realidades y la situación actual de las cuales provienen las personas, los equipos y las organizaciones que estamos queriendo transformar, y esto incluye su Cultura. Exponerlos a esquemas demasiado libres, demasiado no-estructurados sería tal vez solicitarles un paso demasiado dramático de una sola. Mejor paso a paso: la naturaleza incremental de la agilidad.

Puede ser que una vez asimilado Scrum, se le puedan proponer a las personas, equipos y organizaciones, retos en cuanto a nuevos y mejores niveles de madurez de su agilidad. Es más, es lo que debería pasar. Lastimosamente muchas organizaciones se contentan con la primera version de su agilidad y dicen “ya hacemos agilidad”, “ya somos ágiles”, o sencillamente traducen una mala experiencia con agilidad en que la agilidad no sirve. La agilidad por definición sigue el Kaizen, y esto significa que se va mejorando siempre, poco a poco. Y los que logren niveles importantes de madurez en agilidad será probablemente porque se planteen que “nunca” lo van a lograr, que su camino nunca termina.

Ahora, con relación a ese enfoque en la mejora continua, una pregunta válida es: ¿Qué cosas proponer para obtener los resultados más dramáticos en la menor cantidad de tiempo posible? (una propuesta muy Lean…)

A mi criterio el agilista no es una persona, un rol, un tipo de consultor en particular, o un desarrollador. La agilidad es una capacidad, una destreza que tiene que ver más con un mindset que se desarrolla y se aprende a cultivar. Desde esa perspectiva todos los miembros del equipo son ágiles, y por eso el equipo es ágil, y no al revés. Eso significa también que un desarrollador es ágil, un tester es ágil, un arquitecto es ágil.

¿Por qué esto es relevante? Porque por más que nos apasione la agilidad, no debemos olvidar de dónde provenimos, que es lo que somos y que es lo que hacemos. La mayoría de quienes leen estas líneas fuimos educados como tecnólogos, ingenieros, desarrolladores, analistas… de sistemas de información, de software. Y no debemos olvidarlo. Se espera de nosotros un enfoque tecnológico, no solo metodológico. La agilidad no es una carrera profesional, es una condición humana.

Hago esta mención y regreso a la pregunta inicial: ¿Cuáles son los factores que obtienen los mejores resultados de un enfoque ágil?. Mi opinión, formada luego de ver trabajar a muchísimos equipos ágiles en todo tipo de ambiente, industria, reto y cultura, están más orientados a balancear la ecuación de metodología – técnica. Lo digo porque he visto que las realidades son casi contrarias dependiendo desde el punto de vista que se aborden e inclusive desde la geografía en la que se miren.

Lo que he visto en el Sur Global, especialmente en Latinoamérica, es que existe un enfoque de la agilidad más desde el lado metodológico que desde el lado técnico y en el Norte Global es al revés, especialmente en Norteamérica. El análisis de ese fenómeno se los dejo a los sociólogos, aunque me atrevo a adelantar mi criterio a que la explicación se relaciona al hecho de que en latinoamérica somos culturas enfocadas en lo social, en la familia, las tradiciones, etc.

Por el contrario, y para citar un ejemplo, yo vengo escuchando a clientes Californianos acerca de Integración Continua y herramientas para Entrega Continua automatizada desde hace más de 15 años, como una práctica normal y ya desarrollada, casi “por defecto”.  Y he trabajado en empresas de ese mismo origen que hacen de la técnica el brazo principal de su agilidad. Inclusive he trabajado con empresas latinoamericanas que dan servicios en Norteamérica y para ellas es normal hablar (y filtrar a su gente) sobre temas tales como TDD, Patrones de Diseño, etc. Los veo tener éxito porque, luego de haber abrazado el mindset agile (más que haber asimilado una metodología como Scrum) han regresado a hacer lo que se espera de ellos: tecnólogos que proponen soluciones basadas en tecnología, cada vez más exóticas y evolucionadas. Tan es así, que una de esas empresas en las que también trabajé, líder a nivel mundial en delivery de productos mediante agilidad, desarrolla un estudio semestral acerca de las tecnologías que van apareciendo, creciendo y muriendo, y da su opinión fundamentada acerca de cada una, para de esta forma intentar guiar a la colectividad usando su criterio experto.Y además son ágiles. En el estudio no hablan de agilidad. Porque es algo asimilado.

A medida de que muchos roles antes desconocidos para la tecnología como Coaches Ontológicos y Facilitadores Gráficos Profesionales y otros se van sumando a las huestes tecnológicas, no debemos olvidar que agilidad también es sobre tecnología. Lo mismo pasa con los estrategas de productos, que ahora hablan DesignThinking, Lean, etc., pero lo hacen desde una perspectiva agile. En mi mente se dibuja un agilista completo, el cual sabe perfectamente de tecnología, puede preveer el futuro desde el punto de vista tecnológico, puede proponer soluciones tecnológicas… desde su agilidad. Y lo logra con agilidad. Y lo piensa desde la agilidad de su mindset.

Ese divorcio entre Metodología y Tecnología no debe continuar. ScrumMasters, Coaches que no son diestros en tecnología, tienen un gap. Y la agilidad no es solo facilitación. Es mi opinión humilde. No es una o la otra, son las dos al mismo tiempo, y el que carece de uno de los lados, cualesquiera que sea, podría tener un gap.

¿O no es exactamente lo que le estamos pidiendo al negocio? ¿O no les estamos pidiendo a los niveles C (C-levels) que sean diestros al hablar de plataformas, de arquitecturas, de tendencias tecnológicas para poder sobrevivir la revolución digital?

Es como para pensarlo.