Antes de hablar sobre lo qué es un Development Team en Scrum, os proponemos la siguiente dinámica. Es sencilla, os enseñamos 24 fotos de posibles Development Team. Se marcan aquellas que se consideren que cumplen las características de un Dev Team según la teoría de Scrum:
Analizando los resultados
¿Cuántas has marcado? La respuesta correcta es CERO. Ninguna de las imágenes representa a un Development Team. Cada una de esas tarjetas se refieren a equipos que tenemos en muchas organizaciones, incluso organizaciones que afirman tener equipos Scrum. Sin embargo, hay varios detalles que nos indican que estos equipos no son Scrum. Vamos a repasar las características de un Development Team.
Definición de un Development Team
Un Development Team se define como un conjunto de profesional que realiza el trabajo de desarrollar software “terminado” (cumple la Definition of Done), que se pueda desplegar en producción al final de cada Sprint. Es el encargado de crear el incremento que es necesario para la Sprint Review.
Los Devevelopment Team están estructurados y empoderados por la organización para que puedan decidir cómo organizar y gestionar su propio trabajo. Esto debería crear sinergias que permitan al Development Team mejorar su eficiencia y efectividad.
Características de un Development Team
Un Development Team tiene cinco características que vamos a traducir de la Scrum Guide:
- Son autoorganizados. Nadie, (incluido el Scrum Master) les dice cómo convertir elementos del Product Backlog en incremento de funcionalidad potencialmente desplegable.
- El Development Team es multifuncional, posee todas las habilidades necesarias para crear el incremento de producto.
- Carecen de títulos. Scrum no reconoce títulos para los miembros de un Development Team, independientemente del trabajo que realice cada persona;
- No son divisibles. Scrum no reconoce sub-equipos en el Dev Team, no importan los dominios particulares que requieran tenerse en cuenta, como: pruebas, arquitectura, operaciones, o análisis de negocio.
- Son todos responsables. Los miembros individuales del Development Team pueden tener habilidades especializadas y áreas en las que estén más enfocados, pero la responsabilidad recae en el Development Team como un todo.
Por tanto, los equipos no tienen etiquetas ni subequipos. Por eso, en la dinámica, ningún equipo cumplía con la definición. Cuidado, el Scrum Team tiene etiquetas (Scrum Master, Product Owner, Development Team member) pero el Development Team no tiene ninguna.
¿Etiquetas o Especialidad?
Sin embargo, la última característica señala que los miembros del Development Team sí pueden tener especialidades. Y es cierto, hay quienes se enfocan más en los test, quienes desarrollan la aplicación y quienes gestionan las subidas. En general, a las personas les ponen etiquetas y redes sociales, como Linkedin, no ayudan. El hecho de tener etiqueta nos hace pertenecer a una tribu y nos da identidad.
El problema de tener etiquetas lo explicaba muy bien Jeff Sutherland: cuando tenemos una etiqueta, solemos centrarnos solo en lo que nuestra etiqueta dice que hacemos, creando pequeños silos dentro de un equipo. Frases como “esta parte es mía y no la toca nadie” o “yo no hago análisis” demuestran que un equipo no está enfocado en la entrega de valor, y de esto, trata de protegernos Scrum.
Creemos que la mejor analogía son los XMEN. Los XMEN, porque están especializados por sus poderes, hay quien echa fuego, quien vuela o quien es telépata. Cada uno pone al servicio del equipo sus poderes, y trabajan en común para cumplir con los objetivos que se marcan.
¿Cómo podemos eliminar estas etiquetas?
Cambiar la mentalidad de etiquetas por la de especialidad no es fácil. Como hemos dicho antes, ataca a nuestra personalidad y a nuestra identidad. Aún así, os animamos a que hagáis esta dinámica con los equipos para que se lo planteen. Es importante que organicemos el trabajo por entrega de valor (PBIs) y no por etiquetas (Front-Back-Pruebas).
Otra herramienta que podemos utilizar es la matriz de habilidad de Management 3.0. En esta matriz, disponemos en filas las diferentes habilidades (skills) necesarias en nuestro equipo, y en columnas,los miembros del equipo. De esta manera, dejamos transparentar a tod@s qué habilidades necesitamos, cuáles solo domina una persona y qué inquietudes podemos tener en el equipo.
Hay muchos detalles que tendremos que trabajar con el equipo para que, de verdad, la responsabilidad del resultado del trabajo sea compartido. Un buen Scrum Master trabaja para que los Development Team tengan capacidad para tomar decisiones, y a su vez, para asumir la responsabilidad que ello conlleva.
Y tus equipos, ¿tienen etiquetas o están especializados?
Buenas! Gracias por compartir! Sobre la encuesta me equivoqué y marque algunas opciones, lo que pasa es que leyendo todo el artículo…. ¿Podría interpretarse que un Development Team puede tener Skills reconocidos como UX, QA, Front, Back, etc…? Si colaboran para conseguir un incremento, entonces…. ¿serían correctas algunas de las opciones en ese caso? Gracias por vuestro trabajo!
Sì y no, evidentemente el juego busca que pensemos en «skill»s y no en etiquetas. Si lo vemos como skills varias tarjetas son correctas. Sin embargo, si tenemos un equipo con las skills tan marcadas cuidado, un equipo donde cada uno es especialista en una cosa, es un equipo que asume un riesgo alto de que si alguien se ausenta el equipo no avance. Gracias por el feedback 🙂