Definición

Los Developers (o Desarrolladores) es uno de los tres roles en Scrum y se compone de todas las personas que se encargar de construir el Incremento de Producto en cada Sprint. Hasta la Guía Oficial de Scrum del  2017 también se lo conocía con el nombre de “Equipo de Desarrollo”.

Los Developers son auto-organizados

Cuando nos referimos a esta cualidad en Scrum, queremos decir que nadie (ni siquiera el Scrum Master) le dice al equipo cómo convertir el Product Backlog en Incrementos de Producto a lo largo de cada Sprint. Para lograr que este nivel de madurez resulte efectivo necesitamos que todo el equipo tenga muy en claro y presente la Vision del producto.

¿Qué significa ser multifuncional?

Significa que está compuesto por personas con diferentes competencias necesarias para completar cada Incremento de Producto. Ser multifuncional busca no depender de personas externas al equipo, de manera que no se ponga en peligro el cumplimiento del Objetivo del cada Sprint.

No se reconocen títulos ni jerarquías

Dentro de este marco ágil no se reconocen títulos ni jerarquías dentro de los Developers, independientemente del trabajo que realiza cada persona. Tampoco se reconocen sub-equipos internos, independientemente de los dominios que deben abordarse, como pruebas o calidad, arquitectura, operaciones o análisis.

Los Developers pueden especializarse en ciertas áreas pero la responsabilidad de los objetivos pertenece a los Developers como como un todo.

Comunicación con los Stakeholders.

Si bien el Product Owner mantiene principalmente las relaciones con los Stakeholders buscando optimizar la entrega de valor, es muy importante que también fomente la comunicación directa entre ellos y los Developers. En Scrum esta relación directa se produce principalmente durante el evento del Sprint Review donde los Developers recibe el feedback del Incremento sin ningún tipo de filtro de comunicación por parte de terceros.

¿Cuál es el tamaño de un Equipo Scrum?

El tamaño, según la guía Scrum, es 10 personas o menos. (Se considera al Product Owner y al Scrum Master).

Trabajar con muy pocas personas puede resultar en falta de habilidades necesarias para construir un Incremento de Producto de valor durante un Sprint.

Por el otro lado, tener muchas personas hace que aumente considerablemente los canales de comunicación, lo que implica mayor complejidad y al final requiere demasiada coordinación para que un proceso empírico sea útil.

Experimentos con equipos de alta performance publicados en la Harvard Business Review han demostrado que el tamaño óptimo es de 4 a 5 personas.

Entonces como conclusión podemos decir que debe ser lo suficientemente pequeño como para moverse rápido y lo suficientemente grande como para completar un trabajo significativo en Sprint.

Buenas prácticas

Perfiles multidisciplinarios

Dentro del sistema de producción de Toyota existen algunos conceptos que tienen como objetivo la mejora en las diferentes etapas del proceso productivo. Uno de ellos es “Muri” que significa sobrecarga. Este concepto se refiere a cualquier actividad que requiere un estrés o esfuerzo muy alto por parte de cierta persona o equipo, provocando cuellos de botella o tiempos muertos.

Un problema de no tener un equipo con perfiles multidisciplinarios hace que, por ejemplo, cuando aumenta la demanda de cierto tipo de tarea, solamente una o pocas personas del equipo pueden trabajar en ello.

Otro problema que se suele observar de no tener esta habilidad de equipo se da cuando algún miembro se va de vacaciones y el equipo queda inhabilitado para producir un Incremento de Producto y comienza a trabajar en tareas de menor prioridad o valor.

Equipos estables

Los equipos estables tienden a conocer mejor su capacidad, lo que hace posible que la organización tenga cierta previsibilidad. La recomendación es dedicar a los miembros del equipo a un solo equipo siempre que sea posible.

Conclusiones

Las habilidades específicas que necesitan los Developers suelen ser amplias y variarán según el contexto de su trabajo. Sin embargo, los Developers siempre son responsables de:

• Crear un plan para el Sprint: el Sprint Backlog.
• Inculcar calidad al adherirse a una Definición de Terminado.
• Adaptar su plan cada día hacia el Objetivo del Sprint.
• Responsabilizarse mutuamente como profesionales.

¿Cuántas personas trabajan dentro de tu equipo actualmente? ¿Cómo crees que podrían mejorar? Hablemos en los comentarios.