Últimamente veo cada vez más confusión en torno al concepto de equipo ágil. Ahora que muchas organizaciones han decidido subirse al carro de la agilidad y los Agile Coaches que nunca han tenido ninguna experiencia real en Scrum, Kanban, Nexus, SAFe o LeSS -muchos de ellos dicen que lo que son es seguidores del Agile Manifesto– están recomendando a sus clientes estructuras de equipo que no tienen mucho sentido, es necesario clarificar cuales son los significados de cada uno de los términos y cuando tienen sentido aplicarlos.

La alineación entre Producto, Equipo y Arquitectura

Lo primero es tener en cuenta como está organizado nuestro producto. Esta es la primera limitante. Si tenemos un backlog organizado por componente, difícilmente podremos tener equipos de feature. Aunque esto se puede cambiar, si tenemos un Producto organizado por features y un equipo alineado, si trabajamos con una arquitectura monolítica, tendremos que lidiar con muchos retos adicionales.

¿Que quiere decir esto? Que producto, equipo y tecnología no están separados, sino precisamente lo contrario. Las decisiones en cuanto a la arquitectura de nuestras aplicaciones afecta a la composición de los equipos y a la manera de organizar nuestro producto.

Los equipos cross-funcionales

La guía de Scrum introduce el concepto de equipo cross-funcional. Este es un equipo que es capaz de transformar un Product Backlog Item (PBI) en un incremento terminado al final del Sprint. La definición no va más allá de eso.

El equipo de desarrollo tiene que ser un equipo cross-funcional. Si nuestro backlog está organizado en torno a componentes, entonces un equipo especializado en una tecnología en concreto puede ser un equipo cross-funcional.

Si está organizado en torno a características end-to-end de la aplicación, entonces tendrá que tener más generalistas que especialistas, o al menos lo suficiente para poder entregar al menos un incremento terminado durante el Sprint.

Un equipo cross-funcional puede ser un equipo de feature, uno de componente o un full-stack, pero no necesariamente todos esos tienen que ser un equipo cross-funcional. De nuevo, depende de la organización de la arquitectura de nuestro producto y de la organización del Producto en sí mismo.

Equipos de componente

Los equipos de componente son aquellos que están organizados en torno a capas de la aplicación. Normalmente serán dos o más equipos cada uno especializado en distintas partes de la tecnología. Por ejemplo, un equipo de front-end y un equipo de back-end, como podemos ver en la imagen.

La principal ventaja de los equipos de componentes es que economizan la utilización de personas, es decir, permiten que los equipos avancen a distintas velocidades asegurándonos que nadie está parado en ningún momento. El equipo 3 puede estar desarrollando cosas que se harán en unos meses mientras que el equipo 2 está preparando la próxima release. Son baratos.

La mayor pega es que las cosas no suelen funcionar como lo esperábamos y cuando necesitamos disponer del equipo 1 de nuevo, ya están ocupados haciendo otras cosas, lo que implica empezar a crear colas que tienden a infinito. A pesar de ser baratos, una estructura de equipos de componente siempre será más lenta en órdenes de magnitud que cualquier otra organización.

Este es el motivo por el que organizaciones que se estructuran de esta manera tienen ciclos de desarrollo de software que en ocasiones llegan a llevar años de principio a fin.

Equipos de feature

Los equipos de feature buscan arreglar esto. Estos equipos se organizan teniendo distintos especialistas-generalistas que pueden cubrir el desarrollo de una nueva feature orientada al usuario final. No necesariamente tienen que cubrir todas las capas de una aplicación, sino que pueden estar más especializados en un área (Pagos) que en otra (Cuenta de usuario).

La principal ventaja de estos equipos es que son mucho más ágiles que las estructuras de componente, lo que hace que sean mucho más aptos para Scrum, que requiere un incremento terminado en 30 días o menos. Algunas de las pegas más comunes de los equipos de feature son:

• Hay que crear una cultura de equipo orientado a un sólo objetivo
• El uso de Sprint Goals es necesario para conseguir este objetivo
• No todo el mundo está completamente ocupado todo el tiempo
• Pueden dar lugar a frustración de algunos miembros del equipo de desarrollo
• Requieren de habilidades transversales en lugar de especialización.
• En grandes organizaciones donde muchos equipos intervienen en el software, puede ser imposible mantener esta estructura.

Los equipos de feature son una alternativa intermedia entre los equipo de componente y los full-stack, que veremos a continuación.

Full-stack feature teams

Por último, los full-stack feature teams son los anteriores llevados al extremo. En esta estructura, todos los equipos de desarrollo son capaces de llevar a termino un PBI y convertirlo en un incremento terminado, porque entre todos sus miembros controlan el stack completo de la aplicación.

Estos equipos son agilidad llevada a la máxima potencia. Al tener esta independencia y capacidad de ejecución, la organización puede estar trabajando en varias features a la vez y entregarlas todas en un sólo Sprint. LeSS (Large Scale Scrum) recomienda tener al menos un 51% de equipos full-stack, recomendando llegar al 90%.

El problema es que son realmente caros, porque muchos miembros del equipo de desarrollo no tendrán nada que aportar durante el Sprint. La solución a esto es tener profesionales que tengan más conocimiento generalista que especialista, lo cual es imposible en la mayoría de las ocasiones. ¿Que organizaciones se pueden permitir tener un administrador de base de datos (DBA) en cada equipo?

En resumen, la estructura del equipo depende de varias variables: Economía, Producto y Arquitectura. Debe ser una organización estratégica para el contexto y el entorno donde desarrollamos nuestro producto. ¿Que sentido tiene ser capaz de entregar feature nuevas cada semana si el coste de absorción por parte del usuario es muy alto? ¿Como podemos tener equipos de componente en un entorno de alta volatilidad y competencia?