Retos de la agilidad en empresas grandes

Son las 20:13, sonido en el móvil y el pertinente mensaje de WhatsApp. Es de Marta. Ella trabaja con el rol de responsable de proyectos y, entre múltiples mensajes, desea compartir conmigo que, tras meses de trabajo, el comité de dirección de su empresa, entre las que en el campo llamaríamos “grandes”, ha anulado 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, establecidos, etcétera, precisos para poder acometer, verdaderamente, el cambio que requiere trabajar ágilmente.

La frustración y pérdida de ilusión de Marta queda reflejada en una frase: “Realmente absolutamente nadie afirmará en público que no trabajamos de forma ágil y esto terminará en un Scrum con peros” (argot que utilizamos en el campo para llamar a esos proyectos que solo utilizan unas partes de la agilidad, por poner un ejemplo, “usamos Scrum mas… el Testing lo hace un equipo externo”).

“Realmente absolutamente nadie afirmará en público que no trabajamos ágilmente y esto terminará en un Scrum con peros”

El caso de Marta representa uno de tantos, pasada la moda y novedad de la agilidad en las compañías grandes viene ponerse con la transformación y ahí aparecen los auténticos desafíos.

Y el caso de Marta contrasta con otro gran conjunto de empresas grandes con las que el día de hoy me encuentro, aquellas que sí, con esmero, tiempo y perseverancia, han conseguido, o bien están consiguiendo, mudar obsoletas formas de trabajar por aquellas que el día de hoy llamamos diligentes. Lo que presagia un presente – futuro de 2 velocidades: empresas grandes cuyos negocios de base tecnológica trabajan de forma considerablemente más eficaz (llámalo diligente) y empresas (o bien partes de ellas) que no pudieron salir de aquellas viejas y tradicionales formas de trabajar.

¿Mas por qué razón? ¿Cuáles son esos desafíos que hacen que para ciertos sea tan complejo el cambio? Contar todos sería demasiado extenso para un artículo, mas permíteme que te resalte los que en mi experiencia son los más habituales y complejos, y que sirva este como un primer blog post de múltiples en los que vamos a ir ahondando en ciertos siguientes desafíos.

Las dimensiones del desarrollo

Afirmaba McConnell, en su “Rapid Development” (cuando todavía la palabra diligente no existía como tal el planeta de la tecnología), el que para mí, incluso pese a sus años, es entre los mejores libros sobre administración en tecnología, que lo “sano” que es un proyecto software se fundamenta en 4 dimensiones: personas, procesos, productos y tecnología. Iremos repasado los mayores desafíos el día de hoy de la agilidad en empresas grandes, en función de las 3 primeras dimensiones de McConnell.

Personas

Un equipo multifuncional es aquel que tiene todas y cada una de las competencias precisas para conseguir llenar el trabajo, sin depender (o bien dependiendo ligerísimamente) de otros equipos, áreas, o bien papeles fuera del mismo

Si bien una parte del ámbito no lo viese de esta forma a lo largo de años, las personas y equipos son, indudablemente, lo más determinante. Objetivo del tradicional “Peopleware”. Como afirmaba Cockburn, las personas son el componente no lineal de primera importancia en el desarrollo software. Afirmaba McConnell que las personas son lo que tiene más potencial para recortar el tiempo de un proyecto. Y afirmaba Glass, que no se debe olvidar que las personas son las que hacen el software. O bien que “Las personas son la clave del éxito”, que afirmara Davis.

Decenas y decenas de aspectos podríamos mentar acá en lo que refiere a personas, equipos, en empresas grandes trabajando de forma ágil, desde el talento, a la motivación, pasando hasta por el efecto del ambiente. Mas el día de hoy, y acá, me centraré en 3, aquellas que vienen de que un equipo diligente es multifuncional, coche-organizado y pequeño.

Un equipo multifuncional es aquel que tiene todas y cada una de las competencias precisas para conseguir llenar el trabajo, sin depender (o bien dependiendo ligerísimamente) de otros equipos, áreas, o bien papeles fuera del mismo. Dicho lo precedente, este es entre los mayores desafíos en muchas empresas grandes, que se han estructurado desde hace unos años basándonos en modelos de externalización. Caso muy representativo acá es el de Testing, en muchos lugares externalizado, lo que impide a los equipos ser verdaderamente multifuncionales.

Un equipo coche-organizado, como explica Appleton, es un equipo dirigido y organizado por sus miembros, para lograr los objetivos detallados por la gerencia. Esto acarrea a jerarquías más llanas, a comprobar figuras tradicionales, como la del jefe de proyectos, etcétera Un reto organizativo en toda regla.

Y, de forma general, en agilidad, se prosigue la premisa, bastante vieja, a propósito (ya se citaba en el conocido “mítico hombre mes” de Brooks, mil novecientos setenta y cinco) de que los equipos grandes son menos productivos que los pequeños (por eso los equipos en Scrum sean de entre cinco y nueve personas). Otro reto organizativo si venimos de trabajar en equipos grandes y muy jerarquizados.

Procesos

“Frameworks” como Scrum o bien eXtreme Programming son el día de hoy ya bastante conocidos en el campo. Mas tener un equipo y que este trabaje con sus pertinentes Sprints, su Product Backlog, etcétera, no es exactamente lo mismo que tener muchos equipos, tener regular diferentes Sprints, integrar, tener muchos Product Backlog, muchos Product Owner, muchos Scrum Master, etcétera

Nuevamente, acá podríamos contar decenas y decenas de desafíos, mas permíteme que te resalte, básicamente pues el día de hoy acostumbra a ser tema común de charla en estos campos, el reto de la administración de múltiples Product Backlog.

Un inconveniente usual en empresas grandes es el temor a perder la visión global, por eso los diferentes “frameworks” que plantean como llevar la agilidad a empresas grandes (Less, DAD, SAFe, etcétera) encaran, cada uno de ellos desde su visión, entre otros muchos, lo que ciertos llaman administración diligente del porfolio, y ese salto desde orientar la administración basándonos en proyectos para orientarla basándonos en equipos.

Producto

“Clean Code”, calidad software, deuda técnica, estrategia de control de versiones, Testing diligente, la lista completa sería larga, y estos son solo ciertos de muchos términos que el día de hoy podemos asociar a esta dimensión, tratados todos , de una forma o bien otra, cuando charlamos de agilidad.

Para cualquiera que haya trabajado en desarrollo acá no existe ninguna duda: la calidad del código, del diseño, de sus pruebas, el grado de malas y buenas prácticas, etcétera, puede bloquear cualquier iniciativa de mejora en una cualquiera de las precedentes 2 dimensiones. Más si deseamos ir sacando productos potencialmente entregables en iteraciones cortísimas.

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 va a ser más compleja y va a ser realmente difícil soportar en ritmo de los Esprint.

Si te pasas el día de hoy por alguna empresa de las llamadas grandes, procurando trabajar con agilidad, vas a ver como, indudablemente, este es entre los mayores desafíos, que habitualmente es enormemente complejo, más en empresas grandes, que acostumbran a 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 parte de ocasiones, con lo que las presentes ideas que el día de hoy nos hallamos (que darían para mucho redactar) pasan por aislar partes y buscar aquellos puntos específicos sobre los que una refactorización agrega más retorno de inversión.

Futuro…

En aquel dos mil uno en el que participé por vez primera en un proyecto diligente… ninguno de los que nos dedicamos a ello creíamos que con los años la agilidad iba a llegar hasta la alta dirección de muchas empresas de las que llamamos “grandes”.

Alén de que esto haya podido suceder por cuestiones de tendencia, lo que nos hallamos el día de hoy es una necesidad real de cambio, cambio para poder subsistir en un ambiente poco a poco más competitivo, que se fundamenta en la tecnología, que precisa y depende del software, de apresurar el time to market poco a poco más.

Mas absolutamente nadie afirmó que fuera simple, y escalar a la agilidad el día de hoy se traduce en un ámplio conjunto de desafíos. Tratar todos sería demasiado extenso para un artículo… y seguramente este va a ser el primero de múltiples, en los que vamos a ir recorriendo múltiples de estos aspectos.

Absolutamente nadie afirmó que fuera simple… ni imposible.

Asimismo te invitamos a

¿Cuántos años de más te echan por tus ojos?

Scrumblr, tablón Scrum para equipos de desarrolladores que trabajan a distancia

¿Es un pájaro? ¿es un aeroplano? ¡No! ¡Es Scrum!

– La nueva

Desafíos de la agilidad en empresas grandes

fue publicada originalmente en

turincon.net

por
Javier Garzas

.