Simplemente no funcionará: Desmontando el mito de la agilidad en los servicios compartidos

"Simplemente no funcionará".

Como consultor de Agile, eso es lo que oigo con bastante frecuencia procedente de los equipos de Servicios Compartidos.

Claro, es genial ver cuando nuestros socios de AppDev pueden proporcionar valor de forma iterativa en un solo producto. Incluso apoyaremos esos esfuerzos desde una perspectiva de back-end. Pero nuestro trabajo es demasiado fluido, demasiado dinámico. No tenemos un único producto. Apoyamos muchos productos y muchas herramientas repartidas por toda la empresa.

Agile no funciona aquí. La lista de razones es larga. Además de las anteriores, podría incluir: 

• Tradicionalmente se nos percibe como un gasto operativo frente a una organización de valor añadido.
• Estamos estratégicamente instalados en silos de conocimiento.
• Nuestras prioridades pueden cambiar a cada minuto, así que comprometerse con un cuerpo de trabajo que no cambie es casi imposible.
• Tenemos que trabajar por la noche y los fines de semana, así que no es posible mantener un ritmo sostenible.

Cuando se mira desde fuera, puede parecer que lo que llamamos "Agile" no es una buena forma de construir un entorno de Servicios Compartidos. Pero es importante entender qué es Agile en realidad.

Agile es un conjunto de cuatro valores y 12 principios diseñado para cambiar nuestra forma de pensar sobre la entrega de valor; independientemente de cómo se defina el valor.

¿Se puede mostrar "agilidad" en "cascada" o en la gestión tradicional de proyectos? Sí. Lo que ocurre es que 'Waterfall' no apoya la mentalidad ágil del mismo modo que otros marcos como Scrum o Kanban (y 'Waterfall' puede fomentar malos comportamientos).

¿Y si te dijera que los métodos ágiles pueden aplicarse, y se han aplicado, en grupos de Servicios Compartidos e Infraestructuras con enorme éxito? Incluso han sido capaces de hacerlo utilizando algunos de los mismos métodos vistos en otras áreas de la empresa.

Echemos un vistazo a algunas de las áreas de preocupación más comunes y a las técnicas utilizadas para ganar Agilidad.

Solicitudes de obras urgentes

Desafío: Volvamos a ese tornado siempre presente de solicitudes que atormenta a los equipos de Infraestructuras y Servicios Compartidos. Es simplemente la naturaleza del flujo de trabajo. Para estos equipos, los cambios se producen cada día, cada hora, a veces cada minuto.

Cuando tu trabajo requiere un soporte 80% (o más) que cambia cada minuto y actividades de proyecto 20% estáticas, puede ser difícil centrarse en un cuerpo de trabajo singular o incluso tener la capacidad de comprometerse con un Sprint Backlog Scrum de 2 semanas.

Solución: Hay un par de formas de abordar este problema dentro de un marco ágil. Scrum, que sigue siendo el marco más utilizado, tiene lo que se conoce como "Interrupt Buffer". Esta pequeña herramienta está diseñada para crear transparencia a todos los cambios que se están produciendo y crear un espacio para lo que está consumiendo tu tiempo fuera del trabajo comprometido. Esto te ayuda a medirlo y a planificar lo que podemos "el tiempo de ayer". ¿Cómo podemos utilizar esa información para ser mejores, más predecibles?

Algunas zonas han tenido éxito al emplear Kanban como un estilo de funcionamiento de flujo continuo, o de fabricación ajustada. 

Si bien esto elimina la necesidad de iteraciones y de tener que cambiar potencialmente el trabajo y las prioridades a mitad del proceso, un equipo hace bien en recordar que sigue siendo importante tener una sola voz de prioridad en el backlog, un propietario y entrenador de nuestro proceso, tiempo para parar e inspeccionar para adaptarse a la mejora continua y planificar como un equipo. Son buenas ideas, independientemente del marco.

Medición del impacto de los servicios compartidos en una organización

Desafío: ¿Se puede valorar la creación de un nuevo tipo de volante en el valor global de un coche de nuevo diseño? A menos que seas actuario, probablemente no.

Sin embargo, ese nuevo volante ha añadido valor de alguna manera o forma. Qué tiene que ver esto con los Servicios Compartidos o los equipos de Infraestructuras.

Todo.

Como he dicho antes, estos equipos no suelen tener su propio producto o servicio, sino que potencian a los que sí lo tienen. Aumentan otros equipos con sus conocimientos especializados y conjuntos de habilidades. Dar poder a otros es algo poderoso. Pero esto puede dificultar la demostración de cómo estos equipos ayudaron a la organización en su conjunto (o a subconjuntos de la organización) a alcanzar sus Objetivos de Producto.

Las métricas importan. Entonces, ¿cómo puede medir el valor de un equipo de Servicios Compartidos o Infraestructuras?

Solución: A la hora de medir el impacto de los servicios compartidos, es importante contar con objetivos claros y compartidos a partir de los cuales trabajar. OKR (Objetivos, Resultados Clave) son precisamente una de esas herramientas que utilizan cada vez más organizaciones.

El propósito de los equipos de Infraestructuras y Servicios Compartidos es mover la aguja en áreas específicas. 

Prestar servicios especializados que nadie más puede ofrecer. Sin embargo, si su organización tiene objetivos claros y compartidos, medir el impacto es tan sencillo como demostrar que el equipo aportó valor añadido ayudando a alcanzar objetivos específicos de formas concretas. Puede que su equipo no esté diseñando todo el coche nuevo, pero su nuevo volante añadió valor y fue un componente clave para alcanzar ese Objetivo de Producto.

Silos de conocimiento

Desafío: Tenemos el equipo de servidores, el equipo de redes, el equipo de datos, el equipo de telecomunicaciones, el equipo de seguridad, etc. El problema es que cada vez más vemos que un conjunto de servicios empresariales tiene necesidades de todos estos grupos, que deben colaborar en muchas áreas de valor. Además, cuando llega un ticket de soporte, invariablemente rebota de un equipo a otro mientras todos señalan con el dedo dónde está el problema. Esto crea una insatisfacción masiva de los clientes.

Solución: Equipos de apoyo a los servicios empresariales - Los equipos pequeños e interfuncionales promovidos en Scrum se están creando con éxito en favor de los silos de conocimiento para proporcionar tanto trabajo de proyecto como apoyo a los servicios empresariales específicos prestados; no muy distinto de un equipo interfuncional para apoyar un único producto en AppDev.

Los miembros de cada uno de los grupos descritos, según sea necesario, se colocan en un único equipo, que trabaja en equipo y desarrolla "T-Shaped-ness" en apoyo de un Área de Servicio de Negocio. Esto significa que un ticket va a un equipo con todas las habilidades para resolverlo; casi eliminando el carrusel de tickets de soporte.

Recuerde que los métodos ágiles se desarrollaron para ayudar a abordar las áreas de trabajo en las que normalmente se producen muchos cambios. Si algo tienen las infraestructuras y las operaciones son cambios intensos. Echa un vistazo a los métodos y marcos que ofrece Agile.

Algunas partes de este artículo aparecieron originalmente en un blog de la Alianza Ágil también escrito por Robert Woods.