Imagina trabajas en una compañía dedicada a instalar calderas para calefacción. Los componentes principales de tu cadena de valor hacia el cliente son:
- La entrega e instalación de las calderas.
- Su mantenimiento, tanto hardware como del firmware, si se trata de una caldera inteligente.
- La atención al cliente y la facturación.
La empresa ha decidido transformarse en una organización Agile. ¿Como lo haces? En los 2 primeros puntos, pocos son los aspectos en que podremos someternos a ciclos iterativos, formando equipos autorresponsables y multidisciplinares o definir un MVP. La caldera es lo que es. De manera que únicamente nos quedará el desarrollo y evolución de los sistemas TI detrás de la gestión para asimilar el HACER AGILE. El resto de la organización únicamente podrá transformarse hacia SER AGILE.
Cuando decidimos que un departamento TI evolucione hacia una metodología Agile, debemos evaluar con mucho cuidado las interdependencias entre los diferentes servicios en que desmembremos los grandes sistemas de la organización, toda vez que un excesivo control por departamentos transversales podría generar múltiples dependencias entre las entregas de cada uno de ellos. Esta situación impediría su libre evolución autónoma, y encadenaría a nuestra organización a una especie de modelo de trabajo con un desarrollo en sprints de corta duración, pero con entregas masivas propias de los modelos en cascada.
El ejemplo anterior surge a partir de un artículo publicado por Mark Balbes en ADTMag en el que plantea el caso, frecuente en muchas grandes organizaciones, de que la voluntad de transformación se ve lastrada por un excesivo control por parte de la organización convencional de TI. Y no por falta de convencimiento o esponsorización por parte de la dirección, sino que frecuentemente esta situación proviene de la buena intención de no convertir a Agile en un experimento de laboratorio permanente.
Al introducir nuevas metodologías, igual que al introducir otras transformaciones como Cloud, ITSM u otras, la opción más frecuente consiste en ejecutar pilotos para evaluzar la validez de su aplicación. De esta manera podemos estudiar la introducción de novedades en la operativa existente en la organización y buscar una integración más suave entre lo existente y la novedad. Esta aproximación tiene un gran riesgo, y es que al perderse el impulso de la esponsorización inicial, aquello que está llamado a transformar nuestra empresa termina en ocasiones arrinconado como una rareza permanente, o se asimila a la organización adoptando las operativas y modelos anteriores, anulando el deseado efecto transformador.
Con Agile corremos el riesgo de que suceda lo mismo. Y podemos pensar que una solución puede ser incorporarlo a nuestros modelos de arquitectura convencionales. Tomar esta decisión sin tener en cuenta la necesidad de autonomía y de trabajo en ciclos cortos iterativos, puede llevarnos a una situación como la expuesta.
El autor del artículo ofrece posibles soluciones más o menos inspiradas. Pero detrás de ellas yace la solución fundamental. Las áreas transversales dentro de TI deben convertirse en centros de servicio, ofreciendo soluciones y prestando ayuda a los equipos de desarrollo, independientemente de si estos trabajan bajo modalidades convencionales o bajo modelos Agile. Quien presta servicio debe adaptarse a quien recibe el servicio, y no actuar como policía de lo que es correcto. Y esto que es tan evidente cuando contratamos cualquier prestación en nuestra vida personal, debe convertirse en la base fundamental de nuestro trabajo. Si lo logramos, habremos dado un paso de gigante en nuestro camino hacia SER AGILE.
Imagen: Field Engineer en Pexels.com.