Hace falta valor para subirse al tren del agilismo con SAFe

En principio, en el ámbito de la ingeniería del software, las empresas como la nuestra, vivían un impacto directo sobre su forma de trabajar aparentemente mínimo: se trataba de decir a todos nuestros colaboradores que pillaran el portátil, extendiendo nuestra política, ya existente, de trabajo a distancia.

Lo cierto es que el devenir de los tiempos nos ha dejado ver un impacto notable en algunos aspectos clave de la manera en que habitualmente trabajamos, apoyándonos en las técnicas y metodologías propias del “agilismo”.

Este tipo de metodologías se apoyan, fundamentalmente, en la interacción cercana y frecuente de todos los interesados en las actividades de desarrollo, es decir, los miembros del equipo ágil, los clientes, los responsables del negocio, etc. Esta interacción se ha ido hacia los entornos virtuales de manera masiva y la etiqueta, los protocolos, las convenciones culturales, los tiempos, etc. difieren notablemente de los asociados a un entorno físico compartido y la interacción cara a cara.

Es evidente que no todas las profesiones admiten un esquema de trabajo deslocalizado, pero sí está claro que el trabajo a distancia por sí solo no ha conseguido vacunarnos contra un presencialismo endémico.

Por otro lado -y también en parte derivado esto mismo- crece la importancia y la disponibilidad de los datos para evaluar el rendimiento de los equipos trabajando en ese tipo de entornos, siempre híbridos, pero más virtuales que físicos. Hoy, es más fácil y más necesario que nunca migrar hacia un escenario dirigido por, u orientado a datos (Data Driven).Al hilo de esos dos elementos, resultará más importante que nunca poner el foco en la gestión del cambio si queremos sobrevivir en ese nuevo escenario híbrido y dirigido por datos que, además, está facilitando que la filosofía ajustada (Lean) y las metodologías ágiles trasciendan su ámbito originario de la “gestión” de proyectos para la ingeniería del software.

Edosoft, SAFe y el Agilismo

Con más de tres lustros de historia, Edosoft nacía como factoría de software dentro de un grupo empresarial con una amplia tradición ligada al aseguramiento de la calidad del software, de tal manera que siempre se han considerado a las metodologías, las técnicas y prácticas ágiles como una componente nuclear del negocio.

Estando las operaciones y la producción de la empresa directamente ligadas al desarrollo software para terceros, la práctica diaria a nivel de equipo se sustentaba sobre Scrum como marco básico de trabajo, incluyendo técnicas propias de XP y elementos de la cultura DevOps.

Mientras el negocio se apoya en una estructura tradicional funcional con una PMO al uso encargada de la interlocución con los clientes y la dirección de proyectos, la producción va al ritmo del scrum de los equipos de desarrollo. Esta dicotomía impone una cierta “desadaptación de impedancias” que hace difícil conectar de manera natural el negocio con la ejecución: falta sincronización y los órganos de dirección no escalan igual que lo hacen los equipos.

Tal y como sostiene Alejandro Salazar (Teoría de la Estrategia Emergente), “Estrategia es lo que se hace” y nosotros, en Edosoft, hacemos software… Vivimos tiempos inciertos y no hay planificación estratégica que valga más allá de la hoja de cálculo en la que se ha plasmado; de ahí la importancia del verbo “hacer”.

Necesitábamos conectar negocio con ejecución de tal manera que todo el sistema resultara “escalable”. La propuesta de SAFe 5 como marco de trabajo basado en dos esferas, de programa y de equipo, que giran en sincronía y que no interfieren con la estructura organizativa funcional de cualquier organización empresarial madura, se revelaba como la solución más adecuada.

Es importante entender que todos en la organización vamos en el mismo tren: nuestro metafórico tren de entregas (Agile Release Train, ART) . Se trata, en cierta manera, de un rompehielos como el de la celebrada cinta, convertida en un clásico moderno, dirigida por el coreano Bong Joon-Ho y basada en el poco conocido universo creado décadas antes por Jacques Lob. De alguna forma, este tren se ha convertido en nuestra “circunstancia”: es un tren que no se detiene nunca, surcando nuestro planeta de un extremo a otro, con mil y un vagones.

Edosoft no deja de ser un David cualquiera con aspiraciones de matagigantes en un entorno competitivo muy complejo. Nuestra visión es toda una declaración de intenciones, “somos una empresa Ágil, comprometida con la cultura DevOps, que desarrolla soluciones Cloud con Impacto”. 

El tránsito conceptual y cultural que motiva el viaje iniciático de cualquier practicante de SAFe, ‘project to product’, en nuestro caso, nos ha llevado de los proyectos… a los proyectos “con sabor a producto”. 

Gestión del cambio: cultura y organización

Cuando hablamos de transformación, estamos hablando de la gestión del cambio: hablamos de personas, de cultura y de organización. No es necesario acudir a los clásicos de la psicología organizativa ni a los arcanos de la teoría de sistemas y de la ciencia de la complejidad para darnos cuenta de que necesitamos prestar atención al menos a tres (o cuatro) elementos íntimamente relacionados: Organización (O), Individuos (I), Tecnología (T)… y Procesos (P).

El siglónimo asociado, que a mi personalmente me ha resultado útil en diversos escenarios, da nombre a un modelo, OITP, que se apoya precisamente en esos arcanos de la Teoría de Sistemas, como la metodología de sistemas “blandos” (Soft Systems Methodology, SSM) de Checkland.

Edosoft sigue siendo una pyme: medio centenar de personas que se organizan para ofrecer una cartera de servicios competitiva en el ámbito de la ingeniería del software. Existen, a mi juicio, dos elementos que precipitan la necesaria transformación del negocio. El primero, de carácter más, si se quiere, estratégico (siempre me pareció deleznable el uso que se le da a esta palabra) se refiere al lanzamiento de una línea, novedosa, dedicada a la innovación de producto. El segundo, de carácter más operativo, tiene que ver con la falta de “alineamiento” de los distintos equipos de desarrollo: todos intentando seguir el mismo esquema basado en Scrum, pero sin una coordinación precisa, ni eventos o artefactos estandarizados o normalizados más allá de cierta disciplina impuesta por algo parecido a una oficina de proyectos (llamémosla PMO).

Evidentemente, a nadie se le escapa que la transformación de una ingeniería de software a una empresa de producto “pura” es un viaje largo y con numerosos escollos en el camino, sobre todo culturales. Se trata de un tránsito que puede resultar traumático, pero que se debe emprender con decisión y con la convicción de que las empresas que estamos en el mercado jugamos para ganar; y para ganar, tal y como asevera un conocido estratega argentino hablando en términos futbolísticos, solo hay que marcar un gol más que tu adversario.

Es en el segundo aspecto, el operativo, donde observamos cambios más inmediatos, revelándose numerosas inconsistencias y  oportunidades de mejora dentro de Edosoft. El alineamiento de los equipos y la sincronización a nivel de programa, junto con un sólido principio de transparencia ha facilitado el contagio de un nuevo sentido de pertenencia precisamente cuando más lo necesitábamos, es decir, en plena pandemia.

Artefactos técnicos: aquellos locos con sus locos cacharros

Desde mi propia experiencia, he podido comprobar más de una vez como la implantación de diversos marcos de trabajo, herramientas conceptuales, metodologías, etc. se acaba mimetizando y confundiendo, por su carácter instrumental, con las herramientas técnicas utilizadas para darles soporte. SAFe no es una excepción. El ecosistema de herramientas disponibles para la gestión del ciclo de vida del desarrollo de software no deja de crecer… y da la impresión de que empezamos a superar la nostalgia que nos ataba a los pósits de colores.

En nuestro caso, nuestra “factoría” de software se sostiene sobre Gitlab. Una plataforma con la suficiente versatilidad como para incluir la planificación a nivel de equipo y de programa que realizamos dentro de SAFe.

Aun así, el empirismo propio de este tipo de marcos de trabajo nos llevó a probar, tropezar, pivotar y volver a probar. Se acabó imponiendo Notion como alternativa para la gestión visual de numerosos tableros kanban conectados, que nos permitían tener una trazabilidad completa de los artefactos a nivel de Portafolio, Programa y Equipo.

A día de hoy es Notion la herramienta que proporciona el soporte instrumental de nuestro tablero de programa para el PI Planning, así como el Portfolio Kanban, el Program Kanban… y los OKR como herramienta de dirección por objetivos que conecta los temas estratégicos con la ejecución del programa.

Lecciones aprendidas: lo bueno, lo feo y lo malo

Necesitas formar esa “coalición crítica” necesaria en todo proceso de gestión del cambio para avanzar en las primeras etapas de tu viaje y ganar suficiente “tracción” para escapar de las inercias adquiridas por la organización. Se puede constituir como LACE (Lean-Agile Center of Excellence), o no; pero necesitas que exista y que sus miembros alberguen un inagotable afán pedagógico. Personas inasequibles al desaliento y capaces de gestionar la frustración con solvencia y profesionalidad. Es importante que ese grupo de personas se constituyan como un verdadero equipo ágil “virtual” y que no se convierta en un “comité”.

Debemos evitar que SAFe se convierta en una nueva jerarquía dentro de la organización. Contrariamente a lo que uno podría pensar, una pyme es muy susceptible de crear antipatrones de este tipo, convirtiendo este marco de trabajo en el sustituto de líneas de reporting funcional poco definidas. Puede ocurrir sin que te des cuenta: los PO actúan como subordinados funcionales del PM, los SSM hacen lo propio con el RTE, etc. Es posible que las personas que juegan ese rol ocupen, además, posiciones jerárquicas con esas dependencias; pero se asociará directamente a SAFe un línea de reporting que en absoluto prescribe este marco de trabajo.

No se trata tanto del tamaño como de la sistematización y la industrialización de la ingeniería del software como actividad productiva. Se trata de ser previsibles y golpear como un martillo pilón, manteniendo ritmo, sincronización y cadencia, a nivel de equipo y de programa, soportando las inclemencias de un entorno cada vez más competitivo y hostil. 

La obsesión por el valor es necesaria: es lo que nos motiva. Es importante entender esto sin obsesionarnos, valga la redundancia, por la definición de un flujo (value stream) que en el caso de nuestra cartera de servicios para el desarrollo y el mantenimiento de aplicaciones informáticas, se sustancia, precisamente, en la industrialización del ciclo de vida del desarrollo de software (SDLC).