Es típico emplear el término “escalado Agile” para referirse al problema de aumentar el número de equipos trabajando en un modo “Agile”. Curiosamente lo plantean como si se tratase de pasar de una “foto” del modelo de trabajo actual (complicada y no-ágil) hacia otra “foto” del modelo ideal (también complicada, aunque presuntamente ágil). En esta serie de artículos voy a tratar de explicar por qué este enfoque es, en mi opinión, equivocado y cómo abordar el problema de “escalar Agile” de una manera más orgánica.
DISCLAIMER: Con el paso de los años, y durante el proceso de escribir este artículo, me he dado cuenta de que había mucho que explicar. He intentado resumir todo lo que he podido, pero aun así, no quería dejar a medio desarrollar algunas ideas que me parecen esenciales. Así que han salido varios artículos (y bastante largos). Espero que al menos te merezca la pena el tiempo de lectura.
Seguramente habrás visto la típica foto de SAFe (probablemente el marco de escalado Agile más popular). La imagen de más abajo es la configuración más simple que aparece en la última versión (además hay una configuración Large Solution, una Portfolio, y una Full… ahí lo dejo).
Este enfoque, el de pasar de un modelo organizativo actual a otro modelo ideal, incurre en dos errores de base:
- No existe un modelo ideal al que podamos llamar “organización Agile” porque siempre dependerá de cada organización en particular; y es que no existe ninguna organización (grande) que podamos describir como homogénea. Así, podemos empezar a “caminar” hacia un modelo de referencia, pero siempre y cuando sepamos cuándo (y dónde) debemos despegarnos de él.
- Tampoco existe un modelo final para el que podamos planificar acciones que nos permitan “ejecutar” la transición pues una “organización Agile”, por definición, es una organización en constante adaptación.
Por tanto, debemos asumir que, en nuestro camino de descubrimiento de la “organización Agile” que funcione para nosotros, estaremos pasando de un estado intermedio a otro, cada vez menos imperfectos a medida que la organización va aprendiendo, pero siempre intermedios. Por ello es importante entender a qué debemos prestar atención en ese camino de descubrimiento.
Hace varios años di una charla improvisada acerca de cómo podemos adaptar la manera de trabajar de nuestros equipos ágiles a medida que la organización va creciendo. La titulé “Escalar Agile sin frameworks” y la dejé en Slideshare, sin más. Que yo recuerde, nunca la he propuesto a ninguna conferencia: me parecía bastante básica. Sin embargo, cada vez más se deslizan referencias a esa presentación en mis conversaciones; los clientes piden aplicar Agile a gran escala, pero muchos de los actores no dominan los fundamentos y, seguramente por ello, les parece complicado visualizar cómo pueden transicionar desde su organización actual hacia una en la que el trabajo se haga de una manera más fluida. De ahí que tiendan a buscar soluciones “enlatadas” como SAFe u otros frameworks de escalado. Es como si quisieran multiplicar sin aún dominar la suma. En este artículo voy a desarrollar esa presentación.
¿Por qué debemos escalar Agile?
Lo más importante es recordar siempre que la organización crece (escala) porque las necesidades del negocio así lo requieren. A veces son necesidades sobrevenidas (“ya ha sucedido”) y otras veces son necesidades estratégicas (“nos preparamos para lo que pueda suceder”), pero en esencia son las mismas fuerzas y restricciones a tener en cuenta. Vamos a verlo muy despacio, para entender todos los matices.
Te invito a imaginar una empresa muy sencilla y que me acompañes mientras crece. Seguiremos varias lineas del tiempo, así que espero que no te pierdas. En general, lo que vamos a hacer es ver cómo crece la empresa, primero sin atender a restricciones de ningún tipo (es el objeto de este primer artículo), luego veremos cómo crece si el único equipo va trabajando cada vez en más productos simultáneamente, y finalmente veremos cómo un único producto va haciéndose cada vez más grande y requiere de más y más equipos que trabajen en él. Cuando hayamos viajado por esas tres lineas del tiempo, creo que podremos hacer una interesante reflexión sobre cómo podemos ir escalando sin necesidad de frameworks, o sí. 😉
¡Es que yo no tengo productos! Bueno, si tienes proyectos, también te vale esta explicación, aunque seguramente tendremos que ver muchos matices. Por otro lado, si lo que tienes es un servicio, es posible que te chirríen muchas más cosas, pero intentaré que también te sirva la explicación. De todos modos, sea cual sea tu caso, todo el feedback que quieras compartir será bienvenido (allí abajo, en los comentarios, mucho mejor para que nos beneficiemos más gente del debate).
1 equipo y 1 producto
Cuando sólo tenemos un equipo y un producto, una posible configuración Agile sería la del dibujo. Es, más o menos, la que te explicarán en cualquier formación sobre Scrum (salvo el “detalle” de que a mí no me gusta dibujar al ScrumMaster por razones que no vienen al caso pero sobre las que ya he escrito anteriormente). 😉
Aunque creas que ya te la sabes, te aconsejo seguir leyendo porque creo que es importante tener un vocabulario común antes de comenzar a construir con estas piezas y porque voy a ir deslizando consideraciones a las que luego iré haciendo referencia y que conviene que hayamos visto antes de continuar.
Procesos, roles y artefactos
Verás algunas similitudes y diferencias con la Guía de Scrum. Permíteme que te las explique.
Es posible que te llame la atención que haya separado el rol de Product Owner del Equipo de Desarrollo a pesar de que, evidentemente, las personas que ejercen ese rol forman parte del Equipo. Además, Product Owner es un rol que no es mencionado en el Agile Manifesto sino que es introducido por Scrum. Igual me ha ocurrido con el Product Backlog, que tampoco es un artefacto mencionado en el Manifiesto. Sin embargo, en esta serie de artículos necesito mencionar prácticas concretas y, de esta manera, puedo hacer referencia, tanto en los gráficos como en las explicaciones, a las funciones que una o más personas del equipo deberán hacer en relación a la planificación del trabajo.
Éstas son mis definiciones. Creo que es importante que las entiendas tal y como las defino porque de lo contrario es posible que puedas malinterpretar algunos de los gráficos y explicaciones más adelante:
- Pila de producto (Product Backlog), es el plan de trabajo, iterativo e incremental, con el que el equipo prioriza el desarrollo del producto. El artefacto es lo de menos, da igual si se trata de una Excel o un User Story Map, pero lo relevante aquí es que el equipo tiene el control total sobre él.
- Equipo de desarrollo (Team), responsable de construir incrementos de software funcionando (Product Increment) y ponerlos a disposición de los usuarios para incorporar su feedback en el plan de trabajo. Idealmente debería estar formado por personas que, entre todos, pudieran desarrollar cualquier funcionalidad presente en el product backlog, pero a veces podemos necesitar la ayuda de otros. A eso lo llamaremos dependencias.
- Dueño de producto (Product Owner), persona o personas que asumen la responsabilidad de incorporar las necesidades de los usuarios al Product Backlog. Eso no quiere decir que sea la única persona que pueda opinar sobre ello. Y ojo, porque en el Agile Manifesto nada se dice de que tenga que existir este rol. De hecho, lo que dice es “Los responsables de negocio y los desarrolladores trabajamos juntos de forma cotidiana durante todo el proyecto”. De alguna manera, esos “responsables de negocio” vienen a ser, en nuestra configuración sencilla, el Product Owner.
- Ciclos, iteraciones, sprints… El nombre es lo de menos, aunque yo prefiero hablar de iteraciones. Tampoco quiero entrar en un debate sobre si Agile/Scrum consiste en trabajar por lotes o no, porque creo que lo importante es que busquemos los beneficios de las entregas frecuentes. Como dice el Agile Manifesto: “Entregamos software funcional frecuentemente, entre dos semanas y dos meses [ya hablaremos otro día sobre la duración de las iteraciones], con preferencia al periodo de tiempo más corto posible”. Nada dice de iteraciones ni de Sprint Goals, ni Sprint Planning, ni nada por el estilo, pero en la práctica observamos que son técnicas que ayudan a que el equipo tenga foco durante ese periodo de tiempo y le sirve de recordatorio para entregar incrementos de software funcionando, mantener un ritmo sostenible y parar de vez en cuando a reflexionar.
- Visualizar el trabajo en curso diariamente y decidir sobre ello. Ésta es otra buena práctica que tampoco aparece en el Manifiesto pero que resulta extremadamente útil. En el gráfico lo represento mediante un radiador de información (un tablero) y un ciclo diario (normalmente una reunión diaria en la que todo el equipo decide sobre el plan de trabajo).
Todas éstas son definiciones centradas en procesos, roles y artefactos, y son importantes porque permiten a todos los actores acordar mejoras sobre la manera de trabajar, pero no debemos minusvalorar aspectos como las relaciones entre las personas y con el entorno del equipo. Al fin y al cabo…
(…) hemos aprendido a valorar:
Individuos e interacciones sobre procesos y herramientas
(…)
Agile Manifesto
Vamos a ver esto en detalle porque nos ayudará a entender más adelante todo lo que debemos tener en cuenta cuando escalamos la organización.
Relaciones entre las personas del equipo
Hay diversas perspectivas para fijarnos en las relaciones que se producen en el contexto de un equipo. Vamos a ver aquellas que, en mi experiencia, más afectan (o se ven afectadas) cuando llevamos Agile a mayor número de equipos en una organización o cuando aumentamos el tamaño de la misma.
Tamaño máximo del equipo
De la propia Guía de Scrum: “Más de 9 miembros requiere demasiado trabajo de coordinación”. Creo que este gráfico vale más que mil palabras, aunque volveré a este asunto en breve para tratar el tamaño mínimo.
Observa que para que un equipo sea eficaz estamos teniendo en cuenta cómo se comunican sus individuos. A mayor número de individuos que deben estar actualizados sobre las decisiones, más costoso resulta que sus interacciones sean realmente eficaces y que, como consecuencia, también lo sea el resultado de su trabajo en conjunto.
Para minimizar estos costes, los equipos Agile han ido desarrollando estrategias como:
- reuniones periódicas y con objetivos claros (como la diaria, retrospectivas, etc), que permiten que todos los miembros del equipo organicen el resto de sus actividades alrededor de una cadencia concreta, estable y acordada previamente, evitando los típicos trabajos de hacer cuadrar las agendas de todos,
- acuerdos de trabajo explícitos (como los horarios de las reuniones), que permiten a todos los miembros del equipo actuar, y esperar que otros actúen, de una manera coordinada sin necesidad de acordarlo para cada acción,
- radiadores de información (como los tableros de tareas de Scrum o Kanban), que permiten reducir el tiempo dedicado a informar sobre el estado y avance de las tareas,
- trabajar en espacios colocalizados para simplificar las interacciones entre ellos.
Todas estas prácticas, en general, funcionan bien en el contexto de un equipo de no más de 9 individuos, pero si lo llevamos a equipos que deben colaborar con otros equipos (lo que llamamos escalar) parece observarse un límite en el número de Dunbar (150 personas). Ya veremos más adelante cómo podemos manejar esto.
Equipo multidisciplinar
Cuando más arriba explicaba el concepto de Equipo Agile, anunciaba que debería estar formado por individuos que, entre todos, dispongan de los conocimientos, experiencia y habilidades necesarias para desarrollar cualquier funcionalidad que vayan a tener en su product backlog, es decir, debería ser un equipo multidisciplinar.
Entendamos por disciplina el conocimiento, la experiencia, las habilidades y algo de lo que se habla poco, la estrategia para cuidar todo lo anterior. Ya veremos cómo, a medida que vayamos escalando, es posible que necesitemos mecanismos para coordinar y aprender las distintas disciplinas. Pero de momento, en nuestro escenario sencillo de un único equipo, lo que nos interesa es ver cómo se relacionan los miembros de un equipo multidisciplinar.
Por un lado tenemos personas que ejercen roles muy especializados y a tiempo completo, como por ejemplo un programador de front-end o un especialista en experiencia de usuario (UX). Lo que pasa es que a veces estos roles no están tan bien mapeados con individuos concretos y una misma persona ejerce más de un rol. Por ejemplo, un programador de front-end que también “hace UX” o un programador de back-end que también hace de administrador de sistemas. Es cada proyecto (o producto) el que va a requerir las disciplinas necesarias y es la disponibilidad de profesionales (y el coste de los mismos) la que va a definir la configuración de cada equipo. En cualquier caso, Agile fomenta que los equipos sean multidisciplinares por una simple cuestión de eficiencia. Si tenemos todas las disciplinas en el equipo, no tendremos que esperar a nadie para poder hacer ningún desarrollo, es decir, buscamos minimizar las dependencias para así aumentar nuestra velocidad de desarrollo.
Como en todos los negocios, podemos optar por optimizar el uso de nuestros recursos u optimizar el flujo de valor aportado. Si hacemos lo primero, probablemente tengamos equipos pequeños, con más dependencias de las deseables, y con problemas para sacar trabajo adelante con fluidez cada vez que alguno de sus miembros enferma o está de vacaciones. En el otro caso lo que tendremos serán equipos más grandes, con redundancias en los perfiles más críticos, en los que es fácil ver a profesionales de diferentes disciplinas trabajando simultáneamente en la misma pieza de software, consiguiendo así elevar la calidad de los resultados.
Equipo auto-organizado
Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados.
Principio núm. 11 del Agile Manifesto
Esto es algo esencial en los equipos Agile y piedra angular del agilismo, entendido como cultura Agile. Sin auto-organización no hay equipos ágiles porque sólo podemos resolver problemas complejos si cada individuo comparte el propósito y reglas de trabajo del equipo a la vez que tienen la libertad de tomar sus propias decisiones.
Más adelante veremos las relaciones entre el equipo y su entorno, pero de momento vamos a centrarnos en cómo un grupo de individuos son capaces de auto-organizarse. Para ello hablamos de prácticas que, por alguna razón, en el mundo del desarrollo de software se ha tendido a olvidar: las llamadas soft-skills (o “habilidades blandas”). Dar o recibir una opinión con un estilo de comunicación no agresivo, empatía, escucha activa, estilos de liderazgo adaptados a las situaciones, distinguir entre responsabilidad sobre la ejecución de una tarea o sobre el resultado de la misma… quizás todas se puedan reducir a una mucha más ideológica y que cada cuál le dará un nombre: amor, generosidad, pertenencia, respeto… Lo importante aquí es que seamos conscientes que en el corazón de un verdadero equipo Agile está este concepto y que sin él no hay auto-organización posible.
Gestionar el trabajo, no a las personas
Íntimamente relacionada con la auto-organización está la gestión de la personas. Seguramente por influencia de los métodos de gestión del trabajo en entornos de manufactura tradicionales, en las empresas nos hemos acostumbrado a optimizar las tareas que hacen las personas y el tiempo que dedican a ellas. Para ello se han diseñado elaborados métodos de gestión y de incentivos de lo más variados. No voy a entrar a discutir sobre esto, pero creo que es obvio que el factor humano en el trabajo del conocimiento es muy importante y que no es tan “industrializable” como el que se puede pautar en una cadena de montaje. En ese sentido, Agile apenas insinúa que nos centremos en medir el progreso de nuestro trabajo de la forma más objetiva posible, el software funcionando, y quizás porque su mensaje no es más contundente, es demasiado frecuente ver que la metodología termina siendo más un método de control que una ayuda para hacer avanzar al equipo en sacar su trabajo adelante.
Seguramente conscientes de esa debilidad, en el método Kanban (que no es exactamente Agile) hacen hincapié en que debemos gestionar el trabajo y dejar que la gente se auto-organice a su alrededor. Creo que este artículo lo explica bastante bien.
Visualizar el trabajo en curso
En la misma línea de gestionar el trabajo en vez de gestionar a las personas, Scrum y Kanban fomentan la visualización del trabajo en curso. Agile no dice nada sobre esto, pero una de las maneras más eficaces de optimizar el trabajo de un equipo es emplear radiadores de información (tableros, señales, semáforos, cuadros de mando, gráficas, etc). Con significados previamente acordados, todo el equipo (e incluso gente ajena al mismo) puede conocer el estado del trabajo y actuar en consecuencia. Incluso de manera preventiva.
Visualizar el trabajo también ayuda a entender cómo trabajamos realmente y a optimizar nuestros propios procesos.
Mentalidad hacia la mejora continua
Nada de esto funciona si en el equipo no hay una mentalidad colectiva de mejora continua. Fíjate que no digo que cada individuo, por separado, quiera mejorar, sino que hablo del equipo. En mi experiencia, sólo el equipo como unidad puede ser verdaderamente eficaz en su mejora continua.
“Lo que hace que algunas tribus sean más efectivas que otras es la cultura.”
David Logan en “Tribal Leadership”
El concepto de mejora continua ayuda muchísimo a crear esa cultura. Consiste en un propósito fuerte y claro y permite al grupo distinguir rápidamente si algún miembro del mismo está alineado o no con este objetivo.
Creo que todo agilista coincidirá conmigo en que, si hay alguna práctica que adoptar en un equipo que pretende ser ágil es la retrospectiva (o cualquier variedad de la misma). Inspeccionar lo que ha sucedido en la última iteración y adaptar los acuerdos de trabajo es la mejor manera para comenzar a construir una cultura de mejora continua. Luego, en cada iteración, reservar un tiempo para reflexionar y preguntarse (como mínimo) sobre qué ha ido bien para potenciarlo y qué se podía haber mejorado.
Ritmo sostenible
Y por último, y no por ello menos importante, una idea que trato de dejar siempre clarísima a todos los equipos con los que trabajo porque es esencial, no sólo para su trabajo como equipo sino también si luego queremos escalar las prácticas. Me refiero al ritmo sostenible. Como ya escribí recientemente sobre ello, no me extenderé aquí más. Pero insisto en que es una de las ideas más poderosas que deben estar presentes en un equipo ágil.
Este artículo ya es muy largo, así que dejaremos para el siguiente las relaciones entre el equipo y su entorno. Sin embargo, no quiero acabar esta serie de recomendaciones sobre cómo veo yo que debe ser y comportarse un equipo ágil sin incluir esta excelente charla de Carlos Buenosvinos.
LA FOTO: Una bonita imagen que he descargado de Unsplash para hacer énfasis de que “escalar” es sinónimo de “multiplicar” y, bueno, de paso hacer el chiste con la escalera. Ya sabes, escalar… escalera… Perdón. 🙂
Photo by @gmalhotra?utm_source=unsplash&utm_medium=referral&utm_content=creditCopyText">Gayatri Malhotra on Unsplash