Cómo logramos por fin que el desarrollo ágil funcionara

Muchos productos de software se benefician de un modelo de mejora continua y, para los equipos que trabajan en ellos, aumentar la agilidad es inevitable. Sin embargo, a pesar de docenas de libros sobre el tema, miles de entrenadores ansiosos y una multitud de vendedores de software que venden productos para «facilitar» el desarrollo ágil, muchas empresas se esfuerzan por llegar a un punto de verdadera agilidad (es decir, ser ágiles en lugar de «hacer agilidad»).

Hay muchas causas por las que no se adopta el desarrollo ágil, pero la que parece que se aborda con menos frecuencia es la forma en que las personas que se sienten cómodas en un mundo en cascada se adaptan a esta nueva forma de trabajar. Para quienes desempeñan algunas funciones (ingenieros de software, por ejemplo), la actividad principal no cambia: siguen escribiendo el código. Para otros, el camino no está tan despejado.

En miúltimo post, el hilo de comentarios estaba repleto de directores de proyectos y analistas de sistemas y negocios que se ponían en duda la validez de aumentar la agilidad del equipo. Lo que quedó claro en esas conversaciones es que las personas que desempeñan esas funciones tienden a tener dificultades para encontrar una base cómoda en un entorno ágil. Esta resistencia, que nace de la duda ante lo desconocido y de la creciente preocupación por la seguridad laboral, a menudo crea dinámicas de equipo que inhiben la verdadera agilidad multifuncional.

Esta inquietud también es válida para los diseñadores de software. Como diseñador que no solo ha pasado por transiciones ágiles como colaborador individual, sino que también ha dirigido a los equipos a través de ellas, me gustaría compartir cómo el campo del diseño se ha adaptado a la agilidad, demostrando en el proceso que nuestras preocupaciones originales eran falsas y creando un nuevo enfoque para hacer nuestro trabajo.

El proceso en cascada proporcionó a los diseñadores un período de tiempo aislado para hacer nuestro trabajo. La «fase de diseño», independientemente de lo larga o corta que fuera, nos dio la oportunidad de generar ideas, analizarlas y, después, crear otras nuevas hasta que se nos ocurrió lo que considerábamos el mejor diseño para el producto o la función que se estaba desarrollando.

Los que no eran diseñadores no participaron en el proceso y nos pareció bien. ¿Cómo contribuirían de todos modos? Éramos los «diseñadores». El proceso ágil nos obligó a salir de la fase de seguridad de la fase de diseño y a entrar en una nueva realidad tremendamente rápida en la que los directores de producto, los ingenieros de software y los especialistas en control de calidad participaban mucho más en el trabajo que creábamos. Las exigencias de los sprints de dos semanas nos obligaron a dividir nuestras «grandes ideas» en montones de pequeños pedazos que pudieran dedicarse a la «máquina de desarrollo» para garantizar que, Dios no lo quiera, ningún desarrollador se quedara de brazos cruzados.

Nos entró el pánico. «¡Esto no es diseño!» lloramos. Nuestro mejor trabajo no estaba siendo desarrollado y, por eso, nos sentíamos significativamente menos valiosos para la empresa. Todos los diseños que se implementaron parecían obras con una medalla de bronce. Llegamos a la conclusión de que no había lugar para un «buen» diseño en un entorno ágil.

Pero luego se apagó una luz.

En lugar de adaptar nuestro proceso para adaptarlo a la nueva realidad, habíamos intentado meter nuestros procesos antiguos en estas nuevas restricciones. No cabían. Y esa era la causa principal de nuestro problema. Tuvimos que replantearnos la forma en que diseñábamos el software. Nuestra experiencia, talento, técnicas y herramientas seguían siendo muy necesarios, pero la forma en que se ejecutaban, quién participaba en ellos y sus tiempos requerían cambios.

El valor que los diseñadores aportaron al proceso de creación se distribuyó ahora entre otras funciones del equipo. Al principio era una pastilla difícil de tragar. A medida que nuestros equipos crecían, nos dimos cuenta de que el diseño de software estaba evolucionando más allá de la simple disposición de los píxeles. La facilitación del diseño era ahora una parte mucho más importante de nuestro proceso, al igual que una comprensión más amplia de todos los demás elementos (rendimiento, estrategias de precios, contenido, etc.) que abarcaban la experiencia de usuario.

Si tiene dificultades para averiguar cuál es su lugar en un mundo ágil, le recomiendo que eche un vistazo a su proceso actual y vea cómo puede reconfigurar el valor que aporta para cumplir con las exigencias de los equipos ágiles. Además, mire más allá de su función y analice sus competencias. ¿Qué más puede aportar a su equipo más allá de lo que dicta su puesto? Los atributos que encuentre al hacer estos ejercicios facilitarán su transición y le ayudarán a encontrar una nueva base más ágil.