¿Porqué Scrum se basa en equipos funcionales?

Los equipos funcionales son equipos que están compuestos por miembros con las diferentes habilidades y especialidades necesarias para poder construir funcionalidades, componentes de sistemas o historias de usuario de principio a fin. Son equipos con continuidad a largo plazo de entre 3 a 9 miembros colocalizados que se mantienen unidos e integrados para un mayor rendimiento, y aunque los miembros puedan tener habilidades especializadas y áreas en las que estén más enfocados, la responsabilidad recae en el equipo como un todo.

A diferencia de estos, los equipos de componentes están formados por grupos, usualmente temporales, de personas cuya área principal de preocupación se centra en un componente específico o conjunto de componentes del sistema, con una responsabilidad individual sobre "su" parte según su especialización.

Actualmente estoy realizando un curso de LeSS en on-line con Gene Gendel, y la siguiente imagen me inspiró a ver la importancia de los equipos funcionales desde la perspectiva de donde se encuentre la complejidad.

Equipos de componentes versus equipos funcionales - Feature Teams

La complejidad en los equipos de componentes se encuentra entre la pila de poducto y los equipos, en como los equipos toman los elementos de la pila y que dada a su especialización tienen que coordinarse para pasarse el elemento de uno a otro. Usualmente habrá un Propietario del Proyecto focalizado en distribuir y coordinar estos elementos entre los equipos; intentará optimizar el flujo entre equipos, gestionar las dependencias y lidiar con bloqueos y cuellos de botella, en vez de focalizarse en el valor que aportan los elementos al usuario/cliente. Esto por ende convertirá al Propietario de Producto en un gestor de complejidad en forma de jefe de proyecto.

Dado que los equipos de componentes son especializados y se les medirá por las tareas de su especialidad, su interés por colaborar será mínimo y prácticas colaborativas como Sprint Planning 1, Big Room Planning o PI Planning, que podrían resolver la complejidad, no funcionarán.

En el caso de los equipos funcionales, que construyen los elementos de la pila de producto de principio a fin, el Propietario del Producto no ha de preocupare de qué equipo construye qué, y puede focalizarse en la pila, en interactuar con usuarios/clientes y maximizar el valor de negocio. La complejidad está entre los equipos y las funcionalidades o componentes a construir, cuando varios equipos trabajan al mismo tiempo en las mismas funcionalidades o componentes.

Pero esa complejidad tiene solución con técnicas y prácticas conocidas desde hace tiempo con eXtreme Programming y ahora con DevOps. La integración continua facilita la propiedad del código compartido, las pruebas automatizadas aseguran que los componentes sigan comportándose como es esperado después de cada cambio, los despliegues por lotes pequeños que permite DevOps rebajan el riesgo de despliegues fallidos, y su posible impacto, de forma dramática... y quizá debamos de recalcar que las automatizaciones, si están bien implantadas, no fallan nunca, en cambio, el ser humano en su naturaleza, cuyo valor es su creatividad y emocionalidad, es limitado en la amplitud de lo que pueda percibir y abarcar en un mismo momento, y comete errores en cuestiones repetitivas y no motivantes.