Desde mi experiencia, un equipo de desarrollo de software realmente empoderado es aquel que tiene la capacidad de impactar de principio a fin en todo el Flujo de Valor (value stream). Este equipo, partiendo de una idea o de la identificación de un problema (incluso descubriendo el problema junto a sus usuarios), asume la responsabilidad de entregar valor a esos clientes. Este valor no se limita a crear nuevas funcionalidades, sino que también incluye proteger lo ya construido, minimizar el costo de desarrollos innecesarios y fomentar capacidades que ayuden a alcanzar los objetivos del negocio de manera eficiente y efectiva. La responsabilidad extremo a extremo implica evolución, operación y mantenimiento continuo de lo que hayan construido, tomando pleno 'ownership' de su desarrollo.
Los flujos de valor pueden dirigirse tanto a clientes externos como a otros equipos o departamentos dentro de una empresa. En Alea Soluciones mi equipo se hacia cargo del flujo de valor al cliente final (software de gestiĂłn/telefonĂa/tv/internet para operadores de telecomunicaciones) y el flujo de valor para herramientas que aceleraban y ayudaban a otro departamento encargado de los despliegues de redes y operaciĂłn de la red fĂsica. En The Motion nuestro flujo de valor era para el usuario final de nuestro producto. Y tanto en Nextail, como actualmente en Clarity AI, mis equipos (team topologies: equipos de plataforma) son responsables de Flujos de Valor internos que tienen el objetivo de acelerar/habilitar otros equipos encargados de Flujos de Valor a nuestros clientes finales (team topologies: Stream Aligned teams).
Por lo tanto, este empoderamiento, desde la idea hasta la entrega y el mantenimiento del valor, se realiza siempre dentro de un flujo de valor, ya sea interno o externo. En las empresas, suele haber una combinaciĂłn de ambos tipos de flujos de valor.
Como bien describe John Cutler, estos son los llamados Product Teams.
Product Engineers / OrientaciĂłn a impacto
La mentalidad y cultura que siempre he intentado promover ha sido la que ahora parece estar de moda: el pensamiento de "Product Engineers". Es decir, formar equipos que no se limiten a ejecutar tareas asignadas por un manager o por el área de Producto, sino que se conviertan en verdaderos buscadores de oportunidades, resolutores de problemas y generadores de valor. Estos equipos trabajan para, a partir de un problema identificado, o del descubrimiento de los problemas a resolver, ofrecer la mejor solución posible y evolucionando de forma progresiva mediante el feedback del usuario y del propio sistema desarrollado. Todo esto se hace siempre desde la perspectiva del cliente final, teniendo en cuenta tanto el corto como el largo plazo. Solo pensar en el corto plazo puede llevar a no proteger esa capacidad de seguir entregando valor indefinidamente con nuevas evoluciones sobre el software entregado.
Por dar algunos ejemplos prácticos, en Alea Soluciones, todo el equipo se iba rotando para hablar con cliente, dar soporte, o tener reuniones con el CEO y los responsables de otros departamentos. Todos nos involucrábamos en entender por quĂ© hacĂamos las cosas, cual era el impacto que buscábamos, y con ese conocimiento, podĂamos desarrollar de forma evolutiva las soluciones que se iban adaptando a ese impacto buscado. Esto nos permitĂa aprender de nuestro negocio, y cada vez dar mejores soluciones.
En Clarity AI, dentro de los equipos de Plataforma, hemos hecho muchas entrevistas a usuarios internos, usado encuestas, desarrollos conjuntos con los equipos interesados o programas de betatesters y champions, cuando hemos desarrollado algún producto interno nuevo. También solemos hacer rotaciones para el soporte para que todo el mundo tenga contacto con el uso y las necesidades de nuestros clientes.
Como conseguir esta mentalidad
Al final se trata de conseguir moldear la cultura del equipo, que dicho a si suena fácil, pero que dirĂa que es lo más difĂcil y da para multitud de libros.
En mi caso, y como estamos viendo en esta serie de articulos, el desarrollo de software lean, está orientado a conseguir esta cultura, que maximiza el valor (desde el punto de vista del cliente), minimiza el desperdicio y de forma natural se orienta el cliente.
Lo que me ha funcionado en el pasado para ayudarme a contruir este tipo de culturas ha sido:
- Tenerlo muy en cuenta en la contrataciĂłn, haciendo preguntas especificas sobre producto, impacto de lo que ha hecho en el pasado. Intentando identificar si ve el software como un medio o como un fin en si mismo.
- TambiĂ©n en el proceso de contrataciĂłn intento identificar empatia por el usuario, y foco en la calidad y el testing, puesto que me parecen puntos muy relacionados con ese espĂritu de aportar valor de forma sostenida.
- Conseguir siempre una masa crĂtica de miembros que ya tengan esa mentalidad para que se pueda expandir. En algunos casos eso ha implicado tener gente temporalmente con esa experiencia o traer externos para conseguir esa masa critica.
- Hacer trainings sobre vertical slicing, temas de producto, temas de DDD haciendo hincapié en lenguaje ubicuo, dominios, etc
- Coaching técnico, trainings y colaboraciones con gente que ya tienen esa mentalidad (en mi caso, he podido hacerlo con Carlos Ble, Modesto San Juan, Alfredo Casado, Xavi Gost, Aitor Sanz, Codium, etc) y tengo siempre en el radar ciertas empresas que se que pueden traer esa mentalidad por si se da la oportunidad de colaborar (Codium, 540, Leanmind, Code Sherpas, Codesai, tech93, etc).
- Y por Ăşltimo, lo que algunos consideran mi superpoder: Ser un puñetero PESAO, repitiendo todo el rato el mismo mensaje… sobre el foco en el usuario, la calidad sostenida, buscar el impacto, etc.
Equipos empoderados, el balance, y la confianza
Para que un equipo esté realmente empoderado, debe tener la capacidad de decidir en qué y cómo trabaja, siempre de forma alineada con las necesidades de la organización. Esto implica poder equilibrar adecuadamente el corto, medio y largo plazo, asà como balancear cambios de comportamiento (funcionalidades) con cambios de estructura (mejoras de diseño o cambios de arquitectura).
Si el equipo no tiene esta capacidad y es un ente externo quien decide en qué deben trabajar en cada momento, sin una discusión real al respecto, lo más común es que surjan problemas como:
- Una falta de equilibrio en las prioridades, que se traduce con el tiempo en una ralentizaciĂłn del equipo.
- La acumulación de deuda técnica o una disminución en la calidad del código.
- La incorporaciĂłn de nuevas funcionalidades sin una evoluciĂłn correspondiente en la arquitectura del sistema.
En mi experiencia, la manera de conseguir que el equipo pueda tomar estas decisiones implica:
- Ganarse la confianza de la organizaciĂłn trabajando de forma responsable y alineada con las necesidades del negocio.
- Realizar entregas rápidas y en pasos pequeños, lo que permite mucho más fácilmente mezclar de forma continua pequeños cambios de comportamiento con cambios de estructura. De forma que el valor al usuario sea un flujo continuo, mientras protegemos la evolución y sostenibilidad del propio sistema.
Como estamos viendo en esta serie de forma natural Lean Software Development y Extreme Programming nos llevan a trabajar de estar forma (pasos pequeños, maximizando valor).
En Ăşltima instancia, Lean Software Development busca crear bucles de retroalimentaciĂłn positivos, donde:
- El impacto generado en pequeños pasos refuerza la confianza de la organización.
- Esta confianza se traduce en mayor autonomĂa para el equipo.
- La autonomĂa permite tomar mejores decisiones y mejorar continuamente nuestra forma de trabajar (Kaizen).
Si el equipo inicialmente no está realmente empoderado, está en nuestras manos analizar la situaciĂłn y proponer o implementar pequeños cambios para mejorarla. Lo más importante en este proceso es ganarse la confianza de la organizaciĂłn, ya que esto es lo que permite acelerar ese cambio hacia el empoderamiento. Al fin y al cabo, nadie va a dar más autonomĂa si el equipo no demuestra, paso a paso, que es responsable y que busca sistemáticamente lograr un impacto positivo.
AsĂ como en Lean se crea un bucle de refuerzo positivo en el que:
- Ganamos más autonomĂa, lo cual nos permite tener mayor impacto, y
- Este impacto genera aĂşn más autonomĂa para el equipo,
también existen bucle de refuerzo negativo. En este caso:
- Si el equipo no logra entregar de manera frecuente o con la calidad necesaria, la organizaciĂłn confĂa menos en Ă©l.
- Esa falta de confianza reduce la capacidad del equipo para tomar decisiones, disminuyendo su autonomĂa.
- A su vez, esto reduce las oportunidades de mejorar la frecuencia de entrega y la calidad, perpetuando el ciclo negativo.
Empoderamiento y arquitectura
Tal y como hemos comentado que un equipo esté empoderado implica que tenga responsabilidad extremo a extremo desde la idea hasta la puesta en producción y operación de las soluciones que desarrolle. Para que esto se produzca de una forma efectiva se tiene que conseguir:
- No tener dependencias (o las mĂnimas) de otros equipos. Y en caso de tenerlas, que existan interfaces y reglas claras para coordinar el trabajo generando los menores bloqueos posibles.
- Que trabajemos en un entorno y con una plataforma que nos permita de forma autĂłnoma desplegar y operar en producciĂłn nuestras soluciones.
Por supuesto, todos sabemos que estos requisitos no es algo que nos suele venir dado sino que tenemos que invertir esfuerzo de forma consciente y continua en:
- Eliminar dependencias con otros equipos y diseñar nuestras soluciones intentando no generar nuevas.
- Que nuestra plataforma de desarrollo, despliegue y operaciĂłn mejore de forma continua y sea robusta. Lo podrĂamos ver como un esfuerzo consciente en hacer que nuestro lugar de trabajo sea un sitio habitable, reconociendo al mismo tiempo que si no invertimos en ello, se degradarĂa continuamente.
Aquà comparto algunas prácticas concretas que me han funcionado en distintos equipos:
- Mantener un ritmo sostenible (práctica de eXtreme Programming) y dar espacio para la mejora continua y la experimentaciĂłn. Es fundamental evitar que el equipo estĂ© siempre al lĂmite de su capacidad, de modo que exista una cierta holgura para abordar mejoras internas o explorar nuevas ideas.
- Aplicar los conceptos de "bounded context" de Domain-Driven Design (DDD) para dividir la arquitectura según criterios de negocio/dominio, en lugar de hacerlo por componentes técnicos.
- Evitar equipos de QA separados y asignar la responsabilidad sobre la calidad externa al propio equipo. Es posible que haya perfiles especializados en calidad, pero la responsabilidad debe ser compartida por todo el equipo.
- Introducir el principio de “You build it, You run it”, eliminando la necesidad de un equipo separado de operaciones. Esto fomenta que el equipo asuma la responsabilidad tanto de la creaciĂłn de la soluciĂłn como de su operaciĂłn.
- Invertir en observabilidad y monitorización, tanto desde la perspectiva de producto como desde el aspecto técnico, para asegurar un mejor entendimiento del rendimiento y los problemas.
- Absorber el trabajo de otros equipos si esto permite eliminar dependencias. Esto debe hacerse considerando los conocimientos necesarios y el volumen de trabajo, pero en muchas ocasiones resulta más efectivo adquirir esos conocimientos y automatizar ciertas tareas para poder asumirlas y, asĂ, eliminar la dependencia.
- Trabajar en pasos pequeños (vertical slicing, automatización/optimización de pipelines de despliegue, pruebas exhaustivas, etc.), lo que facilita la entrega continua y reduce el riesgo en cada cambio.
Equipos NO empoderados
En algunos casos, la organizaciĂłn o la cultura de la empresa es el mayor impedimento para el empoderamiento de los equipos. Los escenarios más tĂpicos que me he encontrado son:
- División por especialidades y funciones: Cuando la organización se estructura en áreas separadas como frontend, backend, operaciones, QA, etc., lo cual dificulta la colaboración y el empoderamiento de los equipos.
- Equipos como "feature factories": Aunque existen equipos multidisciplinares hasta cierto punto, a menudo se ven como simples ejecutores de las soluciones decididas desde Producto o Negocio, sin autonomĂa real en la toma de decisiones.
- Equipos multidisciplinares con responsabilidades tĂ©cnicas: A veces se intenta crear equipos multidisciplinares, pero sus responsabilidades se asignan en funciĂłn de componentes divididos por criterios tĂ©cnicos y no de negocio. Esto significa que cualquier funcionalidad requiere la coordinaciĂłn de varios equipos, limitando la agilidad y la autonomĂa de cada uno.
Si este tipo de enfoques es el status quo en nuestra organización, no hay otra opción: debe cambiar. Afortunadamente, en nuestra industria ya existe mucho material sobre cómo organizar equipos, las ventajas e inconvenientes de cada tipo de estructura, la relación entre arquitectura de software y organización de equipos, y la gestión de equipos. En este sentido, considero interesantes conceptos como Team Topologies, los patrones estratégicos de Domain-Driven Design (DDD), la ley de Conway, el modelo de cambio de Kotter, el System Thinking o pensamiento sistémico, y los sistemas socio-técnicos.
Por experiencia, os digo que esperar a que los cambios sucedan mágicamente (spoiler: no suceden) no es buena idea. Cuando he visto la necesidad de un cambio, he sido yo mismo quien lo ha impulsado. Os sorprenderĂa la cantidad de cosas que se pueden hacer sin pedir permiso.
Ejemplos y experiencias
Alea Soluciones
En mi experiencia en Alea Soluciones, tuvimos una autonomĂa prácticamente completa, no solo en cuanto a decidir en quĂ© trabajar, sino tambiĂ©n en cĂłmo implementar nuestras soluciones. Coordinábamos directamente con el CEO y con los responsables de departamentos clave, y todas las decisiones sobre producto y organizaciĂłn recaĂan en nuestro equipo. PartĂamos siempre de la estrategia general de la empresa, integrando el feedback continuo de nuestros clientes, tanto internos como externos. Además, nuestra metodologĂa de trabajo era completamente nuestra, evolucionando constantemente dentro de un proceso de mejora continua. Incluso tenĂamos la libertad de decidir sobre la contrataciĂłn de nuevos miembros del equipo, siempre dentro de los presupuestos acordados con la empresa.
Esa autonomĂa/empoderamiento fue completamente buscado, y para conseguirlo hicimos cosas como:
- Ganar poco a poco la confianza del resto de la empresa mediante la entrega de soluciones de calidad que tenĂan un impacto significativo.
- Asumir trabajo anteriormente de otros departamentos para poder quitar dependencias.
- Promover la multidisciplinariedad de los miembros del equipo para evitar silos.
The Motion
En The Motion, aunque tenĂamos un alto nivel de empoderamiento, al inicio las funciones de producto y diseño/UX estaban separadas y trabajaban con varios meses de desfase respecto al resto del equipo. Este modelo, orientado principalmente al backend para la generaciĂłn de videos publicitarios, funcionaba bien en un principio y no generaba fricciones. Sin embargo, a medida que el producto empezĂł a requerir interfaces de configuraciĂłn y administraciĂłn, este desfase comenzĂł a resultar problemático.
Con la evoluciĂłn de la organizaciĂłn, incorporamos perfiles con habilidades en frontend y maquetaciĂłn, con gran sensibilidad hacia el desarrollo de producto y el diseño visual. TambiĂ©n se sumĂł un diseñador con experiencia en maquetaciĂłn web, lo que facilitĂł una evoluciĂłn progresiva del diseño. En la mayorĂa de los casos, trabajábamos en pairing entre el diseñador y un desarrollador frontend, permitiĂ©ndonos avanzar en pequeños incrementos y eliminar los retrasos iniciales. Este cambio nos dio mayor autonomĂa y mejor sincronizaciĂłn entre diseño y desarrollo.
Clarity AI
Los equipos que he creado desde que estoy en Clarity AI han nacido con la idea de responsabilidad extremo a extremo desde el principio, lo que me ha permitido disfrutar de las ventajas de equipos empoderados desde el inicio.
Cuando me unĂ en 2020, ya estaba en marcha un proceso para crear equipos multidisciplinares, aunque las lĂneas de reporte seguĂan organizadas por perfiles (frontend, backend, data engineering y cloud/sistemas). Este cambio hacia equipos multidisciplinares resonaba con mi forma de pensar, y me unĂ al equipo de liderazgo en tecnologĂa para acelerar esta transformaciĂłn siguiendo las ideas de Team Topologies. En los meses siguientes, ajustamos las lĂneas de reporte, redefinimos las funciones de las guilds para que funcionaran más como comunidades de práctica y adaptamos el plan de carrera de ingenierĂa para alinearlo con la nueva estructura. Esta nueva forma de trabajar nos permitiĂł soportar un crecimiento acelerado, en el que fuimos creando tanto equipos multidisciplinares alineados a flujos (stream-aligned) como de plataforma.
A dĂa de hoy, aunque ha llevado tiempo, los equipos son muy autĂłnomos y tienen una responsabilidad casi completa de extremo a extremo. En Clarity AI, varios de estos equipos necesitan conocimiento especializado sobre sostenibilidad, y estamos trabajando en incorporar ese conocimiento de la mejor manera posible para potenciar aĂşn más su empoderamiento.
Además, hemos incluido en nuestros principios de ingenierĂa varios enfoques que refuerzan la responsabilidad extremo a extremo de los equipos: “You Build It, You Run It,” “Squad Autonomy Over Standardization,” y “Flow-Driven Product Delivery.”
AplicaciĂłn de los Principios Lean
Empoderar a los equipos no solo es una estrategia efectiva de organizaciĂłn, sino que tambiĂ©n representa la esencia de los principios Lean. Al reducir aprobaciones y traspasos innecesarios, eliminamos el desperdicio, permitiendo que el equipo se enfoque en lo esencial y agilice su trabajo sin obstáculos burocráticos. Este enfoque refuerza el aprendizaje continuo, ya que el equipo puede experimentar y adaptarse rápidamente, desarrollando un conocimiento profundo y compartido de sus propios procesos y resultados. Al mismo tiempo, la autonomĂa facilita una toma de decisiones rápida, eliminando los cuellos de botella que suelen ralentizar el desarrollo, lo cual nos permite entregar valor de forma mucho más ágil. La calidad se convierte en una responsabilidad compartida y arraigada en el equipo, que adquiere la confianza necesaria para mantener altos estándares sin depender de revisiones externas.
Al aplicar estos principios Lean, se crea un entorno de desarrollo de software más eficiente, adaptable e innovador, que no solo acelera la entrega de valor, sino que también se adapta de manera natural al trabajo en pasos pequeños, permitiendo que la mejora continua y la excelencia técnica se conviertan en una parte inherente del trabajo diario del equipo.
Referencias y enlaces relacionados
Gracias:
Este artĂculo ha sido mejorado con el feedback de: