Escalar Agilidad: las dependencias entre equipos

Cuando llegué por primera vez a la empresa ACME era lunes a primera hora de la mañana, mientras esperaba en la recepción, lo primero que vi fue un montón de gente reunida en una sala haciendo lo que ellos llamaban “daily meeting”. Allí, en aquella reunión, había veintitantas personas.
Cuando ACME inició su “transformación ágil”, una de las primeras cosas que abordó fue el problema de los equipos multitudinarios. Como ya es bien sabido, un equipo que busca la máxima productividad debería controlar su “peso”, peso medido en número de personas que lo forman, donde la cifra que sirve de referencia es que no sean más de 10, por aquello de que los equipos con mucha gente (más de 7) son menos productivos, unido a lograr que los equipos fueran multifuncionales.
Pero a la hora de dividir ese gran equipo apareció un problema aún mayor que el de haberlo dejado como estaba: las dependencias.
Las dependencias suele ser el problema número uno cuando cuando una organización quiere estructurarse, llamemos, de manera ágil. Las dependencias suelen venir de dos sitios, de las personas o de dependencias por aspectos tecnológicos (como es una arquitectura enrevesada).
Las dependencias de personas vienen cuando hay héroes, personas que concentran exclusivamente el conocimiento sobre algo, el conocimiento para el desarrollo de alguna tarea. Cuando, por hacer números redondos, un equipo de 20 personas se quiere dividir en dos de 10, si hay un héroe, un Rambo, este irá a sólo uno de esos dos nuevos equipos, y aquel equipo en el que Rambo no esté… dependerá siempre para completar sus tareas del equipo donde está el héroe.
En ACME hicimos uso de aquella técnica (adaptada de Crisp y que te conté en los equipos modernos de desarrollo son multifuncionales, así disparan la velocidad y la productividad) de escribir en las columnas de una tabla las principales competencias necesarias para completar el trabajo y en las filas de esa misma tabla los nombres de las personas del equipo. Pusimos un asterisco en aquella casilla donde una, o unas, persona es experta en una competencia, detectando las columnas con un solo asterisco. Así aparecieron los Rambos que limitaban escalar la agilidad.
De hecho, las dependencias son tan importantes que en algunos “frameworks” para escalar agilidad, las dependencias son uno de los puntos clave. Por ejemplo, en Nexus, un marco para escalar Scrum (llevarlo a empresas grandes), las dependencias son una de las tareas claves del “Nexus Integration Team”.
Aunque hagas uso de un framework para escalar la agilidad, las dependencias entre grupos debería ser una de tus primeras prioridades.
Si, es posible evitar que solo unas pocas personas tengan el 100% del conocimiento de un proyecto o tarea, pero hay que ponerse manos a la obra, hay muchas técnicas que tratan sobre ello, ninguna seria se basa en cosas como “documentar”, y aún así no existe la magia y llevan tiempo.
Así que, si estás pensando en escalar la agilidad… ya deberías haberte puesto a trabajar en resolver las dependencias.
Otros post de esta serie:
Escalar agilidad: Liderazgo tribal (1/3). ¿Qué cultura tiene la tribu en la que trabajas?
Escalar Scrum: el Executive Action Team, el Meta-Scrum y Scrum of Scrums
Escalar Scrum: Cuántos Product Owner debería haber

• Acerca de
• Últimas entradas

jgarzas

Ph.D. en informática, Postdoctorado en la Carnegie Mellon (EE.UU) e Ingeniero en Informática.

Primera vez que me tocó hacer una gestión Ágil en una empresa... año 2001. Desde entonces he trabajado en, o para, más de 90. Y he formado a más de 2000 alumnos.

También soy profe de la Universidad Rey Juan Carlos.

Últimas entradas de jgarzas (ver todo)

• Las 3 matrices de priorización Ágil - 19 octubre, 2023
• Etapas del Agile Product Management - 12 octubre, 2023
• Agile Product Management: DINÁMICA «Árbol Solución Oportunidad» + «Valores Esperados» - 5 octubre, 2023