El camino hacia el dominio II: un equipo con 11 delanteros

Antes de empezar, si no lo has hecho ya, te recomiendo leer el artículo anterior "Ansiedad VS Motivación: el estado de fluidez"  y "El camino hacia el dominio I: el test de egoísmo" para dar contexto a lo que te voy a contar a continuación.

Capítulo 2: un equipo con 11 delanteros. 

Si la primera prueba fue el test de egoísmo, en la segunda prueba Isagi y sus 10 compañeros (ya solo quedan 11 por grupo, ¡uno fue eliminado en el test de egoísmo!) deben convertirse en un equipo para competir en un torneo. El torneo enfrentará a 5 equipos, y solo los que queden en el primer y segundo puesto pasarán de fase, junto a 1 delantero de cada equipo perdedor: el que haya marcado más goles. Más de la mitad de los chicos de Bluelock quedarán eliminados...

Pero, ¿Cómo van a montar un equipo si los 11 son delanteros? ¿Quién va a ser el portero?

A lo que Ego les dice: 

"El fútbol consiste en marcar más goles que el oponente, ¿por qué no va a tener sentido que los 11 jugadores sean delanteros, si son los que marcan los goles?

No os quedéis confinados en vuestros roles. No dejéis que vuestra posición en el campo os frene.

En el fútbol no se puede ganar haciendo las tareas que te dan, necesitáis habilidades individuales."

En uno de los partidos del torneo, Isagi tiene que jugar de defensa. 

Isagi es delantero, en lo que él es experto es en marcar goles, en tirar a portería. Pero eso no significa que no pueda tener otras habilidades, que no pueda saber hacer otras cosas que aporten al equipo y que les permita ganar.

Esto en agilidad es lo que llamamos habilidades en T o "T-skills". Los equipos ágiles son multifuncionales, lo que significa que entre todas las personas del equipo reúnen todas las habilidades necesarias para poder entregar software, y además que sus miembros tienen habilidades en T. 

Es decir, yo puedo ser experta en programación Java, pero eso no significa que no sepa de testing. Yo puedo ser experto en testing pero eso no significa que no pueda hacer despliegues.

Un ejemplo de esto lo viví en un proyecto donde backend y frontend eran dos equipos distintos. La gente del equipo de front se negaba a aprender cualquier cosa que se apartase de “tareas de un programador frontend”. Ni para poder hacer tests sin pedir ayuda, ni para poder buscar datos en la base de datos. En fin.

Lo que no sabían es que a nivel management esto era un problema muy grave porque no siempre había tarea "puramente" front, y ya estaban pensando en cómo sustituirlos por gente que quisiese coger la doble competencia front-back (serás experto en back, pero serás capaz de hacer también algunas tareas de front o a la inversa).

Escribiendo estas líneas he recordado que yo misma estuve en ese plan, como el equipo de Front del que hablo: yo soy de cobol, solo hago tarea de cobol.

Viéndolo con perspectiva, estaba completamente desmotivada. Trabajábamos con dos tecnologías, cobol y una herramienta con un lenguaje propio. Estaba desmotivada por varias razones, pero me puse en plan "pues yo solo hago cobol" también porque mis compañeros no querían aprender cobol. Lo típico: cuanto más sabes más tarea te dan. Si cogía más conocimiento, me caerían más marrones.

Ya veis cómo pensaba yo en esa época...

Entonces llegó la agilidad. Yo quería con todas mis fuerzas que la transformación ágil saliese bien y que se quedase. Pero los equipos ágiles son multifuncionales, ¡y sus miembros tienen habilidades en T! 

Así que abrí los brazos y abracé el cambio, y empecé a hacer tarea de esa herramienta raruna. Y aunque yo era experta en Cobol, era capaz de hacer pequeñas tareas de la otra parte. Podía aportar más al equipo que antes (como Isagi!). Podía entender mejor el funcionamiento de la aplicación (y a mis compis no coboleros). Y mira tú, mis compañeros empezaron también a querer aprender de Cobol...

Porque limitarte a lo que tu rol dice que eres, es otro bloqueo para tu aprendizaje :-)

Continuará...

#thisistheway