El error de encasillar nuevas profesiones en otras más antiguas (y su posible nueva aplicación al rol del Agile Coach)

Probablemente, la profesión del desarrollo software (en toda su amplitud y con sus diferentes especialidades) haya sido una de las profesiones que, en la historia (o al menos en la reciente), más ha sufrido el haber aparecido, como algo muy nuevo, algo que no existía, y haber sido forzada a ser encasillada bajo alguna otra profesión, otras disciplinas, más antiguas y potentes por aquellos años.

De hecho, todos los que nos dedicamos a esto, incluso los más nuevos hoy, los que están empezando ahora, han sufrido, en mayor o menor grado, de este error histórico. Algunos pudimos salir de esas ideas (no sin esfuerzo), otros no lo harán nunca.

Y después de unos 70 años, aproximadamente, aún sufrimos de ello, de forzar lo entonces nuevo a lo tradicional. E incluso aún hoy hay quien defiende esa idea e incluso enseña aquello de que el desarrollo software debe gestionarse como lo hacen en otras profesiones, encasillándolo ahí. Muchas organizaciones viven ahí y persisten, y persistirán, en ello.

El desarrollo software arrastra aún haber sido asemejado a las ingenierías clásicas, la creación de hardware o los modelos de gestión de la arquitectura tradicional.

Esto no es algo que me haya inventado yo, si quieres referencias lo puedes leer en las actas de la primera conferencia sobre ingeniería del software (y aquello de software como arquitectura), lo puedes (debes) leer en el A View of 20th and 21st Century Software Engineering de Boehm (…1950’s Thesis: Software Engineering Is Like Hardware Engineering), lo puedes leer en esta entrevista a uno de los padres de la agilidad «Entrevista en el blog: Alistair Cockburn«, lo puedes ver hasta en el nombre de las asociaciones que durante años «regulaban» la gestión software (como la IEEE, Institute of Electrical and Electronics Engineers), etc.

De hecho, la tan popular (y poco entendida) Agilidad surge como contra movimiento a todo esto de meter a la profesión del desarrollo software bajo modelos de gestión más antiguos que no encajaban. De asemejar una profesión nueva que no se entiende con una tradicional.

Volviendo al día de hoy… ¿Podemos estar cometiendo, en menor escala, ese mismo error con nuevas profesiones que derivan del mundo del desarrollo software? ¿Con las que derivan de la Agilidad?

Quizá uno de los ejemplos más claros es el del Agile Coach, una profesión que se ha puesto de moda recientemente (aunque es antigua, recuerda que ya la mencionó Kent Beck en eXtreme Programming en los 90, aunque no tengo claro que el tuviera en la cabeza lo mismo que hoy se pretende en muchos sitios que sea un Agile Coach), pero que, seguramente por su poca madurez, nadie tiene claro qué es, hay muchas interpretaciones, y por su novedad… ¿estamos intentando encasillar algo nuevo en profesiones más tradicionales?

“Watches everything, sends obscure signals, makes sure the project continues to Stay Extreme. Helps with anything.” (definición del Coach en eXtreme Programming, por aquellos tiempos sin Agile, una de las que probablemente sea de las más antiguas, vía la wiki de Cunningham).

[“Vigila todo, envía señales oscuras, hace que el proyecto siga extremoAyuda con todo.“]

¿El Agile Coach es principalmente algo que encasillar bajo la tradicional psicología? ¿…es el Agile Coach una rama moderna de la misma? O, más aparentemente obvio… ¿El Agile Coach es principalmente algo que encasillar bajo el tradicional Coaching?

Argumentos que, en ciertos sectores, en estos tiempos, se escuchan mucho. Suena cómo cuando tiempo atrás pensaron electricistas, electrónicos, industriales, etc., que el desarrollo software… era una nueva rama de sus profesiones, en vez de una profesión nueva que había que entenderla así, como algo nuevo.

Como algo que seguramente tenga un poco de muchas áreas pero de manera diferente, aplicado contextos diferentes, con una evolución diferente.

En vez de tanto encasillar a profesiones nuevas en otras tradicionales, mejor deberíamos entender que hay cosas nuevas que surgen.

Mas que el debate de saber en qué rama tradicional meter al Agile Coach mas nos valdría preocuparnos de que el Agile Coach sepa… de Agile, que la «felicidad ágil» y los debates de encasillamiento no nos hagan olvidar al «esfuerzo ágil» (ojo, el anterior es un post de 2014, de hace 5 años y ahí sigue), que de eso si que deberíamos tener claro que debe saber y me parece a mí que no es así en gran mayoría de los casos (por lo que el rol del Agile Coach tienen pinta de seguir el camino del Scrum Master y su extinción).

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Dejar un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *