Tu Definición de Terminado no funciona y lo sabes: lo que puedes hacer a partir del paquete de expansión de la guía de Scrum

La guía de Scrum ha sido, desde su concepción, un referente de simplicidad y claridad. Es un documento muy rico en experiencia frase por frase. Ampliamente usado (aunque no estoy seguro si leído con el mismo ímpetu con el que se intenta usar) y también pródigamente malentendido. En este contexto surge el así llamado Paquete de Expansión de la Guía de Scrum, quizás para llenar el vacío que deja la guía al terminar de leerla, el “¿Qué diablos quisieron decir con todo esto?”

Este documento no reemplaza la guía, de hecho, no es una nueva versión de la guía de Scrum, sino que la complementa, actuando como un puente hacia el presente. Todavía es algo pronto para decidir si era necesario algo así o no. Lo que sí es cierto es que la motivación de los autores detrás del documento es auténtica. El mundo ha cambiado mucho en los últimos cinco años y en todos los entornos hay mucha gente, muchos equipos, muchas organizaciones que no han terminado de entender Scrum ni su guía formal.

Pero si tienes interés: léelo cuidadosamente (en español o en inglés o en el idioma de tu preferencia —¡hay una versión en Klingon! —), analiza si cada concepto, práctica o recomendación propuesta te aplica o no, y comienza a adoptar uno a uno, experimentando, midiendo, aprendiendo. Orgánicamente. No cometas el clásico error de “a partir del próximo sprint todos los equipos deben hacer lo que dice aquí”. No. Así será un ejercicio que te hará fracasar en grande.

Y a propósito de “uno a la vez”, empecemos con uno de los que más me interesó. La Definición de Terminado. Sí, es evidente que un sinnúmero de equipos sigue aplicando mal este compromiso. Se quedan en los aspectos de calidad: que el incremento debe cumplir con Seguridad, que Auditoría debe aprobar, que se hagan las pruebas de regresión, que se elabore un acta o minuta firmada por todos los interesados y un largo etcétera. Y de aquello nada.

¿Y aquello qué es? Valor. Impacto. Beneficio. Para el cliente. Para el usuario. Para el negocio. Incluso para el equipo Scrum.

Los autores de este paquete de expansión, entre los que se cuenta el mismísimo Jeff Sutherland, inventor de Scrum, nos traen una propuesta interesante, dos definiciones de terminado: la Definición de Producto Terminado cuya esencia es la Definición de Terminado existente en la guía; y la Definición de Resultado Terminado. Estos nombres en español son una traducción libre tal y como las interpreto. Vamos entonces por partes.

La Definición de Producto Terminado, que también se puede llamar Definición de Entregable Terminado o Definición de Salida Terminada (en la traducción oficial al español de Alex Ballarin se llama Definición de Hecho de Producto) es el compromiso del Incremento:

•       Describe las medidas de calidad que expresan la debida diligencia para el Incremento, asegurando que pueda ser entregado a los Stakeholders.

•       Se enfoca en el qué fue construido y su calidad, asegurando que está listo para ser potencialmente lanzado.

•       Mide los estándares de calidad y las cualidades del Producto (técnicas y de Producto) que el Incremento debe cumplir.

Entre tanto, la Definición de Resultado Terminado, que también podemos llamar la “Definición de Valor Aportado”, puesto que el término "Valor" es el fin último de cualquier producto. Este nombre me gusta además porque deja claro que no estamos midiendo la funcionalidad entregada (“output”), sino el beneficio real que esta aporta. Incluso “Definición de Impacto Logrado” es buen nombre, ya que denota un cambio significativo en el comportamiento del usuario o en las métricas del negocio (por ejemplo, "aumentar la retención", "reducir las llamadas a soporte"), y describe perfectamente la consecuencia de una salida exitosa. Son ideas. En breve, esta Definición de Hecho de Resultado, como se llama en la traducción oficial:

•       Describe las medidas observables (cuantitativas o cualitativas) que demuestran los beneficios realizados o la validación de valor para los Stakeholders.

•       Se enfoca en el porqué del trabajo, es decir, si lo que se entregó generó el impacto deseado y el valor real.

•       Mide el valor realizado y el impacto para los Stakeholders (incluyendo clientes, usuarios, etcétera).

Ejemplos

Con un ejemplo se entiende mejor. Así que veamos este “paquetico” de expansión al paquete de expansión de la guía de Scrum. Imaginemos un producto, una plataforma de comercio electrónico para pequeños negocios. Una Definición de Resultado Terminado puede contener aspectos como:

Para el Producto en general (impacto estratégico y de negocio):

•       Lograr un aumento del 15 % en el Net Promoter Score (NPS) de los comerciantes que utilizan la plataforma en los próximos 6 meses.

•       Aumentar la tasa promedio de conversión de visitantes a compradores en las tiendas de los comerciantes de la plataforma en un 5 % en el próximo trimestre.

•       Disminuir la tasa de abandono de comerciantes (“churn rate”) en un 10 % en el semestre.

•       Un incremento del 20 % en el volumen total de transacciones procesadas a través de la plataforma en los próximos 6 meses.

Para un Objetivo de Producto específico (por ejemplo, "Mejorar la capacidad de los comerciantes para gestionar inventarios"):

•       Disminuir el tiempo promedio que le toma a un comerciante actualizar y gestionar su inventario en la plataforma en un 25 %.

•       Reducir en un 30 % la cantidad de quejas de clientes relacionadas con productos "agotados" que aparecen como "en stock" en las tiendas.

•       Un 50 % de los comerciantes activos han configurado y reciben alertas de bajo stock para sus productos clave.

Mientras que la Definición de Producto Terminado adyacente puede incluir:

•       Código revisado y aprobado

•       Pruebas unitarias exitosas con una cobertura mínima del 80 %.

•       Pruebas de integración y sistema pasadas

•       Pruebas de regresión automatizadas

•       Desplegado en el entorno de preproducción

•       Rendimiento y escalabilidad verificados

•       Seguridad validada

•       Compatibilidad con navegadores y dispositivos principales (Chrome, Firefox, Safari, iOS, Android).

•       Documentación técnica actualizada

Nada que no esté incluido en una Definición de Terminado típica.

Diferencias clave

En esta tabla te dejo de manera sucinta algunos aspectos que te pueden ayudar a entender sobre el enfoque, el alcance, la validación y el momento de verificación de cada una de estas definiciones de Terminado.

	Definition of Output Done (Definición de Producto Terminado)	Definition of Outcome Done (Definición de Resultado Terminado)
Enfoque	Se enfoca en la calidad de la entrega (el "qué" se construyó)	Se centra en el valor o impacto logrado (el "porqué" se construyó).
Alcance	Aplica a un Incremento específico, asegurando que está listo para ser potencialmente lanzado.	Aplica al Producto en general o a una meta estratégica, midiendo si el Producto genera los beneficios esperados a lo largo del tiempo.
Validación	Se valida mediante criterios de calidad internos y técnicos (pruebas, revisiones de código).	Se valida mediante evidencia observable de impacto en los Stakeholders (métricas de negocio, comportamiento del usuario, encuestas de satisfacción) una vez que el output ha sido liberado y utilizado.
Momento de Verificación	En cada Sprint para cada Incremento.	Proceso continuo que ocurre a medida que el Producto interactúa con el mercado y los usuarios a lo largo del tiempo.

 Recomendación final

Entregar un producto perfecto que no genera valor es el fracaso más elegante del mundo. Inapelable. Si hoy tienes una Definición de Terminado con la que has tenido éxito entregando valor e impactando el negocio sprint tras sprint, entonces quizás no necesites nada de lo que hay aquí. Aun así, es una buena propuesta.

Si, por el contrario, tus usuarios o clientes continúan sin ver los beneficios de lo que les entregas, entonces quizás sea buena idea empezar a usar estos dos compromisos por separado. Como te dije al principio: empieza experimentando en pequeño, con un equipo, observa los resultados, las reacciones del entorno, aprende. Reflexiona. Y adáptate.

Si tienes algún inconveniente, siempre puedes contactarme y, en la medida de mis posibilidades, con gusto te ayudo.

 

Entre la eficiencia y el despojo: La inevitable mutación del desarrollo de software por la IA

Alerta de espóiler: este artículo se basa y contiene datos e imágenes del más reciente reporte DORA sobre el impacto de la Gen AI en el desarrollo de software.

El reciente reporte sobre “The Impact of Gen AI in Software Development” ofrece una visión amplia y matizada sobre la transformación que la inteligencia artificial generativa (IA) está provocando en el mundo del desarrollo de software. El informe no solo destaca los beneficios tangibles y las oportunidades que surgen al integrar estas tecnologías en el ciclo de desarrollo, sino que también plantea desafíos, paradojas y riesgos que deben abordarse de forma estratégica. Así que vamos a analizar los aspectos positivos, negativos y las áreas de incertidumbre (“lo bueno, lo malo, lo feo”) que emergen del estudio, para finalmente responder una pregunta: ¿qué dirección pueden tomar las organizaciones respecto a la adopción de IA en el desarrollo de software?

Entremos en materia.

Lo bueno: Beneficios para los desarrolladores y la organización

Uno de los principales hallazgos del reporte es que la adopción de IA se asocia con mejoras en la productividad, el flujo de trabajo y la satisfacción laboral de los desarrolladores. El medir el impacto en el éxito y el bienestar individual, se encontró que un incremento del 25 % en la adopción de IA se vincula con aumentos en la productividad, mayor frecuencia en el estado de “flow”, es decir, los desarrolladores experimentan más momentos de concentración intensa y productividad continua en su trabajo, y un incremento en la satisfacción con el trabajo. Estos beneficios se deben, en parte, a lo que sabemos: la IA permite automatizar tareas repetitivas y liberar tiempo para que los desarrolladores se concentren en actividades más creativas y de mayor valor, como la resolución de problemas complejos, lo que genera una experiencia laboral más fructífera.

Figura 1: Impactos de la adopción de IA en el éxito y el bienestar individual. Fuente: DORA Impact of Gen AI in Software Development Report.

En el perímetro organizacional, la adopción de IA también tiene impactos positivos evidenciados en mejoras en la calidad del código, la velocidad de revisión y aprobación, y la optimización de la documentación. Al aumentar el uso de IA, se logra un incremento de aproximadamente un 7.5 % en la calidad de la documentación y mejoras de entre 1.3 % y 3.4 % en la calidad del código y los procesos de revisión. Estas mejoras no solo permiten reducir la deuda técnica y la complejidad del código (aunque de manera modesta, con reducciones del -0.8 % y -1.8 % respectivamente), sino que también posibilitan una respuesta más rápida en la identificación y corrección de errores, lo que puede contribuir a una mayor eficiencia en el ciclo de desarrollo.

Son datos que evidencian las hipótesis que teníamos en cuanto a la innovación: la capacidad de generar código a gran escala y de forma automatizada fomenta la experimentación y la adopción de nuevas formas de hacer las cosas, lo que a largo plazo puede impulsar la competitividad de las organizaciones en los mercados actuales.

Figura 2: Impactos de la adopción de IA en el código producido. Fuente: DORA Impact of Gen AI in Software Development Report.

Datos, datos, datos

A continuación, presentamos una tabla que resume algunos de los hallazgos clave del reporte, junto con la métrica asociada y una calificación del impacto:

Fuente: DORA Impact of Gen AI in Software Development Report

La tabla sintetiza los datos más relevantes del informe, permitiendo identificar claramente las áreas en las que la adopción de IA genera beneficios, así como los aspectos que requieren atención o mitigación.

Lo malo: Desafíos y paradojas en la integración de IA

Uno de los hallazgos más sorprendentes es la disminución del tiempo dedicado a tareas que los desarrolladores consideran valiosas, a pesar de la mejora en indicadores como productividad y satisfacción. Esta paradoja, denominada en el estudio como la “vacuum hypothesis”, sugiere que, al aumentar la eficiencia mediante la IA, los desarrolladores terminan completando las tareas de alto valor más rápidamente, lo que se traduce en una reducción del tiempo invertido en ellas. Este fenómeno plantea interrogantes sobre la percepción de valor en el trabajo y sobre si la automatización puede, en ciertos casos, limitar el potencial de profundización o perfeccionamiento de actividades que, de otro modo, aportarían un mayor significado profesional.

Otro aspecto negativo que resalta el documento es el impacto adverso sobre la estabilidad en la entrega de software. Aunque la velocidad de entrega sufre una leve disminución (alrededor de -1.5 %), la estabilidad se ve afectada de manera más significativa (-7.2 %). Esto podría deberse a que la facilidad para generar grandes volúmenes de código mediante IA lleva a la implementación de cambios de mayor tamaño, lo que históricamente se ha asociado a un incremento en los errores y en la inestabilidad del producto final. La adopción de IA, por lo tanto, no garantiza por sí sola una mejora en la calidad de las entregas, sino que exige una atención especial a las prácticas tradicionales de ingeniería, como el mantenimiento de pequeños lotes de cambios y la implementación rigurosa de pruebas automatizadas.

Asimismo, se evidencian riesgos relacionados con la confianza en los sistemas de IA. A pesar de que los desarrolladores que utilizan estas herramientas reportan un aumento en su productividad, la confianza en la calidad del código generado puede ser baja. Ya lo habíamos imaginado mucho antes del reporte: como con cualquier otra tarea en la que usemos la IA, la dependencia excesiva en las sugerencias de la IA sin la adecuada verificación humana podría derivar en problemas de calidad a mediano y largo plazo, afectando no solo el producto final, sino también la reputación y la eficiencia operativa de la organización.

Figura 3: Impactos de la adopción de IA en el rendimiento y la estabilidad de la entrega. Fuente: DORA Impact of Gen AI in Software Development Report.

Lo feo: Incertidumbres y riesgos estratégicos

Más allá de los aspectos positivos y negativos, el reporte también señala “lo feo” en términos de incertidumbres y riesgos estratégicos que aún deben ser abordados. Uno de estos riesgos es la posible disrupción en el rol de los desarrolladores. La adopción de IA plantea la inquietud de que, a medida que las herramientas se vuelven más sofisticadas, se pueda desvalorizar la experiencia y el conocimiento humano, generando temores sobre el desplazamiento laboral o la reducción de las horas remuneradas. Este escenario, aunque no se presenta como una consecuencia directa e inmediata, exige que las organizaciones desarrollen estrategias para reestructurar el rol del desarrollador, enfocándolo en actividades que complementen la automatización y potencien las habilidades humanas, como la resolución de problemas complejos, la toma de decisiones estratégicas y la innovación.

Otro riesgo es la carencia de políticas claras y consistentes en el uso de IA. El reporte destaca la importancia de que las organizaciones establezcan directrices transparentes sobre el uso y las limitaciones de estas tecnologías. La ausencia de un marco regulatorio interno puede derivar en usos irresponsables o incluso en vulnerabilidades de seguridad, afectando tanto la integridad de los datos como la confianza de los empleados y clientes. La elaboración de políticas de uso aceptable y de estrategias de gobernanza robustas se vuelve, por tanto, un imperativo para minimizar los riesgos y asegurar que la adopción de IA se traduzca en beneficios sostenibles a largo plazo.

Direcciones estratégicas para las organizaciones

Frente a este escenario complejo, ¿qué dirección pueden tomar las organizaciones respecto a la adopción de IA en el desarrollo de software? El reporte sugiere que la clave está en una estrategia equilibrada que combine la innovación tecnológica con la solidez de las prácticas tradicionales de ingeniería.

En primer lugar, es fundamental que las organizaciones adopten un enfoque gradual y responsable. La implementación de IA debe acompañarse de programas de capacitación que permitan a los desarrolladores familiarizarse con las nuevas herramientas, comprendiendo tanto sus potencialidades como sus limitaciones. Al invertir en formación y en la creación de comunidades de práctica, las empresas pueden fomentar un entorno de aprendizaje continuo, donde la experimentación y el intercambio de conocimientos potencien la adopción de la tecnología de forma segura y controlada.

En segundo lugar, es imprescindible establecer políticas claras que definan el uso y los límites de la IA. Estas directrices no solo deben contemplar aspectos técnicos, sino también éticos y de seguridad, garantizando que la automatización no comprometa la calidad del código ni la integridad de los procesos. La transparencia en la comunicación de estas políticas ayudará a mitigar los temores relacionados con la pérdida de empleo o la desvalorización del trabajo humano, reforzando la idea de que la IA es una herramienta que potencia, y no sustituye, las capacidades de los desarrolladores.

Otro aspecto crucial es la integración de la IA en un ecosistema de prácticas de desarrollo sólidas. La experiencia demuestra que la automatización de tareas repetitivas y la generación de código de calidad pueden ser muy beneficiosas, siempre que se mantengan mecanismos de control como la revisión de código, las pruebas automatizadas y la gestión de pequeños lotes de cambios. Estas prácticas permiten compensar los riesgos asociados a la generación masiva de código y aseguran que los beneficios de la IA se traduzcan en una entrega de software más estable y confiable.

Además, las organizaciones deben estar preparadas para replantear los roles y responsabilidades dentro de los equipos de desarrollo. La adopción de IA puede generar la necesidad de nuevos perfiles, como el de “prompt engineer” o especialista en la integración y verificación de herramientas automatizadas. Redefinir las funciones y potenciar la colaboración entre los expertos en IA y los desarrolladores tradicionales permitirá que ambas competencias se complementen, impulsando la innovación y la eficiencia.

Finalmente, es inaplazable que las organizaciones adopten un enfoque basado en la medición continua y la retroalimentación. El reporte enfatiza la importancia de utilizar métricas y sistemas de retroalimentación para evaluar el impacto de la IA en diferentes niveles: individual, de equipo y organizacional. Al monitorear indicadores clave, como la productividad, la estabilidad de las entregas y la calidad del código, las empresas pueden ajustar sus estrategias de adopción de forma dinámica, aprendiendo de la experiencia y corrigiendo el rumbo cuando sea necesario.

El desafío real no es la IA, sino cómo la usamos

Para cerrar, la IA representa una herramienta poderosa que, bien implementada, puede potenciar el rendimiento y la creatividad de los desarrolladores, mejorar la calidad del código y acelerar la entrega de software. Sin embargo, sus beneficios no son automáticos ni exentos de riesgos. Si tu organización quiere estar mejor posicionada para liderar el cambio en el mundillo tecnológico vigente, hazte acompañar para que logres equilibrar la innovación con la disciplina técnica y una visión estratégica orientada a la transformación cultural.

En Experimentum ya lo estamos haciendo.

Puedes descargar el DORA Impact of Gen AI in Software Development Report completo en:

DORA | Accelerate State of DevOps Report 2024

https://dora.dev/research/2024/dora-report/

Planificación empírica de productos

 

Mi serie de artículos sobre los errores de los [nuevos] Scrum Masters despertó interés en algunos otros temas. La cuestión más recurrente que me llegó fue esta de la planificación empírica de productos. Es un descuido común. Lo decía en el primero de los tres artículos, mismo que encuentras aquí:

Siete errores comunes de los nuevos Scrum Masters al servicio de los Product Owners – Lucho Salazar

Pues bien, sobre este asunto ya escribí hace algunos años, así que para entenderlo mejor, empieza por aquí:

Nuestro Scrum empírico de todos los días - Gazafatonario IT

Específicamente, establecer una planificación empírica de productos para un entorno complejo significa tomar decisiones relacionadas con el producto basadas en datos, observaciones y evidencias reunidas a lo largo del proceso de desarrollo, en lugar de confiar en suposiciones, planes a largo plazo o predicciones. Y una advertencia en este apartado: hay que ser cuidadosos con ese “a lo largo del proceso de desarrollo”. En ocasiones no es bueno ir tan atrás.

En entornos complejos, donde las condiciones del mercado, las preferencias de los clientes y la tecnología cambian rápidamente, raya en lo imposible predecir con certeza qué le dará más valor al producto. Es allí donde aprovechamos el enfoque iterativo e incremental de Scrum para hacer planificación empírica de productos, recopilando retroalimentación con frecuencia y adaptándonos en función de lo que observamos y aprendemos.

Trataré de dilucidar al respecto.

Paso a los entornos complejos

Ya basta de Cynefin o de cualquier otro modelo que intente explicar los distintos entornos donde nos movemos. En la práctica, un entorno complejo se caracteriza por la gran cantidad de variables y factores desconocidos con las que los equipos lidian al intentar predecir de manera confiable el mejor curso de acción. Ejemplos de esto incluyen:

·       Tendencias de mercado cambiantes.

·       Necesidades inciertas de los clientes.

·       Evolución de la competencia o cambios regulatorios.

·       Avances tecnológicos rápidos.

En escenarios de esta clase, los planes a largo plazo basados en supuestos fijos no arrojan los resultados esperados. El éxito del producto depende de un aprendizaje constante vía experimentación, retroalimentación y adaptación.

Implicaciones de la planificación empírica de productos

La planificación empírica de productos requiere de transparencia, inspección y adaptación: los tres pilares de Scrum.

Transparencia: todos los involucrados en el desarrollo del producto tienen visibilidad sobre el progreso, los riesgos y el estado del trabajo. Esto requiere que los elementos del Product Backlog estén claros y actualizados, así como una comunicación continua.

El Product Backlog es compartido abiertamente y visible para todos los interesados. Alguien como el Product Owner lo actualiza regularmente en función de los últimos datos proporcionados por los usuarios, el mercado, regulaciones o descubrimientos técnicos. Ese 50 % del tiempo que el Product Owner no pasa con el equipo, lo debe transitar en el entorno del producto. Indaga. Profundiza. Se proyecta. Se anticipa, por ejemplo, a asuntos regulatorios por venir.

Inspección: todo el equipo, especialmente el Product Owner con ayuda del Scrum Master, inspecciona con regularidad el producto y el progreso hacia los objetivos. Recopilan retroalimentación con frecuencia a través de Sprints de corta duración, revisiones y pruebas.

Por ejemplo, al final de cada Sprint, el equipo Scrum revisa el trabajo completado y busca la retroalimentación del cliente. Además, inspeccionan métricas como el compromiso de los usuarios, los datos de rendimiento del producto en producción o las funcionalidades más usadas, entre otras.

Adaptación: en función de las observaciones durante las inspecciones, los equipos adecúan sus planes, prioridades y enfoques. En lugar de seguir una hoja de ruta fija, se ajustan para reflejar nuevos conocimientos. Es cuando la “magia” ocurre. Por ejemplo, si el Product Owner nota una disminución en el compromiso de los usuarios, con el equipo ajusta el Product Backlog, priorizando funciones que mejoren la experiencia del usuario en lugar de seguir el plan ya establecido.

Planificación empírica de productos en acción

En la planificación empírica de productos no creamos planes elaborados a largo plazo. En cambio, usamos un enfoque de onda continua, donde proyectamos en detalle para los dos o tres sprints siguientes a la vez que mantenemos el trabajo futuro flexible.

También hacemos planificación empírica cuando, en lugar de construir una funcionalidad basada en suposiciones sobre el comportamiento del usuario, lanzamos una versión básica después de uno o dos Sprints. A partir de allí, observamos cómo los usuarios interactúan con ella, aprendemos qué funciona y qué no y ajustamos los planes futuros.

Además, cuando adoptamos una mentalidad donde las funciones y mejoras son realmente experimentos, estamos haciendo planificación empírica de producto. Establecemos hipótesis, las probamos rápidamente y utilizamos los resultados para guiar nuestras próximas decisiones. Después de todo, de eso se trata el “ser” ágil: de experimentar.

Las cosas así, los beneficios no se hacen esperar. Mitigamos riesgos, porque evitamos perder tiempo y recursos en funciones que no aportan valor. Nos centramos en el cliente, ya que los ciclos frecuentes de retroalimentación aseguran que el producto esté en constante evolución para satisfacer sus necesidades. Y somos flexibles, esto es, respondemos rápidamente a cambios en el mercado o nuevas oportunidades.

La responsabilidad del Scrum Master en la planificación empírica de productos

No hay otra forma de decirlo: el Scrum Master debe asegurarse de que el Product Owner y el equipo en pleno adopten la planificación empírica de productos. Este es el quid de la cuestión.

·       Fomenta ciclos de planificación más cortos: promueve pequeños pasos incrementales en lugar de planes a largo plazo.

·       Facilita los ciclos de retroalimentación: se asegura de que las Sprint Reviews sean significativas y conduzcan a ideas accionables.

·       Enseña pensamiento adaptativo: ayuda al Product Owner y al equipo a centrarse en la toma de decisiones basada en evidencias, en lugar de planes rígidos basados en antojos o cábalas.

·       Impulsa la inspección y adaptación: facilita que el equipo e interesados inspeccionen el progreso con regularidad y adapten su enfoque según lo que aprenden.

Pensamiento final

Solo quiero enfatizar que el desempeño pasado no es garantía del desempeño actual y mucho menos de futuro. Son solo eso, predicciones, pronósticos, hipótesis en el mejor de los casos, unas fallarán, otras no.

Es un hecho, la cantidad de incertidumbre en un pronóstico aumenta a medida que miras hacia el futuro. Perentorio.

Equipos de alto desempeño: redefiniendo la dinámica de equipos en la nueva normalidad

 

A principios de este milenio, muchas empresas cambiaron los tradicionales, antiquísimos por demás, cubículos de trabajo de 4, 8 y hasta 16 personas, por mesas de trabajo, amplias, oficinas más “abiertas”, se pusieron de moda los pubs, las mesas de ping pong y de otros juegos, los espacios de café y hasta de cerveza, pero los ambientes seguían cargados, no solo de humedad sino del peso de la rutina y la monotonía. El mayor impacto que veía por parte de los equipos era la felicidad de las personas cuando era viernes y si, como ocurre mucho en Colombia, el lunes siguiente era feriado, la felicidad era superlativa.

Es en estos escenarios donde a menudo veo el mayor potencial, donde las semillas de la innovación están enterradas bajo capas de burocracia y prácticas obsoletas.

A lo largo de los años, he experimentado continuamente, he caminado junto a innumerables equipos y he sido acogido por organizaciones anhelando una transformación: una verdadera esencia ágil. He llegado a una verdad lacónica: ser ágil es mucho más profundo e impactante que simplemente hacer ágil. ¿La diferencia? La mentalidad. Y esa mentalidad se convierte en la piedra angular para crear equipos de alto rendimiento e impacto.

¿Pero qué es exactamente un equipo de alto rendimiento? Esta es la conclusión a la que he llegado luego de 35 años en la industria: se trata de un grupo de personas que colectivamente exhiben un profundo sentido de colaboración e innovación, logrando consistentemente resultados inmejorables. Estos equipos se caracterizan por un grado elevado de cohesión, confianza y respeto mutuo entre sus miembros, lo que les permite funcionar con eficacia y eficiencia. Por lo general, superan a otros equipos, incluso si están compuestos por miembros con capacidades individuales sobresalientes.

¿Y cómo llevamos a ese grupo de personas de ser un equipo recién formado a convertirse en uno que exhiba estos comportamientos de productividad cumbre?

De 0 a 100 en 8 pasos: cómo llevar a tu equipo a rendir como los mejores

No son fórmulas mágicas, ni mucho menos recetas, pero aquí hay algunas estrategias que mi experiencia me ha enseñado:

1.   Valora a las Personas por encima de los procesos: sí, Scrum, SAFe, LeSS, historias de usuario, OKR y demás son cruciales. Pero estos marcos de trabajo no significan nada si no se valoran a las personas. He visto equipos volar cuando se priorizaba su felicidad y moralidad. No se trata solo de las reuniones diarias o las revisiones de sprint; se trata de escuchar, realmente escuchar, el pulso del equipo.

2.   Incorpora principios de Triple Impacto: ¿Resultados financieros? Esenciales. Pero ¿qué pasa con nuestro impacto social y medioambiental? En la nueva normalidad organizativa, las corporaciones brillantes integran estos tres. Al alinear los objetivos del equipo en torno a este triple impacto, te conectas con un sentido de propósito más profundo, impulsando el rendimiento y la innovación.

¿De qué nos sirven equipos de alto impacto en la oficina? Si el legado que dejan será alto estrés en las personas y, por extrapolación, en sus familias y comunidades alrededor ¿De qué nos sirven? Si los productos que eficientemente producen no dejan sino una estela de daño al medio ambiente y al planeta de la que posiblemente sobrevivan nuestros hijos, pero no nuestros nietos.

No me voy a cansar de decirlo: no es posible tener equipos de alto desempeño sanos, ni empresas sanas, en una sociedad y en un planeta enfermos. (Corolario de una observación de Drucker).

3.   Fomenta el aprendizaje continuo: la mentalidad ágil prospera con el crecimiento. Como líder, anima a los equipos a dedicar tiempo al aprendizaje. Ya sea una nueva tecnología, una habilidad esencial o entender las sutilezas de la transformación digital, cuanto más diverso sea el conocimiento, más holísticas serán las soluciones.

4.   Defiende la seguridad psicológica: uno de los momentos más emocionales que he tenido fue cuando un miembro del equipo, en una retrospectiva, derramó lágrimas al compartir un fracaso personal. Y el equipo se unió. Ese es el poder de la seguridad psicológica. Permite a las personas tomar riesgos, ser vulnerables, fomentando un ambiente donde la innovación no solo es bienvenida, sino que se celebra.

5.  Inclínate hacia el poder de la experimentación: no puedo contar cuántas veces un experimento ha llevado a perspectivas revolucionarias. Permíteles a tus equipos la autonomía de probar nuevos enfoques, probar hipótesis y aprender de los errores. Es en estos momentos donde el verdadero espíritu ágil brilla.

6.   Construye puentes, no silos: los equipos de alto rendimiento no operan en aislamiento. Se relacionan con los interesados, interactúan con los usuarios y comprenden los objetivos organizacionales más amplios. Al promover la colaboración interfuncional, amplías el impacto y alcance de tu equipo.

7.  Empodera con propósito: más allá de las historias de usuario y el backlog de producto pendiente, hay una narrativa. Cada producto, cada característica tiene una historia que afecta a personas reales. Cuando los equipos comprenden el 'por qué' detrás de sus tareas, están más comprometidos, más apasionados y sin duda son más efectivos. Empieza con el porqué.

8.   Estabiliza el equipo: es quizás lo más difícil que existe. Las personas entran y salen de los equipos por diversas razones. Pero los equipos estables son los que lo logran. Es definitivo: cuando ingresa o sale una persona de un equipo, el resultado no es el mismo equipo ‘actualizado’; es un nuevo equipo. Entender esto evitará que caigamos en el error de pretender que las cosas sigan funcionando como si nada hubiera pasado. Tienes que empezar de nuevo. Quizás con algunas heridas a las espaldas, pero es un nuevo comienzo, al fin y al cabo. A ese nuevo equipo le esperan tormentas y momentos de montaña rusa hasta que vuelva a conseguir el rendimiento que tenían antes de la ‘actualización’.

Comportamientos esperados de los equipos de alto rendimiento

¿Cómo sabes si te estás aproximando? Has liderado con esmero un equipo y quieres empezar a cosechar. Pues bien, estas son algunas de las conductas que dan indicios de que vas por buen camino:

Propósito claro: el equipo comprende y cree en sus objetivos y visión compartidos. Saben por qué existen y qué se esfuerzan por lograr.

Habilidades complementarias: los miembros del equipo tienen habilidades diversas pero complementarias, lo que garantiza que el equipo tenga la combinación necesaria de habilidades para realizar tareas y resolver problemas.

Comunicación abierta y honesta: los equipos de alto desempeño priorizan el diálogo abierto. Se sienten seguros compartiendo ideas, inquietudes y retroalimentación sin temor a represalias.

Respeto mutuo: los miembros valoran los diversos orígenes, habilidades y contribuciones de sus compañeros de equipo. Se tratan unos a otros con dignidad y consideración.

Autonomía y empoderamiento: estos equipos suelen tener autonomía para decidir cómo lograr sus objetivos, fomentando un sentido de propiedad y responsabilidad.

Liderazgo fuerte: el liderazgo eficaz proporciona dirección, establece expectativas y apoya al equipo para lograr sus objetivos. Sin embargo, dentro de los equipos de alto rendimiento, el liderazgo suele convertirse en una responsabilidad compartida.

Altos niveles de confianza: la confianza es fundamental. Los miembros del equipo creen en la confiabilidad e integridad de sus colegas.

Resolución eficaz de conflictos: los conflictos, cuando surgen, se abordan de manera constructiva y colaborativa, asegurando que conduzcan al crecimiento y al aprendizaje en lugar de a la negatividad.

Retroalimentación y mejora continuas: los equipos de alto desempeño reflexionan constantemente sobre su desempeño y buscan formas de mejorar, asegurando que sus métodos y estrategias estén siempre evolucionando.

Compromiso con la excelencia: existe un compromiso compartido de ofrecer los mejores resultados posibles, que a menudo van más allá de lo esperado.

Responsabilidad compartida: todos asumen la responsabilidad de los éxitos y fracasos del equipo. No existe un juego de culpas; en cambio, aprenden colectivamente de cada experiencia.

Alineación con las metas organizacionales: si bien pueden funcionar con cierto nivel de autonomía, los equipos de alto desempeño alinean sus objetivos con las metas más amplias de la organización.

Entre algunas otras. En esencia, un equipo de alto rendimiento es más que un simple grupo de personas capacitadas. Es una unidad cohesiva que capitaliza la inteligencia colectiva, el respeto mutuo y la visión compartida para lograr consistentemente resultados notables.

En el corazón palpitante de nuestra era BANI, donde el cambio es la única constante, los equipos de alto rendimiento se elevan no solo por su agilidad o producción. Es la alegría y la unidad de su gente lo que enciende su verdadero poder transformador, convirtiendo los desafíos en olas de innovación y dejando marcas imborrables de impacto positivo.