Management

Introducción

Aplicar una metodología ágil en IT es relativamente sencillo, por ejemplo, Scrum, Kanban, XP, o una combinación de todas ellas. Pero son propuestas pensadas para un proyecto o un único equipo; también podemos hablar de “escalar Scrum”, pero al fin y al cabo eso sólo consiste en dividir un backlog en partes para poder paralelizar el trabajo de más de un equipo… que siguen dentro del mismo proyecto.

Pero, ¿qué ocurre cuando queremos agilizar el departamento de IT? Es decir, ya no tenemos “un proyecto” (que puede ser pequeño, o en el que colaboran 5 ó 6 equipos de personas), sino múltiples proyectos, y además múltiples servicios: mantenimientos, evolutivos, correctivos, acuerdos de niveles de servicio que hay que cumplir para resolución de incidencias y problemas… y además de muchos clientes a la vez, cada uno con su contrato. Pero entre las ¿25, 30, 40, 60? personas del departamento de IT, tenemos que llevar todo ese montante de trabajo en paralelo, cumpliendo con las condiciones de todos los contratos y con todas las entregas de todos los proyectos.

Y claro, para eso, pensamos “si trabajamos de forma ágil a nivel departamental seguro que lo hacemos mejor”, y así es pero… ¿y eso cómo se hace? Pues consiguiendo poner en marcha los denominados “trenes de trabajo”, a lo que se llega si conseguimos dos cosas:

1. Que se utilicen tableros de trabajo multiproyecto (o multicontrato o multiservicio, como queramos llamarlos),
2. y que todo el departamento trabaje en iteraciones con la misma duración.

Veamos en detalle cómo conseguir estas dos cosas.

Proyectos, servicios… ¿y qué más?

Resulta muy académico decir que “el departamento de TI tiene la labor de gestionar y entregar proyectos y servicios…”, pero no es tan simple en la vida real, al fin y al cabo, el trabajo de un departamento TI suele incluir:

• Desarrollo de proyectos para clientes, para cumplir compromisos de entrega (productos mínimos viables incrementales).
• Operación de servicios de clientes, que incluye resolución de incidencias, problemas, peticiones, y en todo caso cumplir con los acuerdos de nivel de servicio en cuanto a capacidad, seguridad, continuidad y disponibilidad.
• Proyectos y servicios internos: desarrollo y mantenimiento de una intranet o de herramientas de software propias.
• Soporte a otras áreas de la empresa (desde cambiar el tóner de una impresora hasta gestionar la renovación de licencias de una herramienta de software cualquiera), gestión de incidencias y problemas del ámbito interno de IT.
• Colaboración en la redacción de ofertas (enfoque técnico, estimaciones, planificaciones…).
• Investigación de nuevas herramientas y tecnologías, pruebas de concepto y similares.

Y otro largo, larguísimo etcétera que nos lleva a una conclusión: agilizar un departamento de IT no consiste simplemente en “escalar Scrum”, ni mucho menos: el reto consiste en orquestar todo este trabajo, y para eso la mejor idea (y no simplemente la mejor práctica) es escalar el uso de los tableros de trabajo.

Tableros a nivel de departamento

Tenemos que preguntarnos de qué debemos preocuparnos y ocuparnos para gestionar todo el trabajo (al fin y al cabo, tareas para personas), y reflejarlo en un tablero para la operativa diaria:

• A qué petición o cambio se refiere la tarea: si es un evolutivo, una incidencia, una petición… Debemos desgranar cada petición en tareas concretas que sean asignables a personas: escribir un documento, desarrollar una transacción en BBDD, ejecutar algún tipo de prueba o desplegar código en algún entorno.
• Quién hace qué: qué persona se hace cargo de la tarea.
• Estado de avance de la tarea: por ejemplo, no es lo mismo que una funcionalidad web esté “desarrollándose” que esté “desarrollada”; si tenemos una columna en el tablero que llamamos “desarrollo”, ¿qué significa cuando la tarea está en dicha columna, que se está desarrollando o que está desarrollada? Esto puede ser importante para que la persona que haga las pruebas (por ejemplo) no coja una tarea que aún se está desarrollando… porque fallará, y es un desperdicio de tiempo.
• Tiempo estimado (normalmente, en horas).
• Tiempo incurrido (también en horas).
• Atascos: si la persona que tiene la tarea no sabe continuar con ella (el código no compila, o no pasa una prueba y no se sabe por qué, o se tiene una duda técnica que le detiene en su trabajo…), es una circunstancia que debe señalarse para recibir, cuanto antes, la ayuda de los compañeros.
• Dependencias con terceros: si una tarea se detiene porque depende de que otra empresa, otro departamento o queda a la espera de que un cliente haga algo, esto debe señalarse cuanto antes para que un facilitador empuje y consiga la resolución del impedimento lo antes posible.
• Dependencias entre tareas: si, por ejemplo, para hacer un desarrollo es necesario que antes se haya hecho un diseño, este orden o dependencia técnica tiene que ser respetado (y por lo tanto conocido, y nuestro tablero tiene que proponer realizar las tareas en el orden en el que tiene sentido hacerlas).
• Dependencias entre peticiones: si una incidencia impide entregar una versión de un producto, o impide solucionar o entregar la solución de otra incidencia, tenemos que plasmarlo y ejecutar el trabajo en el orden más coherente para evitar tiempos de espera más tarde.
• Tipo de la tarea: según si es de documentación, análisis, desarrollo, pruebas… puede recaer en personas concretas, por tanto, puede ser relevante señalarlo para que la distribución del trabajo se aplique de forma natural a los perfiles disponibles.
• Prioridad: si queremos distinguir las incidencias urgentes, por ejemplo.
• Contrato, servicio, o proyecto se trata: ¿de qué cliente, servicio, entrega, hito o petición es la tarea que alguien está haciendo? Si no lo sabemos, no estaremos monitorizando el cumplimiento de fechas de entrega de proyectos o de acuerdos de niveles de servicio de cada contrato.
• … Y cualquier otra que al departamento IT le pueda parecer importante.

Pues una vez que tenemos claras cuáles son todas estas dimensiones que debemos representar en un tablero de trabajo, se trata de preguntarnos “¿Por qué no lo aplicamos al departamento entero?” Es decir, representarlo en UN ÚNICO tablero, no en tableros separados; las herramientas de software para la gestión del trabajo como Jira, Redmine, TargetProcess, Asana, Monday… todas ellas permiten configurar tableros con todas estas dimensiones que hemos señalado. No se trata de construir un sólo “tablero enorme” con cientos de tarjetas moviéndose por el mismo viéndolas todas a la vez, eso se convertiría en una “sopa de tarjetas” y en un caos, pero precisamente estas herramientas tienen posibilidades de visualización del tipo:

• Ver todos los atascos (pero sólo los atascos) de todo el departamento.
• Ver todas las incidencias de cierta prioridad.
• Ver el trabajo de sólo un conjunto de personas.
• Ver el trabajo de una serie de proyectos o servicios a la vez, pero no el de otros.
• Etc (las combinaciones de visualización dependen de cada herramienta y tienden a ser casi infinitas).

Es decir, podemos responder a preguntas del tipo “¿Cuántas incidencias urgentes que haya que resolver en menos de 24h tenemos sin asignar a nadie del departamento IT, sean del contrato o proyecto que sean?”

Pues disponer de esta información para conseguir la respuesta al momento, utilizando tableros, es una de las dos cosas que necesitamos para escalar esta gestión ágil al nivel del departamento completo.

Nos falta igualar la duración de las iteraciones de todas las iniciativas que avanzan en paralelo.

Iteraciones de igual duración

Teniendo en mente que buscamos poder responder cuestiones de gestión a nivel departamento utilizando tableros (que pasa a ser “tablero” en singular, si consideramos como tal la unión de todos los tableros de todas las iniciativas que avanzan en paralelo), entonces es necesario que el ámbito temporal de todos ellos sea el mismo, veamos qué significa esto.

Supongamos que un proyecto (llamémosle “proyecto A”) trabaja en iteraciones de una semana, y otro proyecto en iteraciones de tres semanas (llamémosle “proyecto B”). Esto no es ni bueno ni malo, porque el roadmap de cada proyecto se habrá diseñado así atendiendo a lo más conveniente de cada contrato (de cada cliente). Vamos a suponer que las iteraciones empiezan los lunes en ambos casos (cada viernes termina una iteración en el proyecto A, y cada 3 viernes terminará una iteración del proyecto B).

Supongamos que un día cualquiera de trabajo en el departamento IT, por ejemplo, un miércoles, tenemos que decidir si una persona dedica su jornada al proyecto A, o al B. Y que el proyecto B tiene una tarea o una acción que es una dependencia con otra de este mismo proyecto B, y que por tanto la paraliza.

Podemos estar en la semana 1, la semana 2 o la semana 3 de la iteración larga del proyecto B, pero en todo caso en menos de dos días el proyecto A tiene una entrega de final de iteración (eso es seguro), así que es del todo probable que esta persona se ponga a trabajar en el proyecto A… cuando esto puede estar generando un gran desperdicio de tiempo en el proyecto B, que no resalta como algo importante porque puede que nos queden aún dos semanas y media de iteración. Pero es un retraso que tendrá un impacto fuerte que aún nos cuesta ver. Y si esto lo multiplicamos por 30 personas que trabajan en 6 u 8 proyectos a la vez… la cuestión es dolorosa y muy relevante.

Estas ineficiencias se repiten una y otra vez en departamentos de IT de todo tipo de empresas, y se solventa haciendo que todos los roadmaps de todas las iniciativas empiecen y terminen sus iteraciones al mismo tiempo.

En este caso, el proyecto A no tiene problema puesto que de partida cuenta con la iteración más corta, que es una semana. El roadmap del proyecto B mantendrá sus entregas cada 3 semanas (marcando esto como las releases sucesivas), pero también define iteraciones de una semana (siendo previsible que sólo una de cada 3 semanas genere una release o producto mínimo viable).

Haciéndolo así, el proyecto B se obliga a definir resultados parciales, conseguibles, cada semana, aunque estos resultados parciales no terminen como entregas a clientes. Pero son puntos de control que nos proponemos cumplir, al igual que lo son los del proyecto A.

El proyecto A se parece a un marco Scrum, pero el proyecto B no (porque no genera una entrega en cada iteración), lo cual no es ni bueno ni malo, sino que resulta necesario.

Si esta estrategia la aplicamos a todos los proyectos (y servicios) de todo el departamento, tendremos un ritmo de trabajo a nivel de conjunto que paraleliza el avance de todas las iniciativas, con puntos de control en el tiempo constantes y estables a nivel de departamento, siendo más fácil decidir a qué iniciativa asignar un recurso o cuál puede permitirse un tiempo de espera, puesto que el momento de control de todas ellas se sitúa en el mismo punto.

Por eso, aplicar el enfoque ágil a escala departamental no consiste en “escalar Scrum”, eso es sólo una solución para ejecutar un proyecto más o menos grande.

Trenes de trabajo

Si unimos la idea de un tablero conjunto, e iteraciones de la misma duración… pensemos que cada proyecto o servicio es un carril de una carretera; y que el final de las iteraciones son los puntos kilométricos, todos a la misma distancia; además queremos tardar lo mismo entre uno y el siguiente, es decir, buscamos iteraciones de una semana en todos ellos como decíamos en el punto anterior, porque así podemos ser predecibles: sabemos que cada corto período de tiempo vamos a tener resultados, pocos o muchos, pero vamos a tenerlos, y en todas las iniciativas a la vez (si asignamos personas en todas ellas).

Pues bien, esto es lo que denominamos un “tren de trabajo”: un conjunto de personas que se dedican a diferentes iniciativas, tratándolas todas al mismo tiempo en periodos de tiempo (iteraciones) iguales en todas ellas; es como si el departamento fuera una orquesta completa, cada proyecto un instrumento diferente, pero todos ellos tocan al mismo compás (o la música no suena bien). Y el tablero conjunto es lo que ve el director de orquesta…

Y esta idea escala fácilmente a departamentos IT de gran tamaño: un tren de trabajo de 40 ó 50 personas, puede crecer e incorporar nuevos contratos (nuevos roadmaps de trabajo) siempre y cuando sus iteraciones sean de la misma duración, e incorporemos sus tableros de trabajo (con retrasos, estimaciones, asignaciones de trabajo, etc.) al conjunto para tener esa visualización a nivel global siempre que la necesitemos.

Tanto es así, que marcos de escalado ágil como SAFe propone ya una serie de trenes de trabajo por defecto con nombres y funciones concretas, roles para su organización y gestión, propuestas para orientar en el crecimiento hacia este modelo… porque estamos hablando incluso de agilizar una empresa entera: si podemos montar trenes de trabajo para IT, ¿por qué no incorporar más trenes de trabajo para la labor de negocio, de marketing, de innovación…?

En próximos artículos profundizaremos en este camino de agilización corporativa en el contexto de transformación digital.