Modelos de agilidad en escala

Scrum es probablemente la aplicación más conocida de los principios de agilidad en la construcción de software y en otros ámbitos de conocimiento y de práctica. De hecho, scrum nació a finales de los 80 en el mundo del marketing y del desarrollo de producto. En TI, algunos de los fundadores de scrum fueron parte del grupo que publicó el Manifiesto Ágil. La idea es conocida: cada incremento o mejora de producto (product increment) se puede descomponer en ciclos de desarrollo menores (sprints) de los que se ocupa un equipo pequeño de participantes de diferentes procedencias, incluido el cliente, situados en el mismo espacio físico y dedicados de forma intensa y entusiasta. El despliegue es incremental e iterativo y el resultado siempre es imperfecto, pero se puede poner en producción rápidamente. Algun0s otros artefactos y roles de scrum, como el product owner, el backlog, las reuniones cortas diarias, el scrum master, las retrospectivas y los papelitos pegados en una pizarra forman parte ya del instrumental de la producción de sotware en cualquier parte.

Presentación a alto nivel de los artefactos de SAfe

Scrum funciona bien en esfuerzos donde el alcance es abierto y los requerimientos pueden cambiar frecuentemente. Va mejor con equipos y proyectos no muy grandes y que no requieran un gran número de interdependencias o integración con otros proyectos o con aplicaciones heredadas (legacy). Funciona mejor con perfiles relativamente homogéneos de desarrolladores acostumbrados a trabajar así. Es una organización muy plana, sin jerarquías ni grandes especialidades. Requiere  una cultura organizativa propicia y tiene una curva de aprendizaje, pero no es dramático. Puede ser bonito, excitante, divertido y los resultados, en general y bajo las condiciones anteriores, pagan.

En las circunstancias que hemos descrito, scrum se ocupa más que bien  de la ejecución del proyecto (la producción de software), pero no es un método integral ni para la gestión de proyectos ni para el ciclo completo de delivery de productos de TI; o sea lo que hay antes (la selección y definición de los proyectos y la asignación de recursos) y lo que hay después (el mantenimiento, evolución y protección de los activos). Y, por supuesto, no es un modelo de gestión de los departamentos de TI u otros de la empresa.

Animados por el éxito y la oportunidad, algunos de los fundadores de scrum (como Jeff Sutherland y Craig Larman) y otros epígonos han desarrollado modelos o amplicaciones que aspiran a vencer las limitaciones anteriores, como son Scrumban o MoP (para el mantenimiento de aplicaciones), Large Scale Scrum, Scrum the scrums, DAD (Disciplined Agile Delivery) o SAFe (Scaled Agile Framework), para la planificación y gestión de muchos esfuerzos o proyectos (portafolios) de diferente tamaño y complejidad en organizaciones grandes y con muchos equipos, es decir, para escalar la agilidad.

SAFe, por ejemplo, es una combinación de principios de Lean y Agile dentro de un marco metodológico bastante completo que podéis descubrir en su web, que está bastante bien, El framework de alto nivel se creó en 2007 y ya va por la versión 4.6 de este mismo año. Para mí, sus temas más interesantes son:

-el backlog jerárquico, que permite relacionar y priorizar cualquier tipo de demanda (lo nuevo, lo evolutivo o lo incidental) contra cualquier tipo de oferta (lo que se hace ágil, en cascada o la gestión de servicios bajo diferentes métodos).

-los mecanismos de priorización, con un mayor peso de la visión económica («take an economic view» es uno de sus principios), sobre la visión técnica.

-la limitación del trabajo en curso (WIP), de manera que no puede entrar en cada fase del ciclo más trabajo del que podemos hacer con la capacidad disponible.

-el concepto de producto, donde se fusionan los proyectos y servicios en flujos de valor únicos.

-la sincronización de entregables (lo que llaman release train), que planifica y gestiona con detalle el flujo continuo de producción y la colaboración justo a tiempo de los diferentes participantes.

-un conjunto (quizá exagerado y poco «ágil») de puntos de decisión a lo largo del ciclo de delivery.

-nuevos roles, responsabilidades y relaciones de trabajo, procedentes en su mayoría de Lean y Agile (de nuevo me parecen muchos y a veces difíciles de entender). En SAFe la responsabilidad (acountability) nunca se difumina y la transparencia es completa. Puedes correr, pero no puedes esconderte.

-procesos iterativos y de aprendizaje, bastante parecidos a los de Scrum the Scrums.

SAFe, aunque tiene su terminología abstrusa, sus cofradías y certificados, resulta bastante modular y versátil, es decir, se pueden adoptar algunos de sus artefactos sin necesidad de importarlos todos. SAFe es agnóstico, pero funciona mejor en culturas ágiles. Según los que administran la marca, la mitad de las empresas del Dow Jones lo utilizan ya, en todo o en parte. Para las tribus más radicales de Ágil, SAFe resulta dirigista y burocrático. Es posible. Pero para los que nos dedicamos a la gestión, resulta una plataforma potente para socializar Ágil fuera del mundo de la producción de software y escalar de forma más efectiva la agilidad a la organización de TI en su conjunto.

En informática, el diablo está en los detalles. En la implantación de SAFe o cualquiera de los modelos de agilidad en escala, el diablo está en diseñar cuidadosamente el proceso de implantación, adaptarlo a cada contexto empresarial, iterar y aprender. Seguiremos por esta vía en algún momento.