Retos de la agilidad en empresas grandes

Son las 20:13, sonido en el móvil y el correspondiente mensaje de WhatsApp. Es de Marta. Ella trabaja con el rol de responsable de proyectos y, entre varios mensajes, quiere compartir conmigo que, después de meses de trabajo, el comité de dirección de su empresa, una de las que en el sector llamaríamos “grandes”, ha cancelado lo que allí llamaban la “transformación ágil” de su proyecto.

Marta me comenta que la dirección de su empresa ve demasiado grandes los cambios organizativos, estructurales, contractuales, etc., necesarios para poder acometer, realmente, el cambio que requiere trabajar de manera ágil.

La frustración y pérdida de ilusión de Marta queda reflejada en una frase: “Realmente nadie dirá públicamente que no trabajamos de manera ágil y esto acabará en un Scrum con peros” (argot que usamos en el sector para denominar a esos proyectos que sólo usan partes de la agilidad, por ejemplo, “usamos Scrum pero... el Testing lo hace un equipo externo”).

El caso de Marta representa uno de tantos, pasada la moda y novedad de la agilidad en las empresas grandes viene ponerse con la transformación y ahí aparecen los verdaderos retos.

Y el caso de Marta contrasta con otro gran grupo de empresas grandes con las que hoy me encuentro, aquellas que sí, con esfuerzo, tiempo y constancia, han logrado, o están logrando, cambiar obsoletas maneras de trabajar por aquellas que hoy llamamos ágiles. Lo que augura un presente - futuro de dos velocidades: empresas grandes cuyos negocios de base tecnológica trabajan de manera mucho más eficiente (llámalo ágil) y empresas (o partes de ellas) que no pudieron salir de aquellas viejas y tradicionales maneras de trabajar.

¿Pero por qué? ¿Cuáles son esos retos que hacen que para algunos sea tan complejo el cambio? Enumerar todos ellos sería demasiado extenso para un post, pero déjame que te resalte los que en mi experiencia son los más comunes y complejos, y que sirva este como un primer post de varios en los que iremos profundizando en algunos de los siguientes retos.

Las dimensiones del desarrollo

Decía McConnell, en su “Rapid Development” (cuando aún la palabra ágil no existía como tal el mundo de la tecnología), el que para mí, aun a pesar de sus años, es uno de los mejores libros sobre gestión en tecnología, que lo “sano” que es un proyecto software se basa en cuatro dimensiones: personas, procesos, productos y tecnología. Vamos a ir repasado los mayores retos hoy de la agilidad en empresas grandes, en función de las tres primeras dimensiones de McConnell.

Personas

Aunque parte del sector no lo viera así durante años, las personas y equipos son, sin duda, lo más determinante. Objetivo del tradicional “Peopleware”. Como decía Cockburn, las personas son el componente no lineal de primer orden en el desarrollo software. Decía McConnell que las personas son lo que tiene más potencial para recortar el tiempo de un proyecto. Y decía Glass, que no hay que olvidar que las personas son las que hacen el software. O que “Las personas son la clave del éxito”, que dijera Davis.

Decenas de aspectos podríamos mencionar aquí en lo que refiere a personas, equipos, en empresas grandes trabajando de manera ágil, desde el talento, a la motivación, pasando hasta por el efecto del entorno. Pero hoy, y aquí, me voy a centrar en tres, aquellas que vienen de que un equipo ágil es multifuncional, auto-organizado y pequeño.

Un equipo multifuncional es aquel que posee todas las competencias necesarias para lograr completar el trabajo, sin depender (o dependiendo mínimamente) de otros equipos, áreas, o roles fuera del mismo. Dicho lo anterior, este es uno de los mayores retos en muchas empresas grandes, que se han estructurado desde hace años en base a modelos de externalización. Caso muy representativo aquí es el de Testing, en muchos lugares externalizado, lo que impide a los equipos ser realmente multifuncionales.

Un equipo auto-organizado, como explica Appleton, es un equipo dirigido y organizado por sus propios miembros, para alcanzar los objetivos especificados por la gerencia. Esto conlleva a jerarquías más planas, a revisar figuras tradicionales, como la del jefe de proyectos, etc. Un reto organizativo en toda regla.

Y, de manera general, en agilidad, se sigue la premisa, bastante antigua, por cierto (ya se citaba en el famoso “mítico hombre mes” de Brooks, 1975) de que los equipos grandes son menos productivos que los pequeños (de ahí que los equipos en Scrum sean de entre 5 y 9 personas). Otro reto organizativo si venimos de trabajar en equipos grandes y muy jerarquizados.

Procesos

“Frameworks” como Scrum o eXtreme Programming son hoy ya bastante conocidos en el sector. Pero tener un equipo y que este trabaje con sus correspondientes Sprints, su Product Backlog, etc., no es lo mismo que tener muchos equipos, tener coordinar diferentes Sprints, integrar, tener muchos Product Backlog, muchos Product Owner, muchos Scrum Master, etc.

De nuevo, aquí podríamos enumerar decenas de retos, pero déjame que te resalte, más que nada porque hoy suele ser tema común de conversación en estos ámbitos, el reto de la gestión de varios Product Backlog.

Un problema frecuente en empresas grandes es el miedo a perder la visión global, de ahí que los diferentes “frameworks” que proponen como llevar la agilidad a empresas grandes (Less, DAD, SAFe, etc.) afrontan, cada uno desde su visión, entre otros, lo que algunos llaman gestión ágil del portfolio, y ese salto desde orientar la gestión en base a proyectos para orientarla en base a equipos.

Producto

“Clean Code”, calidad software, deuda técnica, estrategia de control de versiones, Testing ágil, la lista completa sería larga, y estos son sólo algunos de muchos términos que hoy podemos asociar a esta dimensión, tratados todos ellos, de una manera u otra, cuando hablamos de agilidad.

Para cualquiera que haya trabajado en desarrollo aquí no hay ninguna duda: la calidad del código, del diseño, de sus pruebas, el grado de malas y buenas prácticas, etc., puede bloquear cualquier iniciativa de mejora en cualquiera de las anteriores dos dimensiones. Más si queremos ir sacando productos potencialmente entregables en iteraciones muy cortas.

Si la deuda técnica (el “interés” que hay que ir pagando cuando se introduce una mala práctica en el software) nos come... la mantenibilidad cada vez será más compleja y será muy difícil aguantar en ritmo de los Sprint.

Si te pasas hoy por alguna empresa de las llamadas grandes, intentando trabajar de manera ágil, verás como, sin duda, este es uno de los mayores retos, que en muchos casos es altamente complejo, más en empresas grandes, que suelen llevar en sus espaldas muchos años de desarrollo, con aplicaciones muy grandes... y mucho código “legacy”.

Rehacer de cero una aplicación “legacy” grande, con años de desarrollo, es, por muchas razones, algo irreal la mayoría de ocasiones, por lo que las actuales iniciativas que hoy nos encontramos (que darían para mucho escribir) pasan por aislar partes y buscar aquellos puntos concretos sobre los que una refactorización añade más retorno de inversión.

Futuro...

En aquel 2001 en el que participé por primera vez en un proyecto ágil... ninguno de los que nos dedicamos a ello pensábamos que con los años la agilidad iba a llegar hasta la alta dirección de muchas empresas de las que llamamos “grandes”.

Más allá de que esto haya podido ocurrir por cuestiones de moda, lo que nos encontramos hoy es una necesidad real de cambio, cambio para poder sobrevivir en un entorno cada vez más competitivo, que se basa en la tecnología, que necesita y depende del software, de acelerar el "time to market" cada vez más.

Pero nadie dijo que fuera fácil, y escalar a la agilidad hoy se traduce en un ámplio conjunto de retos. Tratar todos ellos sería demasiado extenso para un post... y probablemente este será el primero de varios, en los que iremos recorriendo varios de estos aspectos.

Nadie dijo que fuera fácil... ni imposible.