Team Topologies, una biblia de organización de equipos

La necesidad de revitalizar organizaciones que han crecido hasta atrofiar las estructuras que les fueron útiles cuando eran pequeñas es universal. Lo que sirve para que un único equipo rinda óptimamente no sirve para que lo hagan tres equipos, pero si la organización es buena la cosa sigue tirando. Conforme se añade complejidad técnica y, sobre todo, humana a la organización la idea original está cada vez menos adaptada a la necesidad de un grupo de trabajo cada vez mayor. Aquí es donde nos encontramos con las transformaciones.

Vamos a acometer una transformación. Cinco de las palabras más terribles del lenguaje corporativo. Por supuesto, todo el mundo está dispuesto a cobrarte por ayudarte a hacerlo. Gurús vendiendo agilismo como quien vende crecepelos, sin acometer el problema raíz ni esperarse el tiempo suficiente para que, cuando la cosa no funcione del todo, te exijan rendir cuentas.

Team Topologies trata estos temas y diría que son los mejores veinte euros que me he gastado en meses. Sin ambajes ni dudas. Es un libro que va al grano, en apenas 200 páginas te da algunas buenas ideas sobre el espinoso tema, haciendo hincapié en la transparencia a la hora de decidir la topología asignada a un equipo. Básicamente el hacerlo así establece un contrato implícito entre equipos, que saben perfectamente lo que pueden esperar de los otros equipos (si es proveer algo como servicio, mentorización, facilitación por un periodo corto de tiempo, o colaboración al uso).

Ley de Conway

Posiblemente el mayor hallazgo sea el de la ley de Conway, denominada así en honor a Melvin Conway, que fue quien la enunció:

Las organizaciones dedicadas al diseño de sistemas […] están abocadas a producir diseños que son copias de las estructuras de comunicación de dichas organizaciones

Básicamente, si tienes muchos equipos supuestamente independientes pero toda las capacidades de bases de datos las delegan en otro equipo adicional, sus sistemas terminarán estando bastante entrelazados en ese punto.

Con todo, lo más relevante de la ley de Conway es la oportunidad de hacerle ingeniería inversa. Luchar a contracorriente es difícil, Conway terminará imponiéndose, así que, ¿y si configuramos los equipos de entrada de forma que esa organización condicione de forma implícita el establecimiento de la arquitectura que queremos para nuestra solución a futuro?

Como digo, éste es solo un ejemplo. El libro entero lo he disfrutado muchísimo. Si te interesan estos temas o necesitas lidiar con ellos aunque preferirías estar haciendo otra cosa, seguramente un libro esencial al que sacar mucho partido.

Jose Alcántara
Resolviendo problemas mediante ciencia, software y tecnología. Hice un doctorado especializado en desarrollo de hardware para análisis químico. Especialista en desarrollo agile de software. Más sobre Jose Alcántara.
Este blog usa cookies para su funcionamiento.    Más información
Privacidad