El agilismo de consumo rápido no convertirá tu gestión de servicios en una práctica ágil

De una forma u otra, la gestión de servicios está a la orden del día. Independientemente del esquema o el marco de referencia que utilices, el objetivo es estandarizar una serie de buenas prácticas que nos permitan escalar con nuestros servicios de TI de una manera efectiva y eficiente.

Agilismo

El “agilismo” se refiere a movimientos y actitudes que promueven la agilidad tal y como la entendemos dentro del ámbito de la ingeniería del software, donde se ha desarrollado principalmente a partir de las disciplinas de producción ajustada. Sin embargo, ha proliferado su aplicación fuera de contexto en ámbitos diversos a modo de “degustación”, convirtiéndolo, en cierto sentido, en una suerte de superchería, vendiendo comida rápida como si de un producto gourmet se tratara.

¿Te suena?

Si aceptamos el neologismo, el “agilismo” se refiere a movimientos y actitudes que promueven la agilidad tal y como la entendemos dentro del ámbito de la ingeniería del software, donde se ha desarrollado principalmente a partir de las disciplinas de producción ajustada. Sin embargo, ha proliferado su aplicación fuera de contexto en ámbitos diversos a modo de “degustación”, convirtiéndolo, en cierto sentido, en una suerte de superchería, vendiendo comida rápida como si de un producto gourmet se tratara.

La llegada de la ISO 20000-1:2018 incluía novedades encaminadas, entre otras cosas, a incorporar elementos de los marcos de trabajo ágiles que habían venido ganando popularidad entre las organizaciones empresariales dedicadas a la gestión de servicios de TI.

Me ha parecido pertinente recuperar y traer aquí algunas reflexiones sobre la tradicional dicotomía entre los estándares para la gestión de servicios de TI (ITSM) y las metodologías ágiles que me parece interesante revisar en un escenario en el que cada vez más empresas nos vemos en la necesidad de hibridar lo que aún hoy siguen siendo dos aproximaciones obligadas a convivir en total simbiosis.

Dolf van der Haven, miembro del ISO/IEC JTC 1/SC 40 que está detrás del desarrollo de la ISO/IEC 20000-1, hacía una aportación relevante en este sentido allá por 2016, sobre cuyas tesis volvía hace apenas un par de años en una entrevista que publicaban desde la organización encargada del mantenimiento de los estándares ISO.

El argumentario habitual se centra en contraponer los esquemas tradicionales de estandarización (representados por la ISO 20000-1:2018) y las aproximaciones ágiles como antagonistas, sacando habitualmente de contexto la definición y documentación extensiva de procesos de los primeros y la “ligereza” de las segundas en términos de artefactos y procedimientos.

El discurso de Dolf, por el contrario, se centra en la complementariedad de ambos esquemas conceptuales, viendo la eficacia basada en procesos de la ISO y la eficiencia basada en el flujo y la entrega de valor de las metodologías ágiles como dos caras de la misma moneda.

En resumen, hay más puntos de encuentro, basados fundamentalmente en la flexibilidad -en lo que a la mejora continua y la gestión del cambio se refiere- y la satisfacción del cliente (interno y externo) mediante la entrega continua de valor, que divergencia en sus planteamientos. De hecho, el esfuerzo realizado en la implantación de SAFe 5 nos ha permitido hilar mucho más fino en la re-certificación de la ISO 20000-1, además de facilitarnos nuestra primera vez con la ISO 33000, que sustituye a la ISO 15504, que partía inicialmente del estándar para el ciclo de vida de procesos ISO 12207 y modelos de madurez como el CMM.

A lo largo de las dos décadas que han pasado desde la redacción del Manifiesto Ágil, han sido muchos los falsos mitos que se han popularizado y sacado de contexto a partir de la letra del mismo, con una total falta de consideración por el espíritu que inspiraba sus principios constituyentes.

En el imaginario popular, la práctica del agilismo “desprecia” la generación de documentación y la sustituye por la entrega continua de incrementos de producto potencialmente usables, consumibles. Dentro de la práctica profesional de la ingeniería del software basada en metodologías ágiles, la generación de documentación, como cualquier otra actividad o tarea, se incluirá en el backlog siempre que genere valor. Cualquier pieza de trabajo que no genere valor se considerará un “desperdicio” y se evitará siguiendo un principio, recuperado por la filosofía de la producción ajustada, de ‘mottainai’ que, de hecho, se identifica con la era Edo en el Japón feudal (1603 – 1898).

En el imaginario popular, se entiende, además, que la práctica del agilismo tiene poca consideración por la actividad de planificación, dando mucha más importancia a la velocidad de entrega y la adaptabilidad basada en iteraciones cortas de desarrollo. Sin embargo, dentro de la práctica profesional de la ingeniería del software basada en metodologías ágiles, ocurre que la capacidad para gestionar la variabilidad propia de los proyectos complejos a los que nos enfrentamos se apoya, precisamente, en una obsesión por la planificación: planificamos cada día (en el Scrum diario), planificamos cada iteración, incluso refinamos esa planificación a lo largo de cada iteración, en el caso de SAFe planificamos cada incremento de programa… y se sincroniza con la planificación de cada iteración.

Podría seguir, pero a los efectos de esta breve reflexión, me sirve con este par de ejemplos para ilustrar el tipo de malentendido que habitualmente se convierte en antipatrones que pueden lastrar cualquier implantación de este tipo de frameworks, desde Scrum o Kanban, hasta marcos de trabajo para el escalado de los primeros a nivel empresarial, como es el caso de Nexus, LeSS o SAFe.

e-Fumérides

¿Has implantado un marco de trabajo como SAFe? ¿Has tenido la oportunidad de incluirlo en la certificación para la gestión de servicios de TI? Comparte tu experiencia o contáctanos si necesitas ayuda o te interesa explorar este tipo de herramientas.