Equipos multifuncionales frente a autoorganizados frente a funciones frente a equipos de componentes en Agile

Tradicionalmente, un proyecto se organiza en torno a  equipos de componentes  (es decir, UX, Dev, Business, Tester y…), cualquier lanzamiento que requiera una variedad de conocimientos de componentes deberá involucrar a varios equipos de componentes. Por lo general, diferentes equipos tendrán diferentes conjuntos de prioridades, lo que inevitablemente genera cuellos de botella en el ciclo de lanzamiento del producto.

Según Wikipedia, un equipo multifuncional es un grupo de personas con diferentes conocimientos funcionales que trabajan hacia un objetivo común. Una de las mejores maneras de mejorar la calidad de su equipo es hacerlo multifuncional. Un equipo multifuncional tiene todas las habilidades necesarias para convertir una idea en un producto funcional.

“ Los  equipos multifuncionales  tienen todas las competencias necesarias para realizar el trabajo sin depender de otros que no forman parte del equipo ” — Guía Scrum

En contraste con el enfoque de equipo de componentes,  los equipos multifuncionales  son grupos formados por personas de diferentes áreas funcionales de la empresa. — debe estar formado no solo por especialistas técnicos (back-end, desarrolladores de front-end, ingenieros de control de calidad, etc.) sino también por miembros como Business Analysts, especialistas en marketing y UX o cualquier otra persona que participe activamente en el proyecto.

Un  equipo autoorganizado  es un equipo que tiene la autonomía para elegir la mejor manera de realizar su trabajo, en lugar de ser dirigido por otros fuera del equipo. A diferencia de los principios de gestión tradicionales, los equipos empoderados autoorganizados no están dirigidos ni controlados desde arriba; más bien evolucionan a partir de miembros del equipo que participan activa y colectivamente en todas las prácticas y eventos de Scrum.

Equipo tradicional vs equipo ágil

“Un  equipo de autoorganización  consiste en un grupo de trabajadores del conocimiento que tienen que administrarse a sí mismos. Tienen que tener autonomía” —  Peter Drucker.

La Guía de Scrum indica que “El Equipo Scrum consta de un Propietario del Producto, el Equipo de Desarrollo y un Scrum Master. Ellos son:

“ Los Equipos Scrum  son  autoorganizados  y  multifuncionales ” —  Guía Scrum:

Equipo de componentes vs Equipo de características

El enfoque tradicional consiste en dividir el producto de forma más o menos lógica y significativa en componentes y asignarles equipos de componentes. Sin embargo, estos componentes son completamente irrelevantes desde el punto de vista del cliente.

Un enfoque de equipo de características ahora es una forma casi universalmente aceptada para organizar sus equipos, a diferencia del equipo de pila de tecnología, especialmente, en el enfoque de entrega continua, enfatiza las características (es decir, una porción vertical del sistema) que resuelven las necesidades de los usuarios que normalmente pueden acelerar entrega de valor de cualquier característica o software funcional y acorta el ciclo de retroalimentación de los usuarios reales. Un equipo de características tendría todas las habilidades para realizar el trabajo necesario a nivel de tarea para realizar el trabajo. En particular, suponiendo una arquitectura de tres niveles, los miembros del equipo trabajarían en tareas relacionadas con las partes de esta historia relacionadas con la GUI, el nivel intermedio y la base de datos.

La gran desventaja de la organización de componentes es obvia: ralentiza el flujo de valor. La mayoría de las funciones del sistema crean dependencias que requieren la cooperación entre los equipos de componentes para construir, implementar y, en última instancia, lanzar. Los equipos pasan gran parte de su tiempo discutiendo las dependencias entre los equipos y probando el comportamiento de los componentes en lugar de poder ofrecer valor al usuario final.