Bases de una transformación ágil: desarrolla y ejecuta un marco de mejoras pequeñas y continuas
En nuestra primera publicación sobre «Planificar tu camino» de la serie «Bases de una transformación ágil» presentamos conceptos y explicaciones clave de la filosofía ágil: sus valores fundamentales, un panorama de sus principios, una breve historia y, sobre todo, cómo ser ágil encaja en una mentalidad de «mejora continua».
Agile, al igual que la mejora continua, es más un ámbito cultural de «perspectivas sobre cómo abordar los acontecimientos» que un conjunto de procesos definidos exhaustivamente.
Dicho esto, hay muchos elementos que una organización debe considerar y acordar antes de desarrollar una hoja de ruta de transformación ágil: una visión y misión organizacionales y objetivos estratégicos de alto nivel deben analizarse cuidadosamente para que todos los integrantes se alineen con ellos e impulsen la transformación hacia sus objetivos.
Por último, deben considerarse la cultura actual y los valores organizacionales para comprender cuáles son las prácticas actuales de creación de valor y cómo producen resultados favorables a los objetivos establecidos.
Ahora, ¿qué ocurre con definir la estrategia de gestión de alto nivel para tus operaciones?
Hay tantos casos exitosos de alternativas probadas en los negocios que puede ser difícil decidir qué procesos y prácticas ayudarían mejor a una organización a mantenerse encaminada y prosperar en su hoja de ruta de crecimiento. En Sophilabs ya argumentamos en la primera publicación de esta serie que la agilidad es un factor fundamental para el éxito al cumplir nuestra visión y objetivos, apoyar el cambio cultural y promover la mejora continua.
Repasemos brevemente las estrategias de gestión más comunes para fundamentar nuestra elección:
Elegir una estrategia de gestión: marcos ligeros frente a metodologías exhaustivas
Los proyectos son, en muchos sentidos, el estándar para delimitar y gestionar el trabajo y el valor que genera en un entorno empresarial en constante evolución. En algún momento, profesionales de prácticamente cualquier industria se han familiarizado en cierta medida con los proyectos, incluso si no se formaron plenamente como profesionales de gestión de proyectos.
Por eso, gestionar proyectos eficazmente ha sido una necesidad durante un par de décadas: las empresas que quieren innovar y revolucionar sus mercados deben cerrar la brecha entre negocio y operaciones, optimizar recursos y lograr mejores resultados cada vez. No sorprende que hayan surgido muchas metodologías, marcos y métodos para apoyar la búsqueda continua de una gestión ideal. La gestión eficaz de proyectos tiene dos aspectos fundamentales:
1. El «conjunto de herramientas de gestión»
El «conjunto de herramientas de gestión» permite decidir si usar una metodología muy detallada o un marco ligero como referencia para un proyecto.
En pocas palabras, las metodologías son conjuntos de principios, herramientas y prácticas específicos que pueden guiar los proyectos hacia sus objetivos. Sus beneficios son innegables, especialmente en proyectos o industrias con gran certeza sobre el producto y pocos cambios. Sus desventajas tienen que ver con que son muy extensas y prescriptivas: no implementarlas completamente como se indica puede aumentar mucho la incertidumbre y los riesgos del proyecto.
Los marcos son estructuras más ligeras y abiertas: referencias con procesos de alto nivel suficientemente descritos y espacio para incorporar herramientas y prácticas específicas al contexto táctico, de nivel inferior, según su valor o su encaje en el conjunto actual. Permiten gran flexibilidad al tomar herramientas y técnicas y mantener la alineación con principios amplios. Una desventaja importante es que, pese a ser ligeros, pueden ser difíciles de implementar y gestionar eficazmente.
2. El «enfoque de creación de valor»: predictivo frente a adaptativo
Cómo operamos los procesos de creación de valor está muy relacionado con la mentalidad que guía la implementación de las herramientas de gestión. Hablamos de enfoques operativos «predictivos» o «adaptativos», generalmente, pero no necesariamente, vinculados al propio conjunto de herramientas. Se diferencian en cómo gestionan el riesgo y la incertidumbre.
Un enfoque «predictivo» aborda el riesgo y la incertidumbre anticipando necesidades, decisiones probables y prácticamente todos los escenarios posibles mediante una «planificación inicial exhaustiva», antes de considerar las actividades de creación de valor y su gestión. Esto implica una dependencia detallada entre fases: el lanzamiento y la ejecución dependen de completar el 100% de la definición y planificación del producto, que a su vez dependen de una conceptualización exhaustiva inicial. Los clientes no empiezan a percibir valor hasta las etapas finales. Hay industrias que, por la naturaleza de su negocio, obtienen resultados fantásticos y mucho éxito con este enfoque.
Un enfoque «adaptativo», en cambio, reduce la planificación inicial al mínimo necesario y aumenta los ciclos de feedback del cliente para maximizar la capacidad de adaptación y ofrecer valor incremental desde las primeras etapas. Es ideal para industrias con productos muy innovadores y mucho trabajo abstracto y conceptual. El desarrollo de software reúne esas características y, como señalamos, es precursor de los enfoques adaptativos resumidos en «Agile».
En Sophilabs preferimos un enfoque adaptativo con marcos ligeros como Scrum para la mayoría de las nuevas funciones y productos innovadores, y métodos como Kanban para esfuerzos con mayores restricciones de tiempo, como el soporte continuo del producto.
Este conjunto central nos ofrece procesos completos pero ligeros que complementan nuestra agenda de agilidad y mejora continua, con flexibilidad para incorporar o retirar técnicas, herramientas y prácticas según lo necesario para adaptarnos, alcanzar nuestros objetivos y atender a los clientes.
Scrum y Kanban: adopción mediante un modelo evolutivo ágil
Ya argumentamos a favor de Agile, los marcos ligeros y, específicamente, Scrum y Kanban. Ahora enfrentamos algunas preguntas:
- ¿Cómo promovemos la adopción de estos marcos ágiles?
- ¿Cómo abordamos la resistencia y facilitamos el cambio cultural?
- ¿Cómo definimos la hoja de ruta de ese esfuerzo?
Después de analizarlo cuidadosamente, determinamos que era esencial definir un modelo evolutivo de agilidad para responder de forma sencilla.
Por qué un modelo evolutivo de agilidad
Los modelos son representaciones de un sistema compuesto por dimensiones, como conceptos y prácticas, ordenadas para facilitar la comprensión y gestión del tema que representan.
Hay mucho debate en el mundo ágil sobre la necesidad o relevancia de los «modelos ágiles», y muchos defensores afirman que contradicen el espíritu de Agile. El consenso general parece ser que los modelos pueden acabar definiendo demasiado y limitando su adaptabilidad. Sin embargo, otros sostienen que algunos marcos ágiles son extensibles y pueden, y a veces deben, complementarse con conceptos o prácticas que los adapten mejor a los escenarios organizacionales.
El modelo evolutivo de agilidad de Sophilabs
Necesitamos conectar nuestros marcos y prácticas operativos (Scrum, Kanban, Lean, XP y otros), nuestros impulsores organizacionales (visión, objetivos y cultura) y nuestra hoja de ruta de mejora continua (seguir la adopción con una escala tangible). Por eso resultó atractiva la idea de un modelo evolutivo de agilidad.
Promover la adopción de Agile
Promover prácticas que revolucionan las formas habituales de trabajar puede ser muy disruptivo si no se piensa bien. Creemos firmemente en una base sólida de buenas prácticas, refinadas empíricamente para lograr resultados exitosos. Scrum y Kanban la ofrecen: son ligeros, flexibles y bien concebidos, de modo que los equipos pueden adoptarlos gradualmente y seguir refinando sus procesos.
Facilitar el cambio cultural
La mentalidad centrada en el cliente, el empirismo, la autocrítica y la mejora continua mediante inspección y adaptación constantes son centrales en Scrum y Kanban. Una organización que siga esos principios mejorará drásticamente al adoptarlos y también se divertirá mucho.
Definir una hoja de ruta de mejora
Esta puede ser la parte más difícil, porque Scrum y Kanban no describen la mejora de procesos más allá de considerarla un resultado natural de la inspección y la adaptación.
Nuestro enfoque es directo: creemos que la suma de prácticas valiosas aplicadas determina el éxito. También buscamos un cambio cultural significativo, en el que los equipos incorporen esas prácticas de manera incremental al núcleo de sus procedimientos operativos habituales.
¿Cómo lo logramos? Lo conversamos con nuestros equipos y concluimos que lo mejor es:
- Que la hoja de ruta no tenga restricciones excesivas. Imponer objetivos fijos con plazos arbitrarios puede ser contraproducente y presionar innecesariamente a los equipos. No se trata de tachar elementos de una lista ni incorporar prácticas porque sí, sino de comprender y aceptar su valor y construir sobre sus resultados. Esto también implica adoptar plenamente comportamientos nuevos y mejores, y un cambio cultural.
- Que la hoja de ruta muestre claramente dónde estamos y dónde queremos estar. Debemos definir cómo medir y seguir el progreso con el modelo evolutivo. La mejor forma es establecer hitos que representen distintos «niveles de agilidad» y que los equipos sigan su «puntuación de agilidad», una representación de su nivel operativo actual. Ver el progreso en una escala sencilla y bien definida beneficia mucho a los equipos y orienta la adopción.
Para simplificar, el modelo se estructura en cuatro niveles descendentes: 1) Dimensiones, 2) Elementos, 3) Prácticas y 4) Resultados.
Expliquémoslos brevemente:
- Las dimensiones son las categorías superiores de los objetos del modelo: «Roles», «Procesos y artefactos» y «Resultados».
- Los elementos describen componentes básicos heredados de nuestros marcos y metodologías que encajan lógicamente en las dimensiones superiores; por ejemplo, «Equipo de desarrollo» y «Agile Coach» se agrupan en «Roles».
Este nivel también representa una restricción: según el marco o metodología del equipo evaluado, no todos los elementos medidos en Scrum se tendrán en cuenta en Kanban, y viceversa. - Las prácticas son objetos cuyo cumplimiento puede medirse y que se consideran valiosos para mejorar la agilidad del proceso. Suelen agruparse debajo de los elementos.
- Los resultados son particulares, porque hay dos tipos: resultados de nivel y resultados de dimensión:
- Los resultados de nivel representan el cumplimiento o incumplimiento de una práctica. Los equipos, es decir, proyectos específicos, los usan para evaluar si cumplen una práctica prescrita por el modelo. Sus valores son absolutos: «Sí» o «No», porque una práctica se cumple o no.
- Los resultados de dimensión representan el valor agregado de cumplimiento de 0 a 100, es decir, la «puntuación de agilidad», delimitada por un «alcance» organizacional o un «rango» de niveles, o ambos. Como los filtros de una hoja de cálculo permiten refinar información valiosa, estas restricciones permiten que el modelo escale:
- El alcance organizacional permite centrarse en la puntuación de un equipo, un subconjunto o toda la organización.
- Un rango de niveles permite determinar la puntuación de elementos o dimensiones específicos para el alcance seleccionado. Por ejemplo, calcular la puntuación del elemento «Representante del negocio» o de toda la dimensión «Procesos y artefactos», en lugar de la del proyecto completo.
La tabla siguiente muestra un ejemplo de uso del modelo completo en un proyecto, desglosado por niveles:
| Modelo evolutivo ágil | |||
| Dimensiones | Elementos | Prácticas | Resultados (Sí/No) |
| Roles | Equipo de desarrollo | El equipo se organiza por sí mismo para abordar el trabajo | Sí |
| El equipo es multifuncional | Sí | ||
| Todos acuerdan una «Definición de Hecho» | No | ||
| El equipo respeta la DoD | |||
| Todos los integrantes trabajan en el mismo lugar | Sí | ||
| Los equipos distribuidos tienen reglas claras de comunicación | |||
| Agile Coach | Hay un Agile Master | Sí | |
| Ayuda al equipo a cumplir prácticas y procesos ágiles | Sí | ||
| Ayuda al equipo a alcanzar sus objetivos eliminando impedimentos | Sí | ||
| El Agile Master protege al equipo (del exceso de trabajo o de la falta de esfuerzo) | Sí | ||
| Representante del negocio/cliente | Hay un PO claramente definido | Sí | |
| Tiene autoridad para priorizar | Sí | ||
| Tiene conocimientos para priorizar | Sí | ||
| Contacto directo con el equipo de desarrollo | No | ||
| Contacto directo con las partes interesadas | Sí | ||
| Habla con «una sola voz» | Sí | ||
| El PO da una dirección clara al producto y objetivos de corto plazo | No | ||
| El PO es responsable de un PBL | Sí | ||
| El PO delegó la gestión del PBL | |||
| Procesos y artefactos | Lista de funciones del producto (es decir, PBL) | Existe un PBL | |
| El PO o su delegado mantiene (gestiona) el PBL | Sí | ||
| El PO o su delegado prioriza los primeros elementos por valor de negocio | Sí | ||
| Los primeros elementos están suficientemente refinados para las iteraciones | Sí | ||
| El equipo estima los primeros elementos | Sí | ||
| El PO respalda todos los elementos del PBL | Sí | ||
| Intervalos de tiempo definidos | Duración de la iteración: máximo 2 semanas | Sí | |
| El equipo de desarrollo no sufre interrupciones ni control externo | No | ||
| El equipo entrega lo que se compromete a hacer | Sí | ||
| Siempre termina a tiempo | Sí | ||
| Gestión del flujo de trabajo | El flujo de trabajo se controla en un tablero Kanban | ||
| El flujo del tablero coincide con el proceso real del equipo | |||
| El equipo identifica tiempos de inactividad y conoce su lead time | |||
| Se identifican los cuellos de botella y hay límites WIP para abordarlos | |||
| Se actualiza diariamente (progreso del trabajo) | |||
| El equipo entrega en los plazos acordados | |||
| Planificación | Hay alguna forma de planificación | Sí | |
| La planificación ocurre al menos una vez por semana | No | ||
| Hay una planificación formal por iteración | Sí | ||
| El PO participa | Sí | ||
| El PO proporciona un PBL actualizado | Sí | ||
| Participa todo el equipo de desarrollo | Sí | ||
| El PO o su delegado está satisfecho con las prioridades y el alcance | Sí | ||
| Todo el equipo está satisfecho con el plan acordado | Sí | ||
| Produce un plan de sprint o hitos | Sí | ||
| Hitos (por ejemplo, backlog del sprint, planes de trabajo) | El plan de trabajo es muy visible | Sí | |
| El plan se actualiza diariamente (progreso del trabajo) | Sí | ||
| El plan es responsabilidad exclusiva del equipo de desarrollo | Sí | ||
| Reuniones diarias | Las reuniones diarias ocurren al menos una vez al día | Sí | |
| Se evalúa la frecuencia de las reuniones diarias | No | ||
| Se evalúa la calidad de las reuniones diarias | Sí | ||
| El equipo se organiza para resolver problemas e impedimentos | No | ||
| Se reconocen los problemas e impedimentos | Sí | ||
| Participa todo el equipo de desarrollo | Sí | ||
| Se evalúa la duración de cada reunión diaria (<=5min.) | Sí | ||
| Demostraciones/revisiones | Las revisiones y demostraciones ocurren con frecuencia | Sí | |
| Participan el PO o las partes interesadas, o ambos | Sí | ||
| Se muestra software funcional y probado | Sí | ||
| Se reciben comentarios del PO y las partes interesadas | Sí | ||
| Retrospectivas | Las retrospectivas ocurren con frecuencia | Sí | |
| Las retrospectivas ocurren al menos una vez por iteración | Sí | ||
| Produce planes de acción S.M.A.R.T | Sí | ||
| Se sigue el cumplimiento del plan de acción | Sí | ||
| Resultados | Puntuación de agilidad | Puntuación de agilidad para el marco ágil definido | 89 |
Nivel de agilidad en el modelo evolutivo
Para ayudar a los equipos a comprender y seguir su transformación, también definimos 5 hitos incrementales de madurez, que preferimos llamar «niveles de agilidad»:
| Niveles del modelo evolutivo de agilidad | ||
| Nivel | Descripción | Rango de puntuación de agilidad |
| 5 | Adaptable: responde al cambio mediante múltiples niveles de feedback | 80-100 |
| 4 | Eficaz: produce software funcional | 60-80 |
| 3 | Evolutivo: entrega temprana y continua | 40-60 |
| 2 | Colaborativo: comunicación | 20-40 |
| 1 | Autoanalítico: identifica áreas de mejora | 0-20 |
Según la puntuación evaluada para un alcance y rango determinados, definimos el nivel actual para entender mejor cómo orientar los esfuerzos de mejora continua.
Una puntuación de 89, como en el ejemplo anterior, representa un nivel de «5». Deben analizarse cuidadosamente las prácticas faltantes o deficientes al pensar en el progreso futuro.
Por último, pon a trabajar tu modelo evolutivo de agilidad
Para alcanzar todo su potencial, los equipos y las personas deben promover una cultura autocrítica que busque mejorar continuamente.
Desde equipos hasta organizaciones completas pueden usar el modelo para establecer su nivel actual, identificar áreas de mejora, desarrollar planes de acción inteligentes y, de forma iterativa, seguir y controlar la evolución de su nivel de agilidad.
En Sophilabs lo implementamos con éxito desde hace unos 6 meses y los resultados hablan por sí mismos:
- Alcanzamos el nivel 4 de agilidad en unos meses, después de empezar en un nivel 3 inicial.
- Los proyectos operan eficazmente y siguen buscando y aprovechando oportunidades de mejora.
- Las personas y los equipos son más conscientes de los procesos y de su cumplimiento, porque han desarrollado progresivamente una comprensión de su valor.
- El compromiso con nuestra visión, objetivos y principios creció notablemente; todos están más conscientes y comprometidos con brindar calidad en esas áreas.
En próximas publicaciones examinaremos nuestros resultados, los planes de acción que surgieron y nuestro camino para ponerlos en práctica.
Referencias
- Road-mapping Your Way to Agile Fluency, Kelsey Van Haaster, 2016
- The CMMI Agile Adoption Model, Mukta Telang, 2015
- Measuring Agile Maturity in the Enterprise, Amjad Gani & Jim Starrett, 2017
- The Agile Fluency Model, Agile Fluency Project, 2014
- Agile Maturity Model – 3 Different Approaches, Udayan Banerjee, 2011