Las habilidades en forma de “T” son una metáfora para describir a profesionales que son especialistas en una determinada parcela (por ejemplo, desarrollo back-end), pero que también cuentan con habilidades o conocimientos genéricos en otras áreas relevantes (como front-end, testing o documentación). Esto quiere decir que, aunque el ámbito de trabajo preferido de esa persona sea aquella especialidad o disciplina que domina en profundidad, será capaz de aportar en otros ámbitos, horizontalmente, aunque en estos no sea especialista o no sean tareas en las que destaque.

¿Por qué son importantes las habilidades en forma de “T” cuando hacemos Scrum?

Pues porque en Scrum no vale aquello de “yo ya terminé lo mío”. O, peor aún, “yo terminé lo mío y tú eres muy malo o muy lento y no terminaste lo tuyo, por eso no pudimos entregar la funcionalidad y por eso la culpa de que el Sprint fuera un desastre es tuya, no mía”. Cuidado. En Scrum, la responsabilidad de lograr el Objetivo del Sprint recae sobre la totalidad del Equipo Scrum. Si no entregamos, nos toca a todos levantar la mano y hacer autocrítica. Habrá que revisar qué está pasando, de manera constructiva. Scrum no es un juego de culpas ni de reproches.

Por tanto, queremos que el desarrollador back-end, que es “un crack” en lo suyo, también se faje y eche un cable testeando cosas, o que ayude a los compañeros que hacen el front, o que documente APIs, etc. Recuerdo un ejemplo muy bonito de un compañero de back-end que también sabía ilustrar, y que se puso a ayudar al responsable de UX/UI con un rediseño de la home. Esto nos permite terminar los elementos del Product Backlog en los que empezamos a trabajar, antes de abrir otros nuevos, minimizando el trabajo el curso.

No se trata de que todos sepamos hacer de todo. Ojo. Lo que queremos son profesionales capaces de ir “todos a una”, que significa contribuir más allá de nuestra especialidad, en la medida de lo posible. Puede que las habilidades necesarias vayan cambiando, a medida que el producto y el propio equipo de proyecto evolucionan. Los managers o líderes dentro de la empresa deben intentar favorecer la formación de equipos que cuenten con profesionales con habilidades en forma de T.

¿Es malo tener a especialistas en un equipo Scrum?

Lo deseable es tener a compañeros con habilidades en forma de “T”, no a especialistas que se nieguen a aportar en otras áreas. Si no hay voluntad de intentar contribuir, aunque sea mínimamente, cuando sea necesario, fuera del ámbito de especialidad, con seguridad nos encontramos ante problemas de falta de actitud y compañerismo. Esto no casa bien con Scrum. Pero, insisto, no consiste en que todos hagamos de todo. Por supuesto, cada cual conservará su especialidad y seguramente dediquemos a ella la mayor parte del Sprint, y eso está bien.

Otra situación común es la de “recursos compartidos”. Pensemos en un diseñador de UI que trabaja con tres equipos, supuestamente dedicando un 33% de su tiempo a cada uno de ellos. Este escenario es habitual, aunque no idóneo. El cambio de contexto al tener que navegar por entre múltiples proyectos implicará una merma de productividad que no podemos ignorar.