En busca del equilibrio entre empoderamiento y dirección - Parte 2
Estrategias para fomentar colaboraciones.
En la primera parte exploramos cómo la colaboración y la escala impactan en la eficacia organizativa. Vimos que sin colaboraciones efectivas, la creatividad emergente necesaria para manejar la complejidad no se genera, impidiendo que el equipo sea más que la suma de sus partes individuales.
También examinamos las limitaciones de las estructuras estrictamente jerárquicas y discutimos la necesidad de un equilibrio entre dos fuerzas aparentemente contradictorias: la autonomía y la dirección.
En esta segunda parte, nos centraremos en enfoques prácticos para mejorar la cooperación y el empoderamiento dentro de los equipos de producto.
Tejiendo Colaboraciones
A continuación, describiré algunas estrategias y prácticas que pueden ayudar a fortalecer las redes de colaboración. No entraré en detalles exhaustivos sobre ninguna de ellas, sino que destacaré aquellos aspectos de estos enfoques que catalizan la capacidad de respuesta compleja que he intentado postular con el modelo mental definido en la primera parte de este artículo.
Product Trio
Es un enfoque colaborativo en el desarrollo de productos que integra tres roles clave: un líder de producto, un diseñador y un desarrollador. En lugar de reducir la complejidad a la del product leader el trío permite generar respuestas más complejas y adaptativas al abordar los problemas desde diversas perspectivas. Esto no sólo enriquece la solución final, sino que también asegura una mayor alineación con las necesidades del usuario, las demandas del mercado y la viabilidad técnica.
Teresa Torres lo explica en más detalle en The Product Trio.
Programación en grupo
La programación en grupo (ensemble o mob programming) es una evolución de la práctica de programación en parejas (pair programming) de eXtreme Programming (XP) donde varios miembros del equipo trabajan a la vez en una misma tarea. Sólo una persona escribe código siguiendo un diseño consensuado con el resto del equipo. Es una herramienta potente cuando se está arrancando una nueva iniciativa para alinear las decisiones y maximizar la diversidad de experiencias con la consiguiente amplificación de la complejidad de la respuesta.
Propiedad compartida del código
La propiedad compartida del código (Collective ownership) es otra práctica de XP. Propone que cualquier miembro del equipo pueda modificar cualquier parte del código, lo cual democratiza el proceso de desarrollo y elimina los cuellos de botella que podría generar un enfoque más autoritario. Esto no sólo aumenta la eficiencia al distribuir la responsabilidad del diseño del sistema entre todos los integrantes, sino que también enriquece la calidad del producto final, ya que la diversidad de aportaciones y perspectivas puede generar respuestas más complejas y creativas a los problemas.
Desarrollo guiado por consenso
En su charla CDD (Desarrollo dirigido por consenso), Xavi Gost aborda la idea de cómo las decisiones dentro de los equipos de desarrollo de software pueden mejorar al aplicar un marco de consenso. Explica que, en la industria del software, se tiende a aceptar acríticamente las decisiones basadas en la autoridad sin cuestionarlas, lo cual puede inhibir la innovación y la adaptabilidad. Propone utilizar el consenso para tomar decisiones técnicas, asegurando que todo el equipo esté de acuerdo y comprometido. Algunas prácticas que derivan de este enfoque y que aplicamos en Audiense:
Revisión de preocupaciones (concerns review): Durante el día a día, los miembros del equipo registran en un tablero sus inquietudes relacionadas con el diseño del código o la experiencia de desarrollo. En estas reuniones, se busca alcanzar un consenso, priorizando soluciones o tomando decisiones que se documentan en ADRs (Architectural Decision Records).
Revisiones de código grupales: En lugar de imponer que revisiones de código que puedan bloquear el despliegue a producción, seguimos otras prácticas de eXtreme Programming como la mencionada programación en grupo, Test Driven Development (TDD) o Trunk Based Development (TBD), que mitigan la necesidad de dichas revisiones bloqueantes. Periódicamente, se llevan a cabo revisiones de código en las que participa todo el equipo, analizando el estado de la base de código en su conjunto, y no sólo cambios específicos. A estas sesiones también se invita a miembros de otros equipos, fomentando una visión más amplia y colaborativa. Edu Ferro escribió un artículo excelente sobre diferentes estrategias de revisión de código.
Empowered Product Teams
Tener objetivos y principios bien definidos es imprescindible para fomentar la autonomía y el empoderamiento de los equipos, ya que proporcionan un marco claro y consistente para la toma de decisiones independiente y evita la necesidad de micromanagement. Los objetivos claros orientan a los equipos hacia metas específicas sin ser prescriptivos sobre cómo debe lograrse. Frameworks como los OKRs o The North Star pueden ayudar. Los principios definen qué significa hacer las cosas bien para la organización o el equipo y cuidan que los objetivos no se alcancen a cualquier precio. Os dejo un ejemplo de los principios de ingeniería de producto que definimos en Audiense.
En un equipo empoderado, los miembros no sólo ejecutan tareas; también participan activamente en la definición de los problemas a resolver y en la elaboración de estrategias para abordarlos. Este enfoque promueve una cultura de colaboración y responsabilidad compartida, donde la innovación es impulsada por el propio equipo trascendiendo las limitaciones de las organizaciones jerárquicas que vimos en la primera parte.
Liquidez de habilidades
La liquidez de un activo define cómo de fácil es convertir un activo en dinero de manera inmediata y sin perder valor, normalmente para reinvertirlo en otro sitio. La liquidez de un equipo es lo fácil que es que un miembro asuma las tareas de otro. Lo que más reduce la liquidez es la falta de conocimiento para hacer esas tareas. No hablamos solo de conocimiento técnico, sino también de negocio.
— Luis Artola. Software Economics
La formación debe ser una labor de equipo. Técnicas como Delivery Mapping, Capability Profile Mapping o Matrices de Competencias (otro) son herramientas que permiten inventariar lo que sabemos y la capacidad que tenemos como equipo para hacer frente a los problemas. Este mapeo de conocimientos y capacidades facilita la liquidez de personas y habilidades, permitiendo que se puedan reasignar miembros a equipos donde sean más necesarios o donde puedan ofrecer o recibir mentoría entre equipos.
Relacionado con esto, las Comunidades de Práctica (CoP) ofrecen un espacio donde los miembros de diferentes equipos pueden elevar su nivel de habilidades colectivamente. Estas comunidades se basan en la práctica deliberada y en la validación de buenas prácticas. Son grupos organizados que fomentan el aprendizaje continuo y la mejora de habilidades a través del intercambio de conocimientos y experiencias.
Todo esto contribuye al fortalecimiento de la capacidad adaptativa de toda la organización asegurando una reserva de talento versátil listo para fluir hacia donde se necesite, similar a cómo el capital líquido se mueve hacia oportunidades de inversión. En próximas entregas escribiré sobre como estoy llevando a la práctica esto en Audiense.
Event storming
Event storming es un técnica de modelado diseñada por Alberto Brandolini que se centra en identificar «eventos de dominio» dentro del contexto del dominio del negocio. Reúne a expertos de diferentes áreas (desarrolladores, expertos en el negocio, UX/UI designers, y otros stakeholders) para asegurar una visión integral y completa del sistema o proceso. El proceso es altamente interactivo y se centra en el descubrimiento y la exploración de la lógica del negocio, flujos de trabajo, y problemas potenciales. Es otra forma de romper jerarquías y tejer redes interdepartamentales para solucionar problemas complejos.
Lenguaje Ubicuo
Uno de los resultados clave del Event Storming es el Ubiquitous Language, un término acuñado por Eric Evans en su libro “Domain-Driven Design – Tackling Complexity in the Heart of Software”. Este concepto se refiere al desarrollo de un lenguaje común compartido no solo por el equipo de desarrollo y los expertos del dominio, sino también por todos los participantes en un proyecto.
El objetivo del Lenguaje Ubicuo es asegurar que todos los miembros del equipo —desde programadores hasta gestores de proyecto— hablen el mismo idioma técnico y de negocios.
Cultura DevOps y Team Topologies
La cultura DevOps se enfoca en optimizar el flujo de valor desde una perspectiva integral y romper los silos entre departamentos. Facilita conexiones más eficientes entre equipos lo que promueve respuestas más complejas. Además, marcos como Team Topologies ofrecen una combinación de principios y prácticas que fomentan estructuras organizativas que facilitan un flujo de trabajo rápido y eficiente, ayudando a las organizaciones a superar jerarquías restrictivas y potenciar un entorno donde la innovación colectiva pueda prosperar.
Lean Software Development
El Desarrollo de Software Lean es una metodología que se enfoca en maximizar el valor para el cliente mediante la minimización de desperdicios y la mejora de la eficiencia en los procesos de desarrollo. Se inspira en los principios del Sistema de Producción Toyota, adaptándolos al contexto del desarrollo de software. Algunos de los principios relacionados con el trazado de lazos de colaboración incluyen:
Crear conocimiento: Abrazando el cambio y adaptándonos usando prácticas de desarrollo ágil como las mencionadas más arriba.
Eliminar el desperdicio: Entre otras vías limitando el trabajo en progreso (WIP) lo que entre otros beneficios termina fomentando el trabajo en equipo vía prácticas de desarrollo ágil antes mencionadas.
Respetar a las personas: Crear un entorno de trabajo que valore el respeto mutuo y la colaboración entre todos los involucrados en el proceso de desarrollo.
Eduardo Ferro está explorando estos temas en profundidad en una serie de posts sobre desarrollo Lean.
Organizaciones Teal, Sociocracia 3.0, Holocracia
Ya a un nivel de abstracción superior, paradigmas como las Organizaciones Teal, Sociocracia 3.0 y Holocracia representan palancas de cambio que requieren una alineación no sólo de los miembros de una organización, sino también de sus directivos y accionistas. Estos modelos buscan transformar radicalmente las estructuras tradicionales, promoviendo una mayor autogestión y distribución de poder. Este es un tema sobre el cual quiero profundizar más y sé que la intersección con los temas que trato en esta entrega es grande. Tengo pendiente leer Reinventar las organizaciones de Frederic Laloux y estoy seguro que me llevará a volver a escribir sobre esto.
Os dejo un par de artículos por si os interesa profundizar más:
Conclusiones
He estado implementando muchos de estos enfoques durante varios años, pero solo recientemente he comprendido el importante papel que juegan en facilitar la emergencia de la complejidad necesaria para responder adecuadamente a la complejidad de nuestro entorno. Espero poder dedicar alguna entrega adicional a mis aprendizajes, especialmente desde que el crecimiento del equipo de 0 a varias decenas de personas me ha obligado a delegar más.
Desde que leí a Bar-Yam, mi obsesión es asegurarme de que la creatividad de mis equipos escale y supere mis limitaciones. Cierro el post como lo comencé, con otra cita suya que resume perfectamente esta discusión:
Nuestra experiencia en la organización de personas es para problemas a gran escala que no son muy complejos. En este caso, la necesidad de muchas personas surge porque muchos individuos deben hacer lo mismo para lograr un gran impacto. En esta vieja razón para organizar personas, una jerarquía funciona porque está diseñada para amplificar lo que una sola persona sabe y quiere hacer. Sin embargo, las jerarquías (y muchas modificaciones de ellas) no pueden realizar tareas complejas ni resolver problemas complejos. Descomponer (subdividir) una tarea compleja no es como descomponer una tarea a gran escala. El desafío de resolver problemas complejos, por lo tanto, nos exige entender cómo organizar a las personas para un comportamiento colectivo y complejo.
— Yaneer Bar-Yam. Making Things Work: Solving Complex Problems in a Complex World
Si has llegado hasta aquí y crees que esta perspectiva puede ayudar a otras personas a comprender el valor de los enfoques que listo, te agradecería que lo compartas. Además cualquier interacción con el artículo me da pistas de si estos temas son de interés 🙏🏼.