El Development Team, más que un equipo de “desarrolladores”.

Si has trabajado con equipos Scrum, alguna vez te habrás preguntado quiénes forman parte del Development Team. Por ejemplo, ¿todos los desarrolladores que escriben código son el Development Team? ¿Qué sucede con los que no escriben código? ¿Son también “desarrolladores”?

De hecho, muchas veces me han hecho esta pregunta los propios miembros de equipos Scrum con los que he trabajado e incluso ha sido objeto de debate en la comunidad ágil de Paradigma. ¡Arrojemos luz sobre la cuestión!

El corazón de un equipos Scrum es el Development Team. Algunos interpretan este nombre como el equipo compuesto por los miembros que “escriben código”. Sin embargo, los mejores Development Teams hacen muchas más cosas aparte de escribir código, aunque esta tarea sea esencial para lograr entregar un Incremento de Producto.

Por ejemplo, los especialistas en UX ayudan al equipo a entender a los clientes a la vez que proporcionan soluciones y soporte a otros desarrolladores que escriben código.

Otro ejemplo serían los QAs, guardianes de la calidad del Producto que velan, entre otras cosas, porque el código escrito cuente con los tests necesarios. Así podríamos seguir con los Analistas, con los especialistas en Sistemas y Operaciones, etc.

Por tanto, es obvio que no solo se contribuye a la creación de un Incremento escribiendo código, por lo que el término “desarrollador”, tal y como lo entiende Scrum, va más allá de la pura programación.

De hecho, merece la pena citar la definición que hace Scrum.org del término “desarrollador”:

Developer: any member of a Development Team, regardless of technical, functional or other specialty”.

Es decir, no importa si la contribución es técnica, funcional u otra especialidad para ser miembro del Development Team.

Sin embargo, no basta con que los “desarrolladores” sean especialistas en un área de conocimiento. Una de las claves para conseguir que un equipo ágil de verdad funcione es que esté compuesto por miembros multifuncionales, en lugar de miembros hiper-especializados.

No es suficiente con que la composición del equipo sea cross-functional, en un equipo ideal, todos los “desarrolladores” deben ser capaces de contribuir en múltiples dimensiones.

El término cross-functional está muy relacionado con otro concepto anglosajón del mundo del reclutamiento: T-shaped skills. Este término se utiliza como metáfora para describir las habilidades de una persona para contribuir en el trabajo.

El palo vertical de la T representa su habilidad dominante, su especialidad, el área de conocimiento donde esa persona es más fuerte. Mientras que el palo horizontal de la T representa otras habilidades menores, pero presentes con las que esa persona puede aportar al equipo.

Por lo tanto, es importante que los miembros de un Development Team reflexionen acerca de sus habilidades y tomen consciencia de que, además de ser especialistas en una materia, si trabajan en un equipo Scrum y aspiran a ser Development Team Members Awesomicos, deben también trabajar activamente sobre el palo horizontal de su T, sobre las habilidades que los convertirán miembros cross-functional.

No hay que perder de vista que, en un Sprint, existe un trabajo que terminar, un Sprint Goal que alcanzar y poder contar con jugadores polivalentes siempre es una ventaja.

Yendo un paso más allá, no se trata sólo de Scrum; si queremos ser Grandes Profesionales del Trabajo en Equipo, no basta con saber mucho de una cosa, tenemos que expandir nuestras áreas de conocimiento para comunicarnos mejor con nuestros colegas, entender sus problemas y poder ayudarles.

Seguro que has visto la película Los Mosqueteros, ¿recuerdas su lema? “Todos para uno y uno para todos”. Pues eso.

De los miembros de un Development Team se espera que hagan lo que sea necesario, cualquiera que sea la tarea, para entregar un Incremento al final del Sprint. El concepto T-shaped skills no solo aplica a las habilidades, sino que define un mindset, una forma de actuar en equipo, compartiendo propósito y responsabilidad. Los equipos con esta mentalidad, no solo son más resilientes y responden mejor al cambio, sino que son más colaborativos y creativos.

Es cierto que es muy difícil que todos los miembros de un Development Team dominen todas las áreas de conocimiento implicadas en el desarrollo de un Producto, por no decir casi imposible.

Pero, llevado al contrario, ¿qué sucede cuando un único miembro del equipo acapara un área de conocimiento? Por ejemplo, ¿qué ocurre cuando sólo una persona del equipo sabe hacer los despliegues o resolver un problema de la infraestructura? O, ¿qué sucede cuando sólo el QA, o ciertos desarrolladores, saben escribir tests y/o realizar las pruebas? Pues que, además de un cuello de botella, supone un gran riesgo para el Producto.

Esta mentalidad se denomina I-shaped skills y es muy común en equipos Scrum de reciente creación. Refleja una forma de pensar y actuar: ”This is what I do, who I am and I am very good at this particular skill".

Conclusiones

En el Development Team todos los miembros del equipo son “desarrolladores”, escriban o no código. Además de escribir código, los grandes Development Teams realizan otras muchas actividades (que involucran otras áreas de conocimiento) de gran valor para el Producto.

De hecho, Scrum no reconoce ni títulos ni subequipos dentro del Development Team. Lo que sí admite Scrum es que los miembros del equipo puedan tener dominios de especialización, aunque la responsabilidad hacia fuera recae sobre el equipo al completo.

Los Development Teams que más sobresalen tienen un mindset T-shaped. Están compuestos por miembros multifuncionales capaces de aportar valor en múltiples dimensiones. Dominan una especialidad pero también aportan al trabajo del equipo en otras áreas, ¡son grandes jugadores con visión de equipo!