Redescubriendo el Poder del Manifiesto Ágil para Formar Equipos de Producto Empoderados
En este artículo, exploro cómo cada principio del Manifiesto Ágil contribuye a la formación de equipos empoderados, revisando su poder y relevancia en el proceso.
La mayoría de los equipos de producto aspiran a trabajar en un entorno Agile. Sin embargo, lograr esto no es tarea sencilla, ya que implica que numerosas piezas deben encajar simultáneamente. Cuando asesoro a equipos, suelo plantear una pregunta: "¿Habéis leído los principios del Manifiesto Agile?" Sorprendentemente, la mayoría de las veces la respuesta es negativa, o admiten haberlo leído pero no recordar su contenido. Si Agile es el cimiento y los principios sobre los que basamos nuestro trabajo, es imprescindible que los tengamos firmemente arraigados en nuestra práctica diaria.
Recuerdo un día, hace varios años, cuando decidí releer el Manifiesto Agile. Para ese entonces, ya había leído y aplicado las enseñanzas de "Inspired" y "Empowered" de Marty Cagan a mis equipos. La conclusión que tuve fue: ¡El Manifiesto Agile – del año 2001 – ya nos indicaba cuál era el camino más óptimo para construir productos!
Te invito a realizar un ejercicio. Vamos a leer juntos el Manifiesto Agile y a reflexionar sobre su contenido. Te animo a que reflexiones primero por tu cuenta sobre cada principio, y luego contrastes tus ideas con las mías. Mi deseo es que, al final de esta newsletter, te lleves al menos dos o tres puntos que puedas aplicar en cómo trabaja tu equipo.
El Manifiesto Agile comienza así:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Nuestra máxima prioridad como equipo de producto Agile es desarrollar soluciones que satisfagan las necesidades de nuestros clientes. Para lograr esta satisfacción, es esencial entregar resultados tempranos y de manera continua. En otras palabras, el Manifiesto Agile ya anticipaba el concepto de Producto Mínimo Viable/Valioso (MVP, por sus siglas en inglés). Debemos concentrarnos en construir productos valiosos que realmente satisfagan a nuestros clientes.
Es crucial evitar proyectos de larga duración que solo buscan implementar todas las funcionalidades posibles antes de llegar a producción. Del mismo modo, debemos resistir la tentación de construir productos basados simplemente en una lista de requisitos de stakeholders internos. Nuestro objetivo supremo es satisfacer a los clientes, lo cual implica resolver sus problemas de manera efectiva.
Para garantizar que estamos en el camino correcto, plantéate las siguientes preguntas:
¿Conversas con tus clientes frecuentemente, cada semana, para asegurarte de que estás satisfaciendo sus necesidades?
¿Haces despliegues a producción diariamente o varias veces por semana?
¿Implementas proyectos pequeños para aprender y adaptarte rápidamente a las necesidades cambiantes de tus clientes?
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
El Manifiesto Agile nos invita a dar la bienvenida a los cambios de requisitos, incluso en etapas avanzadas del desarrollo. Los procesos ágiles canalizan el cambio para convertirlo en una ventaja competitiva para el cliente. Esto es esencialmente una declaración de flexibilidad y adaptabilidad, y marca una clara desviación de los métodos tradicionales de desarrollo que a menudo consideran los cambios como obstáculos o inconvenientes.
Un equipo de producto Agile debe ser receptivo a los cambios. En lugar de resistirnos a ellos, debemos entender que el cambio es una constante y que, en muchos casos, puede proporcionar valiosos insights sobre las necesidades cambiantes de nuestros clientes. De hecho, adaptarse a estos cambios puede ser la clave para mantener a nuestros productos competitivos y relevantes en un mercado en constante evolución.
Es crucial que veamos los cambios de requisitos no como desafíos, sino como oportunidades para aprender y mejorar. Tenemos que manejar bien la incertidumbre. Y deberíamos ser capaces de incorporar nuevas ideas y feedback, incluso si llegan tarde en el desarrollo, y usar este input para afinar nuestro producto y hacerlo aún mejor para nuestros clientes.
Por lo tanto, pregúntate:
¿Tu equipo es receptivo a los cambios, incluso cuando estos llegan en etapas avanzadas del desarrollo?
¿Estás utilizando los cambios como una oportunidad para mejorar y aprender, en lugar de verlos como un obstáculo?
¿Estás utilizando los cambios para proporcionar una ventaja competitiva a tus clientes?
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Este principio subraya la importancia de la entrega frecuente de software funcional. Los equipos de producto ágiles deben entregar con regularidad. La frecuencia de las entregas ejerce una influencia significativa en cómo nuestros clientes perciben nuestros productos. Entregar de manera frecuente fomenta la confianza y evidencia nuestro compromiso con el aporte continuo de valor.
Optar por plazos más cortos mejora nuestras oportunidades de recibir feedback temprano y relevante. Esto facilita la iteración y adaptación a las necesidades cambiantes de nuestros clientes de manera más eficaz y eficiente.
Además, este principio hace hincapié en la importancia de entregar software que realmente funcione. Esto implica no solo reducir los errores técnicos, sino también garantizar que el producto resuelve de manera efectiva los problemas de nuestros clientes. Establecer como objetivo la entrega frecuente de software de alta calidad y bajo error, debería ser una meta central para cualquier equipo de producto empoderado.
Para lograrlo, es crucial hacernos algunas preguntas:
¿Con qué frecuencia tu equipo logra entregar software funcional?
¿Te esfuerzas por minimizar los tiempos de lanzamiento a producción y los errores?
¿Has implementado mecanismos para obtener feedback temprano y regular de los clientes a fin de mejorar continuamente?
Business people and developers must work together daily throughout the project.
El Manifiesto Agile también destaca la necesidad de una colaboración constante entre las personas de negocios y los desarrolladores a lo largo de todo el proyecto. No se trata solo de una mera interacción, sino de un entendimiento profundo y mutuo.
Si bien los Product Managers son fundamentales en la concepción y dirección del producto, los desarrolladores deben estar íntimamente familiarizados con el negocio, interactuar directamente con las personas de negocio, y estar activamente involucrados en la priorización y diseño de las soluciones. Un desarrollador que solo está interesado en programar y no se involucra con el negocio, carece de una pieza esencial para ser un buen ingeniero. Para manejar proyectos complejos, se requiere un conocimiento sólido del negocio, y este se logra a través de la interacción y la comprensión directa del negocio y sus necesidades.
Esta colaboración diaria promueve un entendimiento compartido, la alineación de las metas y la capacidad de adaptarse rápidamente a los cambios. Por tanto, es esencial cultivar un ambiente de comunicación abierta y fluida.
Para validar si se está logrando esta colaboración, reflexiona sobre las siguientes preguntas:
¿Los desarrolladores y las personas de negocio trabajan juntos casi a diario?
¿Están todos los miembros del equipo, independientemente de su rol, comprometidos e informados sobre los objetivos del proyecto?
¿Existen espacios y oportunidades para que los desarrolladores interactúen directamente con el negocio y se involucren en la toma de decisiones?
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Este principio pone el foco en el corazón de cualquier proyecto: las personas. La clave para un equipo de producto empoderado de alto rendimiento radica en la construcción de proyectos alrededor de individuos motivados. No solo se trata de seleccionar a las personas adecuadas, sino también de proporcionarles un entorno propicio y el apoyo necesario.
Los líderes tienen la responsabilidad de crear un ambiente que inspire a su equipo, les facilite los recursos necesarios y promueva la confianza. La confianza es fundamental. Un líder que confía en su equipo para realizar el trabajo impulsa la motivación, la iniciativa y la responsabilidad.
Además, un ambiente enriquecedor implica respetar la autonomía de los desarrolladores, permitiéndoles tomar decisiones y dar forma a las soluciones. Esta confianza y autonomía no solo potencian la motivación, sino que también permiten a los equipos adaptarse rápidamente a los cambios y desafíos.
Por tanto, es esencial hacernos las siguientes preguntas:
¿Estás construyendo proyectos alrededor de individuos motivados?
¿Proporcionas el entorno y el apoyo necesario para que tu equipo prospere?
¿Confías en tu equipo para llevar a cabo el trabajo y les permites tomar decisiones importantes?
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Este manifiesto, escrito en 2001, aboga por la comunicación cara a cara como la forma más eficiente y efectiva de transmitir información dentro de un equipo de desarrollo. Sin embargo, en 2023, el mundo ha cambiado drásticamente, y se nos plantea una pregunta interesante: ¿Estarían de acuerdo los autores originales con este principio en el mundo laboral actual?
La aparición del trabajo remoto y el cambio hacia modelos híbridos han introducido nuevos desafíos y oportunidades. Aunque la comunicación escrita puede dar lugar a malentendidos y conflictos, y el trabajo remoto puede reducir las interacciones informales y la comunicación transversal con otros departamentos, también nos ha permitido acceder a un talento global sin precedentes.
Personalmente, sigo creyendo en el valor de trabajar en persona. Facilita la formación, genera más ideas interdisciplinares, y se forjan relaciones más profundas y rápidas. Si empezara una startup de nuevo, lo haría de forma híbrida con mucha interacción en persona para generar mejores ideas y construir una buena base de equipo.
Independientemente de cómo elijas trabajar, lo esencial es mantener una comunicación frecuente y de alta calidad. Combinar la comunicación escrita con el audio o video cuando se necesita discutir algo es clave.
Entonces, te pregunto:
¿Cuál es vuestro balance entre comunicación cara a cara y comunicación digital?
¿Eres consciente de los posibles malentendidos que puede causar la comunicación escrita y qué haces para mitigarlos?
¿Cómo facilitas la comunicación informal y transversal en un entorno de trabajo remoto o híbrido?
Working software is the primary measure of progress.
El software funcional es la medida principal de progreso para un equipo de producto ágil. Más allá de los planes, estimaciones y métricas internas, lo que realmente importa es si estamos entregando software que aporte valor y que nuestros clientes utilicen de manera efectiva.
No obstante, es importante recalcar que "funcional" no significa únicamente libre de errores técnicos. También implica que el software cumple con los objetivos de negocio y satisface las necesidades de los usuarios. Un software puede ser técnicamente impecable, pero si no resuelve un problema real para los usuarios o no añade valor al negocio, su utilidad es cuestionable.
Por lo tanto, el trabajo del equipo no concluye simplemente al lanzar una nueva funcionalidad a producción. La tarea se completa cuando validamos que esta funcionalidad es efectivamente utilizada por nuestros usuarios, aporta valor y mejora las métricas de negocio que nos hemos propuesto optimizar. Es este ciclo completo, de concepción a validación, el que realmente muestra nuestro progreso y eficacia.
Entonces, te invito a que reflexiones:
¿Cómo mides el progreso en tu equipo?
¿Se centra tu equipo en la entrega de software que funcione y aporte valor real a los usuarios y al negocio?
¿Validas la utilidad y el impacto de las funcionalidades después de lanzarlas a producción?
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
La sostenibilidad es otro de los principio del Manifiesto Ágil. El desarrollo de productos es una carrera de fondo, no un sprint. Los stakeholders, desarrolladores y usuarios deben ser capaces de mantener un ritmo constante de forma indefinida.
La idea de "ritmo sostenible" implica que debemos evitar el agotamiento del equipo, los picos de estrés y la fluctuación en la calidad del trabajo debido a la sobrecarga. La cultura del "crunch", es decir, trabajar horas extras constantemente para cumplir con los plazos, puede resultar en un desgaste rápido del equipo y disminuir la calidad del producto final.
Además, mantener un ritmo constante también significa tener una visión a largo plazo y priorizar adecuadamente. No se trata solo de entregar características a corto plazo, sino también de construir un producto robusto y escalable que pueda crecer y evolucionar con el tiempo.
Por tanto, te pregunto:
¿Cómo evitas el agotamiento del equipo?
¿Tienes una visión a largo plazo para tu producto y un plan para llegar allí?
¿Cómo priorizas tus características para equilibrar las necesidades a corto y largo plazo?
Continuous attention to technical excellence and good design enhances agility.
Este principio subraya la importancia de prestar atención continua a la excelencia técnica y al buen diseño como catalizadores de la agilidad. La agilidad no es simplemente una cuestión de velocidad de entrega, sino también de la calidad de lo que se entrega.
La excelencia técnica y el buen diseño son pilares fundamentales para el éxito a largo plazo de cualquier producto. Sin embargo, este camino hacia la calidad puede estar marcado por lo que se conoce como deuda técnica o de producto, decisiones conscientes de comprometer ciertos aspectos de la calidad por un progreso más rápido en el corto plazo.
La clave aquí radica en gestionar esta deuda de manera inteligente. Es crucial entender cuándo conviene aceptar cierta deuda por las ventajas inmediatas que ofrece y cuándo es preferible invertir tiempo y recursos para "hacer las cosas bien" desde el principio. Esto implica también la necesidad de mantener un plan sólido y factible para reducir esa deuda a lo largo del tiempo, mientras seguimos entregando de manera frecuente.
La excelencia técnica engloba escribir código limpio, adherirse a buenas prácticas de programación, realizar pruebas y revisiones de código, y mantener la documentación al día. Mientras que el buen diseño abarca la usabilidad, la experiencia del usuario, la accesibilidad y la estética.
Por tanto, reflexiona sobre las siguientes preguntas:
¿Tu equipo presta atención constante a la excelencia técnica y al buen diseño?
¿Cómo manejas la deuda técnica y de producto en tu equipo?
¿Cómo balanceas la necesidad de entregar rápidamente nuevas características con la importancia de mantener la calidad del código y del diseño?
Simplicity – the art of maximizing the amount of work not done – is essential.
El Manifiesto Ágil celebra la simplicidad, que se considera como el arte de maximizar la cantidad de trabajo no realizado. Los equipos se ven tentados de forma continua a añadir funcionalidades que no son esenciales, lo que puede llevar a un producto sobrecomplicado y difícil de mantener.
En el desarrollo ágil, menos es más. La simplicidad implica eliminar cualquier cosa que no sea absolutamente necesaria. No se trata de evitar el trabajo, sino de maximizar el valor que se proporciona al cliente con el mínimo esfuerzo y recursos posibles.
En este sentido, la simplicidad no es sólo una cuestión de diseño o de código, sino también una cuestión de enfoque y priorización. Hay que centrarse en las características que realmente importan y aportan valor a los usuarios, y resistir la tentación de añadir "características bonitas" que no son necesarias.
Entonces, te propongo las siguientes preguntas para reflexionar:
¿Cómo promueves la simplicidad en tu equipo?
¿Cómo te aseguras de que sólo se está trabajando en las características que realmente importan y aportan valor a los usuarios?
¿Cómo resistes la tentación de añadir características innecesarias?
The best architectures, requirements, and designs emerge from self-organizing teams.
Este principio nos dice que las mejores arquitecturas, requisitos y diseños surgen de equipos autoorganizados. Marty Cagan, en su libro "Inspired", habla de la importancia de tener equipos de producto empoderados, que no son muy diferentes de lo que este principio del Manifiesto Ágil describe.
Un equipo de producto empoderado, al igual que un equipo autoorganizado, es aquel que tiene autonomía para tomar decisiones importantes y responsabilidad sobre los resultados. Cagan argumenta que estos equipos son más propensos a producir productos excepcionales porque pueden aprovechar al máximo el conocimiento colectivo, la creatividad y la experiencia de sus miembros. Además, estos equipos tienen un mayor compromiso con el producto y la organización, ya que sienten que tienen un verdadero impacto.
Pero es importante tener en cuenta que el empoderamiento no significa anarquía. Los equipos de producto empoderados necesitan líderes que establezcan la visión, proporcionen orientación y eliminen los obstáculos. Estos líderes no se encargan de dictar soluciones, sino de ayudar a sus equipos a descubrir las mejores soluciones posibles.
En este sentido, los equipos autoorganizados y los equipos de producto empoderados están alineados en su núcleo: ambos abogan por la autonomía, la responsabilidad y la colaboración. Ambos reconocen que las soluciones más efectivas y creativas emergen cuando los equipos tienen la libertad de explorar, experimentar y adaptarse.
Por tanto, te propongo reflexionar sobre lo siguiente:
¿Tu equipo se siente empoderado y autoorganizado?
¿Tienen la autonomía para tomar decisiones y la responsabilidad de los resultados?
¿Cómo puedes, como líder, ayudar a fomentar un entorno de empoderamiento y autoorganización?
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
El Manifiesto concluye con que los equipos ágiles deben dedicar tiempo regularmente para reflexionar sobre cómo pueden mejorar su efectividad y luego ajustar su comportamiento en consecuencia. Esta práctica, a menudo referida como retrospectiva, es fundamental para la mejora continua, uno de los pilares del pensamiento ágil.
Las retrospectivas permiten a los equipos reflexionar sobre lo que está funcionando bien y lo que necesita mejorarse. No solo se enfocan en el trabajo del equipo en sí, sino también en cómo trabajan juntos como equipo. Esta autocomprensión es esencial para un equipo de producto empoderado, ya que permite ajustes y mejoras continuas en el proceso de trabajo.
Las retrospectivas también promueven la transparencia y la confianza dentro del equipo. Al tener un espacio seguro para discutir abiertamente los desafíos y los problemas, los equipos pueden trabajar juntos para encontrar soluciones y mejorar su forma de trabajar.
Pero no basta con hacer retrospectivas, es importante actuar sobre las conclusiones a las que se llega en estas reuniones. Un equipo que se toma en serio la mejora continua actuará sobre estas conclusiones, realizando los ajustes necesarios en su comportamiento y forma de trabajar.
Te invito a que reflexiones sobre lo siguiente:
¿Tu equipo realiza retrospectivas regularmente?
¿Se sienten seguros para hablar abiertamente sobre los desafíos y los problemas en estas reuniones?
Y lo más importante, ¿actúan sobre las conclusiones de estas reuniones para mejorar su eficacia?
Conclusión
Los principios del Manifiesto Ágil y el concepto de Equipos de Producto Empoderados de Marty Cagan se complementan perfectamente – o son esencialmente lo mismo – para dar forma a una cultura de trabajo donde los equipos brillan y los productos prosperan. Ambos enfatizan la autonomía, la colaboración, la adaptabilidad y una orientación fuerte hacia el cliente, estableciendo el escenario para una cultura de producto vibrante y eficaz.
Cuando estos principios se llevan a cabo, los equipos no sólo son capaces de producir software de alta calidad de manera constante, sino que también están en una posición para crecer y evolucionar. Se sienten valorados y empoderados, lo que les lleva a asumir la responsabilidad y a esforzarse por superar las expectativas.
Por otro lado, los clientes y stakeholders experimentan el valor de un enfoque de producto sólido. Sienten que su feedback y necesidades son realmente escuchados y atendidos, lo que refuerza su confianza y satisfacción. Asimismo, se benefician de la entrega frecuente de valor, ya que el producto evoluciona y mejora constantemente para satisfacer sus necesidades y superar sus expectativas.
Por experiencia propia, trabajar dentro de esta cultura de producto es una experiencia muy enriquecedora y gratificante. Ves a los individuos crecer y desarrollarse, a los equipos brillar y a los productos avanzar de manera constante y significativa. Al final, se crea un círculo virtuoso donde el equipo de producto, los stakeholders y los clientes están sincronizados, colaborando para construir soluciones increíbles que realmente aportan valor.
Sin embargo, es importante recordar que esta es una meta a alcanzar, una cultura de trabajo a construir. Requiere tiempo, esfuerzo y compromiso constante. A nosotros en Ontruck nos costó años de muchas conversaciones e iteraciones semanales. Pero cuando lo logras, es indudablemente gratificante. Y eso es lo que hace que valga la pena cada paso en este viaje.