Capítulo 7. Modos de Interacción

Capítulo 7. Modos de Interacción

Topologías de equipo útiles para el flujo

Asignar una topología de equipos no es suficiente

Ver

Solo la colaboración suficiente

Ver

Los tres modos de interacción esenciales

Ver

Los modos de interacción son los hábitos de los equipos

Ver

Enlace

La colaboración: el conductor de la innovación y rápido descubrimiento PERO con fronteras borrosas

DESVENTAJAS

VENTAJAS

RESTRICCIONES

USOS TÍPICOS

X como Servicio: Responsabilidades claras con entrega predecible pero necesita de una buena Gestión de Producto

DESVENTAJAS

VENTAJAS

RESTRICCIONES

USOS TÍPICOS

Facilitando: Sentido y reducción de brechas en capacidades

DESVENTAJAS

VENTAJAS

RESTRICCIONES

USOS TÍPICOS

Modos de interacción de las topologías fundamentales

Las cosas raras que ocurren en la interacción alertan sobre capacidades faltantes o fronteras mal establecidas

Ver

Enlace

Habilidades interpersonales para los modos de interacción

Ver

1. Modo de colaboración
1. Trabajar junto con otro equipo en un tema o iniciativa específica y de manera temporal.
2. Modo de X como Servicio
1. Consumir o proveer un servicio con la mínima colaboración.
3. Modo de facilitación
1. Consiste en ayudar o ser ayudado por otro equipo para eliminar una restricción o impedimento.

La combinación de estos tres modos de interacción se necesita para la mayoría de compañías grandes o de tamaño medio (estos modos ayudan a introducir en pequeñas organizaciones más rápido).

Oportunidades

Contextualiza tu tema

• Planificar la estructura de tu comunicación.
• Jerarquizarla y darle peso visual a lo principal.
• Definir mensajes secundarios con interactividad.
• Establecer un flujo a través del contenido.
• Medir los resultados.

Amenazas

• Responsabilidades compartidas por los equipos
• Más detalle y contexto necesario entre los equipos requiere mayor carga cognitiva
• Posible disminución del rendimiento del equipo comparado con su situación anterior.

Ejemplo 2

Ejemplo 1

Un equipo SA no se ha expresado respeto a una iniciativa de plataforma para proveer un servicio. Eso nos hace preguntarnos:

• ¿El equipo alineado al flujo de valor conoce el valor de lo que estamos desarrollando?
• ¿Estamos generando algo de valor?
• ¿El equipo de SA tiene los skills necesarios para consumir nuestro servicio?.
• ¿La frontera es demasiado ambiciosa?

Un equipo alineado al flujo habla mucho con otro de subsistema complejo al tratar de usar un component, eso nos hace preguntarnos:

• ¿Está bien identificada la frontera?
• ¿El API está bien especificada?
• ¿El API es fácil de usar?
• ¿Falta habilidad o capacidad de UX o DevEX?