¿Hay alguna dinámica para experimentar la creación de equipos según Team Topologies?

Team Topologies de Skelton y Pais

Para Agility Tres60 2021 Alex y yo preparamos una sesión de Team Topologies; dimos una breve introducción y luego efectuamos una dinámica que queremos compartir en este post.

Primero hablemos de Team Topologies; se trata de una guía práctica para formar equipos de software y permitir que superen sus retos, o para ayudar a equipos existentes a ser más efectivos en la entrega de valor. Describe los patrones organizacionales para la estructura de equipos y sus formas de interacción.

Recordemos las estructuras de equipos:

• Stream-Aligned Team: Es el tipo de equipo fundamental. Está alineado con parte del flujo de valor de negocio y tiene la responsabilidad de principio a fin del diseño, desarrollo, despliegue, soporte y retirada del producto o servicio, así como de los ciclos de feedback asociados.
• Platform Team: Su función es reducir la carga cognitiva de los Stream-Aligned Teams a través de, por ejemplo, ofrecer IaaS o PaaS.
• Enabling Team: Es un proveedor de servicios, por lo general de carácter temporal, y sirve para hacer más efectivos y mejorar las habilidades de los Stream-Aligned Teams, y también detectar si hay brechas en la plataforma o en lo que se espera que hagan estos equipos.
• Complicated-Subsystem Team: Equipo especializado que reduce la carga cognitiva de los Stream-Aligned Teams. Hacen cosas que requieren conocimiento, experiencia o habilidades muy específicas o sofisticadas, por ejemplo modelos matemáticos, simulaciones, etc.

Y las diferentes formas de interacción:

• Collaboration: Consiste en trabajar o colaborar muy cercanamente a otro equipo.
• X as a Service: Proveer algo como un servicio con una mínima colaboración. Los roles involucrados en este tipo de interacción son: Proveer algo y Consumir algo.
• Facilitating: Ayudar (o hacer coaching) o ser ayudado por otro equipo para eliminar impedimentos.

Team Topologies trata de gestionar la carga cognitiva limitando el tamaño de los servicios y/o productos de software que los equipos puedan manejar. Adopta "Team-First Approach" para establecer los límites del software. Cada servicio o producto debe de ser "propiedad" de un equipo con suficiente capacidad cognitiva para construirlo y operarlo. Trata de equipos pequeños multifuncionales, entre 3 y 9 miembros, cohesionados y longevos que trabajan sobre el mismo conjunto de problemas de negocio durante largo tiempo. Esto se materializa:

• Limitando los dominios de responsabilidad
• Limitando el numero de aplicaciones que operan
• Limitando el número de herramientas que necesitan manejar

Para asignar equipos a dominios:

• Asignar cada dominio a un único equipo, si de dominio es muy grande para un solo equipo, dividirlo en subdominios y asignar cada uno a un solo equipo
• Un equipo debe ser capaz de trabajar con dos o tres dominios simples
• Un equipo que es responsable de un dominio complejo no debe tener otros dominios asignados
• Evitar que un único equipo sea responsable de dos dominios complicados

Para quién quiera saber un poco más aquí os dejamos una ficha de referencia rápida que Henry Portman ha diseñado y comparte con todos:

Quick Reference Card de Henny Portman traducida por Emiliano Sutil - Thank you!!!

Para la dinámica partimos de un contexto "tradicional" con el objetivo de estructurar equipos e interacciones de forma alineada con Team Topologies. El contexto es el que sigue, también lo podéis descargar en pdf.

---

La empresa "Conoce el mundo con Gertru y Alex" es una plataforma online de viajes y aventuras que provee los siguientes servicios:

• Vacaciones en con niños en resorts familiares
• Viajes exóticos a países lejanos
• Aventuras con mascotas
• Rutas gastronómicas

Tiene un área de IT cuya misión es desarrollar y mantener los sistemas y aplicaciones que permiten la operación de la empresa, y está organizado de la siguiente manera:

• Departamento de Análisis
• Departamento de Desarrollo
• Departamento de QA
• Departamento de Operaciones

Una de sus realidades complejas que tiene que enfrentar son las interfaces con las aerolíneas y los hoteles.

Este departamento tiene entre otros, los siguientes problemas:

• Tiempos de desarrollo muy largos con muchos bugs
• Su frecuencia de despliegue es muy baja
• El nivel de satisfacción de los usuarios es muy bajo

Por esto la empresa ha decidido iniciar una transformación ágil incorporando un equipo de Agile Coaches para, entre otras cosas, reorganizar el área con base en la propuesta de Team Topologies.

---

La dinámica se efectúa sobre un tablero, en nuestro caso utilizamos Miro, en el que en la parte izquierda se muestra la organización por áreas (silos) tal como se describe en el contexto, y en la parte derecha tenemos un área en la que los asistentes trabajan la reorganización. Para los 4 tipos de equipos hay preparados rectángulos con los colores correspondientes, así como elementos de dibujo para los 3 tipos de interacciones. También hemos puesto una chuleta para tipos de equipos e interacciones.

Tablero listo para ser usado

Leyenda perfiles

Las personas las hemos representado con emoticonos, algunos de ellos para poner una nota de humor en la dinámica. :-)

En la situación inicial las personas están distribuidas y organizadas en sus áreas correspondientes, excepto los Agile Coaches que son nuevos y van a ser los responsables de implantar la reorganización.

La misión de los participantes en la dinámica es reestructurar equipos e interacciones mediante la aplicación de Team Topologies.

Algunas pistas para el facilitador:

• Cada servicio debería de tener al menos un Stream-Aligned Team
• Si el software corriera en la nube tendríamos un Platform Team de cloud
• La complejidad de los interfaces con las aerolíneas y los hoteles podría requerir un Complicated-Subsystem Team
• Los Agile Coaches que impulsan la reorganización serían un Enabling Team

Dinámica en acción en Agility Tres60, gracias a los participantes