Contenidos del artículo
Una historia de la trinchera
Hace unos años estuvimos asesorando a una organización con una gran inversión anual en contratar desarrollo de software. Contaba con 9 jefes de proyecto internos que controlaban varios proyectos en paralelo con decenas de desarrolladores. Tenían problemas de retrasos en las entregas, usuarios insatisfechos, unos sistemas anticuados tanto en tecnología como en usabilidad y mucha deuda técnica. Vaya, algo que nunca ha pasado en otro lado.
Nos llamaron para “agilizar” el desarrollo. Durante más de un año conseguimos unas cuantas victorias en una organización que “se dejaba hacer”:
- Introdujimos la agilidad en los proyectos de mantenimiento.
- Revitalizamos la integración continua y la calidad del software.
- Conseguimos implicar al “negocio” y a Dirección IT con los proyectos con un tablero Kanban de iniciativas.
- Integramos la iniciativa Agile con otra sobre DevOps que se desarrollaba en paralelo y que desconocía el departamento de desarrollo (arg!)
Cursos relacionados
| Fecha | Ciudad | Curso |
|---|---|---|
| 04/03 | Curso virtual | Professional Scrum Master – Advanced (PSM-A) |
| 04/02 | Virtual | OKR Champion (OKRC) |
| 13/01 | Curso virtual | Professional Scrum Master (PSM) |
| 14/01 | Curso virtual | Professional Scrum Product Owner (PSPO) |
| 03/02 | Curso virtual | Professional Scrum Product Owner – Advanced (PSPO-A) |
| 10/03 | Curso virtual | Professional Agile Leadership (PAL-E) |
| 01/04 | Remoto | APS – Software Developer (APS-SD) |
| 04/02 | Curso virtual | Professional Scrum with Kanban (PSK) |
Todo parecía que iba sobre ruedas. Tanto los usuarios como la organización IT estaban más contentos sobre la nueva manera de trabajar. Pero, ¿habían ganado en agilidad de negocio? No mucho:
- Los desarrollos iban más rápido pero la mayoría de iniciativas seguía partiendo de un presupuesto anual de IT.
- Los usuarios seguían siendo “peticionarios” que colaboraban en la “toma de requisitos” y en las “pruebas”.
- No se usaban métricas de valor para el usuario, ni de uso de las aplicaciones, y el alcance de los proyectos no pivotaba en función del usuario.
En definitiva, se consiguió adoptar Agile pero no tener agilidad de negocio. Hubo una mejora notable, pero no se transformó la organización. Hace poco volví a saber de ellos y el grado de agilidad estaba estancado en un nivel parecido al que se obtuvo tras nuestra consultoría.
El problema de la iniciativa Agile era que, para ellos el objetivo de Agile no era innovar y entregar más valor al usuario, sino acelerar los proyectos.
El techo de cristal de las transformaciones ágiles
Muchas transformaciones ágiles nacen de equipos ágiles o directores de desarrollo que apuestan por Agile como un modelo para entregar el software más rápido, con mayor calidad y satisfacción de los usuarios. Eso es un buen punto de inicio y si se hacen las cosas bien, se pueden comenzar a tener resultados iniciales en pocos meses y un cambio más profundo en la mayoría de los proyectos en 2 o 3 años.
Estas iniciativas no suelen transformar la organización porque éstas se concibieron desde IT y para IT. El negocio, a nivel de diseño organizativo, proceso presupuestario y de la manera en que la estrategia se diseña y operacionaliza sigue inmune a la transformación ágil. Si se pone en foco en lo conseguido, es positivo. Si se piensa en la agilidad de negocio, como el motor de innovación alrededor del usuario, muchas transformaciones ágiles fracasan.
¿Qué es agilidad de negocio?
La agilidad de negocio es la capacidad de una organización para:
- Adaptarse a cambios en el mercado con rapidez.
- Responder con velocidad y flexibilidad a las necesidades de los clientes.
- Innovar continuamente para obtener una ventaja competitiva
Aunque desarrollar los proyectos IT con rapidez es necesario para obtener agilidad de negocio, la agilidad de negocio debe comenzar replanteando como se planifica y se comunica el negocio, no el desarrollo de software (Agile).
Como obtener agilidad de negocio
Los siguientes principios no son una receta trivial en absoluto de implementar por el cambio profundo que suponen, pero sí acciones lógicas que suelen funcionar en las organizaciones que consiguen agilidad de negocio.
El primer equipo ágil debe ser el de Dirección
Dice Klaus Leopold [1] que para obtener agilidad de negocio, el primer equipo que debe adoptarla es la dirección. Estos son los motivos:
- Si la capacidad de adaptación del negocio debe ser alta, las decisiones de dirección deben tomarse con agilidad.
- Si la Dirección incorpora una mentalidad y prácticas ágiles, se tomará en serio como impulsar la agilidad en el resto de la organización.
- Si la Dirección practica la agilidad, el resto de la organización creerá en ella.
Se debe agilizar la estrategia organizativa
La Dirección es la responsable de definir y ejecutar la estrategia. La práctica tradicional de planificación estratégica suele definir una cartera (portfolio) de proyectos transformadores para varios años. Tener una hoja de ruta a medio plazo es necesario, pero la estrategia debe articularse de manera ágil:
- Las iniciativas estratégicas deben ser más pequeñas, p.e. ejecutables y validables en <90 días.
- El presupuesto de inversión debe asociarse a los objetivos y revisar las prioridades frecuentemente (p.e. <90 días)
Participación abierta en la estrategia
La definición y seguimiento de la estrategia no debe ser algo privado para la Dirección. Éstos marcaran los objetivos estratégicos, pero:
- Muchas iniciativas estratégicas pueden partir de los equipos que trabajan resolviendo problemas de cliente.
- Cuando los equipos saben que su trabajo tiene un objetivo claro y pueden medir su consecución, están más motivados.
- La priorización y seguimiento conjunto de las iniciativas entre Dirección y los equipo dispara la transparencia y la colaboración.
Coordinación activa de las iniciativas
Drucker [2] dijo que la estrategia es un producto y que su ejecución es un arte. En una organización, especialmente si tienen tamaño medio o grande, debe crearse transparencia sobre el flujo de las iniciativas y las dependencias entre equipos que pueden frenarlas.
- Los equipos deben visualizar las dependencias con el trabajo de los demás para poder gestionarlas periódicamente (p.e. semanalmente o más frecuentemente).
- La visualización de las iniciativas para Dirección debe permitir detectar cualquier bloqueo en las iniciativas y poder ofrecer apoyo para eliminarlo.
La relación entre estrategia y gestión del trabajo
Podemos tener una jerarquía con objetivos más ambiciosos (p.e. a conseguir en 1 año o más), pero es necesario definir hitos intermedios para inspeccionar y adaptar con más efectividad. El modelo OKR (Objectives and Key Results) va en esta dirección.
- Las Iniciativas deberían ser pequeñas (<3 meses) y definirse mediante un cambio medible, ya sea interno o para los clientes (p.e. el concepto Key Result).
- Las Épicas deberían ser contenedores de historias de pocas semanas que puedan realizarse preferentemente un único equipo y que contribuyan directamente a la iniciativa.
- Las Historias deberían ser paquetes de trabajo pequeños (p.e. <1 semana), realizables por un equipo y que ofrezcan un resultado concreto al cliente.
- Las Tareas son pasos intermedios que realizan los equipos para realizar las historias y la única relevancia que tienen fuera de los equipos es gestionar dependencias con otras personas o equipos.
No se trata de escalar la agilidad, sino de agilizar la organización
Frecuentemente se habla de las dificultades de “escalar la agilidad” en una organización. El motivo, que no se conoce tanto, es el enfoque equivocado. La agilidad puede funcionar relativamente bien en unos equipos aislados, pero chocará habitualmente con la organización actual si tratamos de extenderla más allá del desarrollo de software.
Más allá de empeñarse en seguir con el mismo enfoque, y con los mismos resultados, es necesario reencuadrar el problema de “No soy ágil porque no tengo equipos ágiles” a “Quiero agilizar las iniciativas de negocio parte de la solución son equipos ágiles”.
Si se quiere obtener agilidad de negocio, sí se debe comenzar la casa por el tejado. Hacer ágiles a los equipos de software traerá beneficios, pero es una optimización local que no hará ágil a la organización.
Para saber más…
- Klaus Leopold habla sobre agilidad organizativa.
- Se le atribuye esta cita a Peter Drucker
- Scaled Agile Framework 5 tiene contenidos dedicados a Business Agility.
¿Quieres recibir más información y recursos de calidad?
¡Suscríbete a nuestra newsletter mensual!
Cada mes enviamos una newsletter a más de 1.200 personas con contenidos, recursos y ofertas especiales de nuestros cursos. Queremos ofrecer contenido de calidad y sin spam.
