El objetivo de este post es reflejar algunos puntos de partida erróneos que se repiten una y otra vez cuando una organización quiere empezar a plantear la transformación hacia modelos ágiles. No busca resolverlos, sino ayudar a identificarlos y cambiar nuestra mentalidad, como organización y como agentes del cambio.

Cuando, como organización nos decidimos a dar el paso para transformarnos y cambiar la forma en la que trabajamos hacia un modelo ágil, es muy importante tener en cuenta algunas premisas que se repiten constantemente. Este artículo no está orientado sólo a las organizaciones que empiezan su viaje hacia un modelo ágil, sino también a los scrum masters, coaches, mentores y todas aquellas figuras que ayudan a esa transformación.

Imágen que hace referencia a la corriente #noestimates que se centra en la construcción de software y entrega de valor sobre la estimación y la predicción, cuyos principales promotores son Woody Zulia y Vasco Duarte.

Algo que se suele olvidar, y voy a relacionarlo con los Coaches más disruptores o a los Scrum Master super motivados deseosos de aplicar las últimas tendencias (con todo el cariño del mundo, es necesario ser disruptor y contar con una gran motivación aunque una sobre-motivación puede jugarnos malas pasadas), es el “estado de madurez” de una compañía y hasta donde puede necesitar llegar a nivel ágil.

Cuando llevamos años trabajando con metodologías ágiles, tendemos a obviar algunos de los que fueron nuestros primeros pasos (como por ejemplo entender cómo concebía originalmente una Historia de Usuario Mike Cohn o adquirir la constancia necesaria para pasar de un Refinamiento ceremonial a un Refinamiento continuo tal cual se indica en la Guía de Scrum), igual que en matemáticas no empezamos por las integrales y empezamos por operaciones más sencillas que posteriormente nos ayudan a entender otras más complejas, hay prácticas ágiles que no podemos plantear a un equipo novato.

Podremos tutorizar y guiar a estos equipos, y en algunos casos, efectivamente conseguiremos que no caigan en determinados errores conocidos, pero siempre tenemos que dejarles espacio para que adquieran su propia experiencia y sus propios errores, de hecho el objetivo es iterar y aprender de ellos en nuestro propio contexto.

A continuación recopilo algunos de los tópicos que nos solemos encontrar en nuestras tomas de contacto:

Hay clientes, que cuando deciden pedirnos ayuda lo hacen porque han visto como competidores, partners u otras grandes empresas están cosechando beneficios al implantar modelos ágiles, me gustaría destacar que no digo “éxito”, que digo “beneficios”. Hay un mensaje que cuesta entender, si ya estamos viendo resultados en otros, quiere decir que empezaron su camino antes y no podemos pretender recorrer el mismo camino en menos tiempo, cada organización tiene su propio contexto y necesidades y como tal, requerirá diferentes aproximaciones al cambio, pero en cualquier caso, las personas necesitan un tiempo determinado para adquirir conocimientos, habilidades y adaptarse a los cambios que se propongan en su contexto.

Muchas veces escuchamos “Quiero poner en marcha el modelo de Spotify” o “Queremos implantar Design Sprint de Google en nuestra organización”. Esto se traduce en que en muchas ocasiones leemos sobre casos de compañías concretas (lo más habitual es hablar por referencias de un modelo, más que por haberlo analizado realmente y comprendido sus beneficios potenciales), y como vemos que hay algo que a ellos les funciona, queremos ponerlo en marcha.

Tenemos que plantear el escenario al que nos gustaría llegar (que no es el mismo para todas las compañías). Hay que tener en cuenta que pasar de donde estamos ahora (A), a donde queremos estar (B) hay muchos puntos intermedios que recorrer dependiendo de cada compañía y el momento del tiempo en el que nos encontremos. El resumen es, tenemos que experimentar, iterar y encontrar nuestro modelo óptimo, no adoptar sin más, sin descubrimiento ni contextualización.

Evolución desde donde estamos al punto que queremos llegar. Hay muchos grados de adopción de metodologías y hay que tener en cuenta la realidad de nuestro contexto.

Ojo, esto no implica el voy a hacer lo que quiero a mi manera y sin conocimiento, eso es pervertir la metodología y con gran probabilidad acabe en fracaso.

Otras frases muy típicas en nuestras tomas de contacto son “Quiero que mi departamento X trabaje de forma ágil” o “Quiero ejecutar este proyecto con equipos ágiles” o “Quiero que sólo este equipo trabaje de forma ágil”, lo primero que tenemos que pensar es qué estamos dispuestos a cambiar como organización. Si quiero seguir igual pero que mis equipos trabajen de una forma diferente, tal vez no esté planteando correctamente la transformación.

Muchas veces estos beneficios hablan solo de una parte de la organización o de un proyecto concreto (no quiero llamarlo expresamente postureo, porque hay muchos casos en los que no lo es y sí que hay una mejora respecto a cómo se trabajaba previamente), si es este el escenario y tenemos una cadena de dependencias, ¿conseguiremos que estos equipos trabajen como necesitamos? ¿O solo conseguiremos frustrar a los equipos porque tendrán una fuerte dependencia de un modelo que no está pensado para la forma en que estamos pidiéndoles que trabajen?

El que una organización se transforme conlleva un periodo de años, de hecho, un equipo empieza a tener un cierto grado de madurez cuando lleva un tiempo determinado trabajando en un modelo ágil, por supuesto, este tiempo no es el mismo para todos los equipos.

Vamos con un clásico: “Queremos poder tener antes en producción las cosas”.

Para empezar, buscamos entregar antes software con calidad, la calidad no es discutible.

Si antes entregábamos software cada semana (por poner un ejemplo), pero la calidad del mismo es baja e impacta en la percepción que tienen los usuarios (fallos en producción que obligan a llamar a los call center) o tenemos que sumar esfuerzos para estabilizar la plataforma, podemos ser muy rápidos pero no ágiles. Voy a ser un poco irreverente por que creo que aplica, estaremos entregando rápida y frecuentemente mierda en producción o estaremos forzando a entregar rápida y frecuentemente mierda en producción.

Pasemos al “Quiero mejorar el rendimiento de mis equipos”.

Hablemos de velocidad. Cuando decimos que las metodologías ágiles nos ayudan a entregar software antes y empezar a entregar valor al cliente o al usuario, no hablamos de velocidad, la velocidad es una consecuencia de cómo trabajamos. Es muy habitual intentar ver cómo medimos lo mismo que medíamos antes en un nuevo contexto, pero… ¿no deberíamos medir diferente si trabajamos de forma diferente?

La velocidad no es un denominador común en los equipos y solo nos sirve como “vara de medir” para un equipo concreto ya que cada uno empleará un stack tecnológico diferente, tendrá un contexto de producto diferente y realizará las estimaciones de una forma diferente. Comparar entre diferentes equipos, sería comparar “peras con manzanas”.

Deberíamos centrarnos en el aporte de valor, esto es como varían los KPIs que nos marcamos según vamos realizando entregas de nuestras solución, este feedback es indispensable para la toma de decisiones posterior.

“Quiero mejorar la productividad de los equipos con metodologías ágiles”.

Bien, ahora viene la respuesta con una pregunta. ¿Te has molestado en ver si tus equipos tienen los conocimientos y habilidades necesarios para llevar adelante el trabajo con éxito? Si tu respuesta va en la linea de “Eso es cosa del proveedor”, vamos mal, simplemente porque puedes creer en esa fantasía, pero la realidad es que sí que te afecta, afectará al proyecto y a la percepción que tengan tus clientes, por muchas cláusulas que tengas en el contrato con el proveedor.

A modo de conclusión, nuestra propuesta siempre es la misma, analiza tu contexto, empieza con un equipo, pon en marcha las acciones que hayas considerado durante tu descubrimiento, itera y ajusta, y cuando veamos que está funcionando, vamos a empezar a extenderlo PROGRESIVAMENTE al resto de equipos y posteriormente podremos empezar a plantearnos un modelo de escalado.

Si no tienes experiencia previa, pide ayuda a alguien que pueda guiarte, pero desconfía de las recetas tipo “Ser ágil en 5 pasos” o “Da igual tu contexto, haz esto y triunfarás”.

Hay algo inherente a la transformación que es la potenciación de los equipos y las personas. Y eso implica también el correcto uso de las prácticas y las técnicas tecnológicas además de las metodológicas. De nada servirá hacer muy  bien una definición de nuestro producto si no vamos a dar espacio al equipo para mejorar los conocimientos sobre una tecnología concreta necesaria para construirlo.

Recordemos que nuestro objetivo es trabajar mejor de lo que lo hacemos actualmente (concepto Kaizen), ir introduciendo mejoras y no hacer un Big Bang en toda la compañía. Esto último suele acabar mal.

En Autentia proporcionamos soporte a la implantación corporativa de metodologías ágiles ayudando a la transformación digital de grandes organizaciones. Te invito a que te informes sobre los servicios profesionales de Autentia y el soporte que podemos proporcionar a tu empresa.