Cómo medir la implantación de Agile

(sin morir en el intento…)

Amigos y compañeros involucrados en una iniciativa parecida me han preguntado en más de una ocasión cómo medir el grado de madurez o de implantación de Agile en una compañía.

Agile tiene como principios o valores la adaptación constante al cambio, la asunción que nada es rígido ni imperturbable y junto a otras filosofías cercanas como LEAN, la apuesta por la mejora continua constante e infinita.

¿Quiere decir esto que no hay fin posible en la implantación de Agile? ¿Se trata de una quimera infinita? ¡No! bueno, sí, no sé… depende 😉

Podemos medir el avance de la aplicación de determinadas prácticas ágiles y el alcance de determinados hitos si son de tamaño reducido y tangibles, pero ¿cuando se puede realmente decir que ya hemos implantado Agile? Difícil respuesta, casi imposible.

La cuestión es: si no tienes un final definido, ¿Cómo mides el avance o grado de implantación?

(Recordad que un porcentaje es una parte de un total y… ¿Conocemos realmente ese total?)

Muy probablemente durante el proceso de implantación cambiaremos los siguientes hitos al ir contrastando la realidad, descubriendo alternativas de mejora, incluso podrían cambiar las prioridades una vez que agentes externos a los propios equipos involucrados en la implantación influyan al observar o participar del nuevo modelo de trabajo.

Os recomiendo un modelo muy simple: definir hitos parciales. No midáis la implantación de forma holística sino definid pequeños hitos asociados y no planifiquéis más allá de los que abarquen los primeros meses.

¿Cuáles serían estos hitos?

Cada compañía, equipo o iniciativa pueden requerir hitos diferentes. Incluso equipos parecidos pueden tener diferente experiencia o prácticas ya implantadas que impliquen un roadmap diferenciado.

En Tiendeo tenemos 8 equipos en IT actualmente y cada uno tiene definido un roadmap diferente. Incluso el modelo de trabajo objetivo no es el mismo entre ellos.

Existen hitos técnicos, organizacionales, comunicativos y operativos entre otros. Algunos ejemplos:

• Mantener un roadmap visible y actualizado
  (ver post: Implantando AGILE en TIENDEO: VISIBILIDAD PARA TODOS)
• Definir un sistema de priorización de las historias (coste/beneficio) aplicable a los backlogs actuales
• Incluir en los cálculos de prioridades el concepto de cost-delay
• Implantación de un nuevo flujo en nuestro GIT
• Conseguir que la mayoría de tarjetas que entran en el board tengan una estimación parecida y reducida.
• Participación de los perfiles del equipo QA en la definición de las historias.
• Canalización de la demanda y evitar asaltos directos a los equipos
• Mantener un sistema de escalado Agile entre todos los equipos.
• Alimentar una knowledge base al finalizar la resolución de una incidencia
• Alcanzar un 20% de presencia de tareas de I+D en los boards
• Empezar a usar búferes en los tableros Kanban para detectar cuellos de botella en el equipo
• Empezar a usar TDD en un primer equipo (una práctica habitual de XP)

Definimos alcances realistas, objetivos creíbles y a medida que se vayan alcanzando aparecerán los nuevos.

Ejemplos de hitos incorrectos:

Hito incorrecto #1: ”Implantación de BDD” como metodología de QA y vehículo de transcripción de requerimientos para facilitar su comprensión y posterior validación.

¿Podemos medir el grado de implantación de BDD? Incluye muchas prácticas, es otra filosofía Agile orientada al control de calidad con eje principal en el comportamiento. ¿Qué es exactamente implantar BDD?

Mejor planteémonos tareas más tangibles a corto plazo como: “realizar formaciones de BDD a grupos de usuarios de negocio”, “Integrar Specflow con nuestro framework de desarrollo”, “Redactar escenarios en el 50% de los tickets del equipo de FrontEnd”

Hito incorrecto. #2: “Implantación de Scrum”: ¿Consideraríamos que está implantado en un 100% en un equipo si se cumplen todas las ceremonias del ciclo? (ver post: Yo trabajo en Agile porque hago “dailys”)

Debemos trabajar estos hitos parciales que comentábamos: realizar las ceremonias Scrum, aumentar en el sprint número de tareas que provengan de las retros, modelos de escalado, etc.

Hay modelos como Scaled Agile Framework (SAFe®) que sí contemplan un modelo exhaustivo de implantación para toda una organización, pero me sumo a la corriente respaldada por los creadores de Scrum que SAFe ya no emana Agile. Demasiada rigidez, complejidad y norma. Choca con varios principios del Manifesto siendo un modelo demasiado inflexible y tradicional al que han aplicado cierto search&replace para que incluya palabras propias de Agile.

¿Y si necesitas medir?

¡Mide, que es bueno! Pero intenta darle la vuelta: habla de hitos parciales, logros, pero sobre todo mide el valor que aportan, ese será tu verdadero indicador.

Ejemplos:

• Conseguir un 10% de reducción del hands-off o tiempos muertos (cuantifícalo, es fácil)
• Reducir un 25% el TimeToMarket por una evolución en el sistema de integración continua
• Cuantifica los beneficios de las iniciativas que consigas finalizar total o parcialmente
• Adelanto de 5 semanas del ROI al poder sacar un producto intermedio (MVP) al mercado.
• Conseguir una cobertura del 50% con los tests funcionales en las nuevas features
• Aumento de la satisfacción del usuario final: mídela con encuestas.
• Montaje paneles informativos: Los equipos del área de marketing ya pueden ver el estado de las releases y su contenido y reducimos en un 40% las preguntas e interrupciones al equipo.
• Reducción de un 5% de media del Cycle Time (sácalo de tu Jira o equivalente)
• Reducción de horas extras del equipo (gran métrica, creedme…)

Sobretodo no dejes de ponerte nuevos objetivos realizables a corto/medio plazo constantemente, mantén un roadmap que puedas ir revisando y alterando y entra en detalle solamente de aquello que sea cercano en el tiempo, el resto déjalo como titulares.

Mide sólo lo medible, sino te estarás haciendo trampas al solitario.