El Equipo de Desarrollo Scrum

El Equipo de Desarrollo Scrum

El Equipo de Desarrollo Scrum, o Development Team, o simplemente DevTeam, conforma una de las tres patas del Equipo Scrum, siendo las otras dos el Product Owner y el Scrum Master.

El Product Owner es, como su nombre indica, el dueño o propietario del producto que se va a construir, entendiendo por dueño quien lo define, quien entiende su valor de negocio y, en definitiva, el responsable de ese producto de cara a la organización.

El Scrum Master es, también como su nombre indica, el experto o maestro en Scrum. Entre otras cosas, vela porque el Equipo Scrum se atenga al marco de trabajo de forma que se aplique correctamente y trata de quitarles cualquier piedra del camino de cara al buen desarrollo del Sprint.

Pues bien, el Equipo de Desarrollo Scrum lo forman los desarrolladores que realizan el trabajo de construir y entregar un incremento de producto terminado (done) que potencialmente se pueda poner en Producción al final del Sprint.

Por cierto, quien decide si finalmente el incremento subirá a PRO o no subirá es el Product Owner.

En este post pondremos foco en aquellos que construyen, prueban e implantan el software Sprint tras Sprint: el Equipo de Desarrollo Scrum.

Quiénes forman el Equipo de Desarrollo Scrum

Como su nombre indica, el Development Team está formado por aquellos desarrolladores o profesionales que realizan todas esas tareas técnicas que terminan como resultado con un incremento al final de cada Sprint que potencialmente podría subirse a Producción.

Por desarrollador debe entenderse no sólo al que programa. El marco de trabajo considera desarrollador a cualquier profesional técnico que participa en la construcción y despliegue del incremento, sea programador, tester, technical lead o devops. Es decir, no reconoce categorías dentro del equipo.

Sólo los miembros del Equipo de Desarrollo participan en la creación del incremento. Esto dice la teoría, aunque en el mundo real el incremento suele contener partes realizadas por equipos ajenos al Equipo Scrum, que el Equipo de Desarrollo deberá integrar en el incremento. Ya veremos este tema de las dependencias externas en otro momento, porque da para mucho.

También dice la teoría que la organización es la encargada de estructurar y empoderar a los Equipos de Desarrollo para que estos organicen y gestionen su propio trabajo. Esto lo que viene a decir es que debe darse al Equipo de Desarrollo la suficiente autoridad y potestad para poder ser una célula autónoma, con capacidad de decisión.

Por tanto, si durante el Sprint Planning el DevTeam se planta en una determinada cantidad de trabajo, no se le debería presionar para que meta más. Eso dice la teoría…

En general, cualquier equipo ágil debe presentar las siguientes características:

  1. Pequeño.
  2. Multifuncional.
  3. Autoorganizado.
  4. Estable (no se desmonta).
  5. Tiene un objetivo claro.

Veamos con más detalle.

Características de un Equipo de Desarrollo Scrum

La guía Scrum indica que los Equipos de Desarrollo tienen las siguientes características:

Auto-organizados

Nadie (ni siquiera el Scrum Master) indica al Equipo de Desarrollo cómo convertir elementos de la Pila del Producto (Product Backlog) en Incrementos de funcionalidad potencialmente desplegables. Es decir, el equipo debe tener plena capacidad de decisión en ese aspecto.

Multifuncionales

Los Equipos de Desarrollo contarán con miembros con todas las habilidades necesarias para crear un Incremento de producto. Ellos solitos deberían tener a la gente necesaria para construir el incremento al completo de tal forma que se pueda dar por done.

Pero como he indicado anteriormente, en el mundo real no siempre se respeta esa premisa por culpa del trabajo en silos y tienes a equipos técnicos ajenos al Equipo Scrum que sí tienen participación en el incremento y con los que, obviamente, habrá que integrarse en algún momento.

Todos son desarrolladores

Scrum no reconoce títulos para los miembros de un Equipo de Desarrollo independientemente del trabajo que realice cada persona. ¡Aquí todos son desarrolladores!

Insisto, todos son desarrolladores

Scrum no reconoce sub-equipos dentro de los Equipos de Desarrollo, no importan los dominios particulares que requieran tenerse en cuenta, como pruebas, arquitectura, operaciones, o análisis de negocio. Lo dicho, todos desarrolladores. Punto.

Uno para todos y todos para uno

Los miembros individuales del Equipo de Desarrollo pueden tener habilidades especializadas y áreas en las que estén más enfocados, pero la responsabilidad recae en el Equipo de Desarrollo como un todo. Así que todo el mundo debe remar en la misma dirección, de modo que tanto el éxito como el fracaso es compartido. Aquí no hay héroes ni primadonnas!!!

Tamaño mediano-pequeño

El tamaño óptimo del Equipo de Desarrollo es lo suficientemente pequeño como para permanecer ágil y lo suficientemente grande como para poder completar una cantidad de trabajo significativa. Vaya, que ni muy grande ni muy pequeño.

Distintos experimentos consideran que 3-9 es el número óptimo de modo que eso es lo que prescribe la guía. Aunque posteriormente Jeff Sutherland, uno de los dos creadores de Scrum, ha hablado de que 4-5 sería el número ideal.

Estructura interna del Equipo de Desarrollo Scrum

El que un DevTeam sea un equipo autoorganizado y con todas las competencias técnicas necesarias para construir el incremento al completo ya es todo un hito.

De hecho, en muchas compañías que trabajan de forma departamentada y en silos, esto no siempre se cumple y al final el Equipo de Desarrollo Scrum es uno de entre varios equipos técnicos que trabajan sobre el incremento. De modo que si tu caso es el ideal, el que indica la guía Scrum, puedes estar contento…

Pero Scrum siempre busca el plus ultra, el mejor que mejor, así que si llegas a este punto no te conformes, todavía te quedaría un paso más que dar para lograr la completa multifuncionalidad de la que habla la guía Scrum.

Muchas veces, dentro de DevTeams completamente autoorganizados, aparecen pequeños silos, tal que, por ejemplo, el tester sólo prueba, o el desarrollador front sólo sabe hacer eso, desarrollar código front.

Soy consciente de que ser experto en varias tecnologías es muy complejo, y es que no hay tantos desarrolladores fullstacks solventes. La tecnología cada vez busca más la especialización. De hecho, la especialización supuso el génesis de la alta productividad.

Sin embargo, la superespecialización tiene sus inconvenientes…

Inconvenientes de los Equipos de Desarrollo Scrum en silos

Personalmente, encuentro principalmente cuatro grandes inconvenientes en esos equipos donde los roles están muy especializados, de forma que un rol en particular sólo puede llevarlo a cabo 1-2 personas y nadie más del equipo puede, en ausencia de estos especialistas, tratar de cubrir esa baja.

Normalmente este problema es debido al desconocimiento técnico, o porque los compromisos contractuales con los proveedores tecnológicos impiden que alguien que tiene un rol determinado por contrato trabaje en otro diferente, o porque la organización está dividida en departamentos, etc.

Desequilibrio en la carga de trabajo

Puede darse la circunstancia, por ejemplo, de que el tester esté casi sin trabajo mientras los programadores están a tope, o viceversa al final del Sprint. Ésto, además de poco productivo, puede generar resquemor dentro del equipo y que al final la gente tienda al individualismo.

Dependencia con uno o varios miembros del equipo

Si el especialista en un área falta (está de vacaciones, enferma, se va de la compañía) el DevTeam se queda cojo, incapaz de cerrar una historia de usuario. Pierde completamente su multifuncionalidad.

Por ejemplo, si tu tester se ausenta y sólo él puede certificar una funcionalidad, te quedas sin poner ninguna historia a done.

Falta de empatía con un objetivo común

El hecho de que una persona esté especializada en un trabajo en particular hace que, una vez que termine su parte, se desentienda del Sprint Goal ya que considerará que terminó su trabajo y por tanto ya ha cumplido con «su» objetivo en ese Sprint.

En definitiva, termina por desvincularse emocionalmente del Sprint Goal y sólo lo hace con su tarea en particular. Esto rompe completamente eso que dice la Guía Scrum de que la responsabilidad recae en el Equipo de Desarrollo como un todo.

Esto es especialmente negativo, ya que un DevTeam fuerte es aquel que rema al unísono en la misma dirección y no busca satisfacer iniciativas personales.

Rompe con la idea del swarming

El hecho de que cada uno trabaje en “lo suyo” hace que se empiecen muchas tareas en vez de preocuparse por cerrar, entre todos, una tarea antes de comenzar con otra, que es lo que viene a significar swarming (ya veremos este concepto en posteriores artículos).

Es el clásico “abrir muchos melones” sin preocuparse de las prioridades de cada funcionalidad. Este problema es consecuencia del punto anterior, de sentirse identificado con tu tarea técnica en vez de con el Sprint Goal.

RECUERDA: la superespecialización rompe la cohesión del DevTeam como un todo.

Para paliar este problema de la superespecialización, se indica que los Equipos de Desarrollo adquieran habilidades en forma de T (T-Shaped skill).

Equipos con habilidades en ‘T’

Las habilidades en ‘T’ representan lo siguiente: cada miembro del Equipo de Desarrollo tiene sus habilidades técnicas en las que está especializado. Esta especialización queda representada por el palo vertical de la ‘T’.

Pero además, cada miembro del Equipo de Desarrollo deben poseer habilidades básicas de otras áreas técnicas, representadas mediante el palo horizontal de la ‘T’.

Un ejemplo que ilustra esta idea es el de un equipo de futbol: aunque cada jugador tenga su posición dentro del campo, si se da la necesidad podrá realizar otra tarea diferente a la que tiene asignada. Por ejemplo, un delantero podrá hacer de defensa si con ello evita que metan un gol a su equipo. Nadie pide que el delantero tenga la misma habilidad defensiva que el defensa que es experto en ello, pero sí que por lo menos sea capaz de realizar esa tarea con un mínimo de solvencia.

Equipo de Desarrollo con habilidades en T
Un equipo de fútbol ilustra un ejemplo de equipo con habilidades en T: todos tienen su posición en el campo pero si se da la necesidad pueden adoptar otro rol, ¡todo sea por meter gol o evitar que te lo marquen!

Por supuesto, no es tan común que un experto en Angular tenga conocimientos de herramientas de automatización de testing. Pero la idea es tratar de tener una base mínima para que, en ausencia de un miembro del equipo, entre los demás puedan compensar esa carencia. 

Reflexión final

Me gustaría darte un consejo final: mantén a tu Equipo de Desarrollo sentado junto. A veces, no hay más remedio que trabajar en remoto, pero lo óptimo es tener a tus compañeros a tu lado. Esto se traduce en más inmediatez y menos ruido en la comunicación.

Por otro lado, hemos hablado de la cuestión de que sean equipos multidisciplinares y que no haya nadie cuya ausencia resulte fatal para cumplir con el Sprint Goal.

El planteamiento de los equipos en ‘T’ resolvería posibles lagunas de conocimiento en caso de ausencia del especialista en algún rol. Sin embargo, si el problema viene por un requisito burocrático, como por ejemplo que alguien con contrato de programador java sólo pueda dedicarse a eso y nada más, está claro que la solución es más una cuestión política que otra cosa.

Si te quedaron dudas puedes dejarlas en la sección de comentarios, estaré encantado de responderte.

Y si el artículo te ha resultado útil, te agradeceré mucho que lo compartas en alguna de las siguientes redes sociales. ¡Nos vemos en el próximo post!

Deja un comentario