Los Developers de Scrum son un importante cambio incorporado a la guía. La reordenación de conceptos en torno al Scrum Team es clave para interiorizar mejor Scrum. Originalmente, el Scrum Team se dividía en tres roles: Scrum Master, Product Owner y Development Team.
Este último, al tener incorporada la palabra “Team” provocaba una separación entre estas personas y el resto del Scrum Team. Para recalcar la idea de equipo, el concepto ha evolucionado a “Developers”. ¿Quiénes son los developers y a qué se dedican? ¡lo analizamos!
Qué y cómo
A la hora de desarrollar un nuevo producto, tenemos que diferenciar entre dos dimensiones. Por un lado, quién es el responsable de definir qué se hace y por otro lado quién se encarga de definir cómo se hace.
Esta separación no es tan sencilla como pueda parecer, por ejemplo: “tenemos que hacer un botón azul de 100 píxeles que nos muestre la información de las ventas de nuestros clientes”. Aquí parece que estamos diciendo el qué pero también el cómo. ¡Toca trabajar la frontera!
En Scrum, la persona que ejerce de Product Owner se responsabiliza del qué mientras que los Developers del cómo. De esta manera, nos aseguramos que ambas dimensiones están cubiertas en el Scrum Team.
Características de los Developers en un equipo Scrum
Los Developers son todas aquellas personas que contribuyen a la construcción y desarrollo del producto. Esto incluye codificadores o programadores y también a analistas, UX, calidad y cualquier otra habilidad que haya que ejercer para entregar valor al cliente. He visto a equipos incorporar entre sus Developers a abogados, Recursos Humanos o personas de apoyo que contribuyen de manera activa al éxito del producto.
Por tanto, la palabra Developer se refiere a cualquier persona que desarrolla el producto más allá de las líneas de código que ponga. Con ello, eliminamos etiquetas y ponemos al mismo nivel de responsabilidad a todas las personas del Scrum Team.
En los Developers no hay etiquetas, hay habilidades (Skills)
En el mundo actual en el que utilizamos LinkedIn y plataformas similares tendemos mucho a etiquetar a las personas. Necesitamos un QA en la empresa o esto lo tiene que hacer un diseñador. Realmente, la calidad, el diseño, el análisis, el soporte o el desarrollo son todo tareas de un determinado producto, ¡No son personas!
Scrum elimina estas etiquetas y favorece la creación de skills o habilidades. En vez de responder a la pregunta “¿Qué eres?” debemos ser capaces de contestar a la pregunta “¿Qué sabes hacer?”. Es decir, explicar tus habilidades por encima de la etiqueta que tienes.
Un equipo Scrum está compuesto por habilidades que le deben de permitir entregar valor y no de personas etiquetadas que entran y salen para desarrollar un determinado trabajo.
Sí, en la práctica, los especialistas en calidad harán calidad y los especialistas en análisis harán análisis pero la responsabilidad seguirá siendo compartida y deberán de buscar la manera de colaborar unos con otros para entregar valor. El objetivo no es optimizar tu trabajo para honrar a tu etiqueta sino la colaboración mútua y la corresponsabilidad para entregar valor.
Características de los Developers en un equipo Scrum
En general, los Developers suelen ser un conjunto pequeño, inferior a 10 personas. Son los encargados del Sprint Backlog tanto de crearlo como de mantenerlo.
Dado que son los creadores de la entrega de valor deberán de velar por la Definición of Done. Deben asegurarse de que disponemos de una y de que colaboramos unos con otros para cumplirla. La calidad que queremos tener debe estar reflejada en la DoD por eso es tan relevante.
Los Developers deben ser profesionales y vivir los valores de Scrum para poder entregar valor. Además, según el contexto en el que aplicamos Scrum, deberán de aportar otro tipo de técnicas que les permitan mejorar la capacidad de entrega de valor. Si aplicamos Scrum en el desarrollo software, los Developers deberán aportar técnicas como pair-programming o TDD que les permita mejorar la calidad y efectividad de su trabajo.
Autogestión
La verdadera autogestión aparece a través de los Developers y, para ello, el Scrum Master debe prestarles servicio y ayudarles en ser un equipo.
La autogestión no es binaria sino que requiere de niveles y puede ser progresiva. Los Developers deben de conocer sus límites de autogestión, qué cosas pueden decidir cuáles tienen que preguntar o cuáles son impuestas. La persona que ejerce de Scrum Master se encarga de favorecer este debate que permita definir y evolucionar los límites de la autogestión. ¿Podemos decidir dónde sentarnos? ¿Podemos decidir qué tecnologías utilizar?
Los Developers deben entender que la autogestión requiere de mucha gestión y por tanto de trabajo en equipo con el objetivo final de la entrega de valor. Unos Developers que tienen la autonomía para autocomponerse, es decir, decidir quién entra o sale del Scrum Team suelen llegar a altas cosas de entrega de valor.
Y tú ¿Tienes Developers autogestionados en tu equipo Scrum?
