Ágil / Scrum y esquemas industriales
Al tocar el tema de los métodos ágiles para crear soluciones de negocio basadas en software, encuentro con demasiada frecuencia que sólo se habla de Scrum. Eso es un problema pues el recorrido histórico de los métodos sistemáticos para crear software es mucho más abundante comparado con tan sólo el recorrido histórico de Scrum.
Scrum es tan sólo uno entre muchos métodos ágiles: Scrum no tiene el monopolio de todo lo ágil — con ‘a’ minúscula.
Un patrón ágil es la retroalimentación y la autocrítica según el contexto propio: por eso tiene sentido revisar con detalle los modelos de equipo disponibles y las estructuras de grupo de trabajo para así analizar las opciones que más sentido tengan para nuestros esfuerzos.
Un anti-patrón “Ágil” — con ‘A’ mayúscula — sería usar la palabra “Ágil” como etiqueta o sinónimo de “bueno” sin elaborar el qué y cómo se aplicará en un contexto concreto. Suelo caer en ese anti-patrón cuando me expreso sólo en general, sin concretar suficiente.
Scrum ha ganado popularidad, pero dada la cantidad de veces que en su lugar se observa –en los hechos materiales– una usurpación por ScrumBut y FlaccidScrum, se confirma lo que sus propios autores indican: es simple de entender, pero es mucho muy difícil de implementar.
Además, no hay que olvidar las severas críticas a Scrum por parte de otros autores del Manifesto for Agile Software Development: «si no se tiene cuidado, Scrum resulta una manera muy rápida de crear un montón de lodo» —la traducción libre al español y la paráfrasis con eufemismos son mías.
La decisión de estructurar un grupo de trabajo, por ejemplo, como un Feature Team dependerá del tipo de objetivo que busque ese grupo de trabajo. Más al respecto de Feature Teams: aquí y aquí.
Si Scrum es simple de entender, ¿por qué es tan difícil de poner en la práctica?
Suelo decir, de manera excesivamente concisa, que se debe a que la cultura en donde ocurre el intento carece de los valores, principios, prácticas y hábitos profesionales del «esfuerzo intelectual cooperativo».
Por supuesto, en cada ambiente cultural hay valores, principios, prácticas y hábitos profesionales. El ambiente cultural convencional suele estar dominado por los valores, principios, prácticas y hábitos derivados de la cosmovisión profesional que suelo llamar «taylorismo posindustrial». Un problema u obstáculo es que esa cosmovisión es incompatible con los valores, principios, prácticas y hábitos del esfuerzo intelectual cooperativo.
El taylorismo posindustrial surgió en el contexto histórico de las revoluciones industriales pasadas; cuyos productos están basados en átomos. Por el contrario, la presente revolución industrial en ciernes genera productos y servicios basados en bits; es la así llamada “revolución de la información”. Un esquema industrial apropiado para este tipo de revolución es el esfuerzo intelectual cooperativo. Muchos de nosotros no contamos con una educación formal para dicho esquema industrial. Las escolarizaciones tradicionales, incluso en grado universitario, nos suelen preparar para obedecer, no para pensar; mucho menos para pensar cooperativamente. Por eso nos cuesta mucho trabajo poner en la práctica ideas que eclosionaron en ambientes intelectuales distintos a lo convencional.
Está claro que se necesita una reeducación profesional para la presente revolución industrial. Yo recomiendo que eso se deje enteramente en manos del individuo; es decir, para ser convincente, una auto-reeducación deberá ser buscada y lograda de manera por completo personal.
