basada en la Guía Scrum original, de Ken Schwaber yJeff Sutherland (40)

Collected Resources for Paquete de expansión de la Guía Scrum
Este documento es una colección de trabajos independientes. Cada sección mantiene su licencia o copyright, tal como se indica. Por favor, refiérase a cada sección para conocer sus requisitos y derechos de uso.

Section 1: Paquete de expansión de la Guía Scrum 1 (Adaptation)
Title: Paquete de expansión de la Guía Scrum Adaptation of: The original Scrum Guide
Author: Ralph Jocham, John Coleman, and Jeff Sutherland.
Source: 2020 Scrum Guide , Paquete de expansión de la Guía Scrum
License: Creative Commons Attribution-ShareAlike 4.0 International ( CC BY-SA 4.0 ).
© 2025 Ralph Jocham, John Coleman, and Jeff Sutherland.
Modification Notice: This is an adaptation of the original 2020 Scrum Guide . Changes have been made from the original.
Disclaimer: No warranties are given. Use at your own risk.
This section is offered under the Attribution-ShareAlike 4.0 International license of Creative Commons.
By using this Paquete de expansión de la Guía Scrum, you agree to the terms of the CC BY-SA 4.0 license.

Contexto

Ken Schwaber y Jeff Sutherland lideraron el desarrollo del marco de trabajo Scrum. La Guía Scrum 2020 (40) describe la esencia de Scrum. La Guía simple a Scrum (58) es una versión compacta de la Guía Scrum oficial de Ken Schwaber and Jeff Sutherland. Scrum Hexis (52) interpreta la Guía Scrum 2020 (40) desde la perspectiva de 2025. Para conseguir una adopción masiva, la Guía Scrum (40) debía ser simple.

Propósito del Paquete de expansión de la Guía Scrum

Para favorecer una adopción más exitosa de Scrum, este paquete de expansión ofrece una orientación adicional adaptada a los tiempos actuales, basada en la Guía Scrum 2020 de Ken Schwaber y Jeff Sutherland (40). La contribución de Ralph Jocham (89) a la Guía Scrum aporta una mayor profundidad incorporando sus ideas originales en este paquete de expansión.

Este paquete de expansión explica el qué y el por qué de cada elemento de Scrum con una mirada orientada al futuro. Cada elemento cumple una función específica y contribuye al valor general y los resultados que se pueden obtener con Scrum. Este paquete de expansión evolucionará de forma periódica. Se espera que el lector lea el documento de manera secuencial, al menos la primera vez.

Este documento supone que quien lo lee ya tiene cierta familiaridad con Scrum y su vocabulario. En caso contrario, se recomienda leer antes la Scrum Guide 2020. Se incluyen referencias a otras fuentes para facilitar el aprendizaje. El apéndice y las referencias ofrecen una oportunidad para explorar, investigar y aprender con mayor profundidad y perspectiva.

Quienes practican[a] Scrum o se relacionan con él deberían adoptarlo cuando sea adecuado, con autonomía, información y decisiones emergentes, valor, transparencia, inspección, adaptación, ritmo y resiliencia, mejorando continuamente para alcanzar los objetivos del producto y de la organización. Se espera que muchas implementaciones de Scrum vayan más allá de lo que aquí se presenta —en teoría, roles, artefactos, eventos, escalado y demás aspectos— que despierten curiosidad duradera por explorar, cuestionar y seguir aprendiendo.

Este Paquete de expansión está diseñado para apoyar a los equipos autogestionados (49) en todos los aspectos de la entrega de productos, según las necesidades o intereses de las personas implicadas para abordar un problema u oportunidad. Esto incluye, entre otros, al descubrimiento, desarrollo, entrega y validación del valor del producto. Aunque Scrum se originó en el desarrollo de software, hoy se ha adoptado ampliamente en muchos otros ámbitos, permitiendo generar valor en trabajos complejos (30–35). A medida que se amplía su uso, otros profesionales como ingenieros, programadores, investigadores, analistas, abogados, especialistas en marketing o científicos aplican Scrum con éxito en sus respectivas disciplinas.

El valor que genera para las personas implicadas hace referencia a cualquier necesidad que una persona (incluyendo, entre otras, a clientes, decisores o usuarios) lo considere importante y que un equipo les entrega. Sin embargo, esas personas no siempre son conscientes de lo que podría aportarles valor. La observación o la evidencia pueden poner de manifiesto ese valor, de forma intencionada o no, y modificar las prioridades. A medida que aparece nueva información, es necesario identificar, inspeccionar, refinar y adaptar aquello que podría ser valioso. El valor sigue siendo una hipótesis hasta que se confirma mediante evidencia, como observación o resultados medidos.

Scrum en pocas palabras

Scrum es un marco de trabajo para la entrega de productos complejos (30–35), donde la experiencia es valiosa para tomar decisiones, pero no suficiente, y la relación causa-efecto solo es evidente a posteriori. Scrum aborda todo el ciclo de vida del producto, incluyendo entre otros, su creación, sustitución, mantenimiento, adaptación, evolución y retirada, tanto a nivel de producto como de sus funcionalidades[b][c][d]. Scrum ayuda a las personas, equipos y organizaciones a ganar flexibilidad y generar valor adaptándose al cambio.

Scrum favorece un entorno donde las necesidades de las personas implicadas se comprenden y atienden de forma coherente. Su enfoque iterativo e incremental reduce riesgos y promueve la mejora continua. Scrum ayuda a los equipos a equilibrar la exploración de problemas, la identificación de necesidades (incluyendo las de los clientes), la entrega de soluciones, la gestión proactiva del riesgo y la validación del valor.

Un riesgo se define como cualquier factor que podría provocar una consecuencia adversa a futuro. Como la exposición al riesgo sigue siendo impredecible con el paso del tiempo, anticiparse es clave. La exposición al riesgo puede incluir, entre otros, el riesgo de mercado, ajuste problema-solución, ajuste producto-mercado, tecnología, detección de señales, capacidad de respuesta, cumplimiento normativo, corrección, malas decisiones de compromiso, etc. Scrum apoya la gestión proactiva del riesgo y el descubrimiento de oportunidades.

Scrum promueve reducir la separación entre las personas implicadas que plantean problemas u oportunidades y quienes los abordan.

En resumen, Scrum se basa en un entorno donde:

1. Las personas implicadas que impulsan el cambio (en adelante, aliados) hacen lo necesario para apoyar y reforzar de forma proactiva la adopción de Scrum, guiadas y respaldadas por el Scrum Master.
2. El Propietario del producto define el objetivo del producto (Product Goal), clave para generar valor para las personas implicadas.
3. El equipo Scrum autogestionado (49) define, refina y convierte el trabajo seleccionado en resultados valiosos.
4. El equipo Scrum y las personas implicadas inspeccionan los resultados durante el Sprint y adaptan lo necesario.
5. Los aliados ayudan al equipo Scrum a prosperar.
6. Repetir

Una entrega (release) es el proceso de poner a disposición una versión nueva o actualizada del producto para las personas implicadas (incluyendo, entre otras, a clientes, responsables de decisión y los usuarios). Marca un punto de inflexión en el ciclo de desarrollo y representa la transición del producto desde su creación hasta su disponibilidad para su uso y la posible generación de valor.

Scrum es intencionadamente incompleto. En lugar de prescribir procesos detallados, proporciona un marco que guía las relaciones y las interacciones con propósito. Diversos procesos, técnicas y métodos pueden complementar Scrum, pero su aplicación depende del contexto y varía según el uso.

Scrum se puede integrar con prácticas existentes o, en algunos casos, hacerlas innecesarias u obsoletas. Scrum fomenta la mejora continua al evaluar de forma transparente la efectividad del equipo Scrum, de los aliados, del entorno de trabajo y de las técnicas utilizadas.

En el contexto del trabajo del conocimiento, el término Scrum —tomado del rugby— fue acuñado por Takeuchi y Nonaka (29) para describir equipos que trabajaban de esta forma y donde el conocimiento se difundía rápidamente por toda la organización para entregar productos excepcionales.

Teoría de apoyo y complementaria

Scrum se fundamenta en un equipo Scrum autogestionado (49), la información y decisiones emergentes, el empirismo (67) y el pensamiento lean (63). Se apoya además en la teoría y principios complementarios que se detallan a continuación, así como en ideas como:

• La responsabilidad compartida,
• La reducción del desperdicio que no aporta valor (incluidas las ineficiencias organizativas),
• El enfoque del trabajo como problemas u oportunidades,
• Descubrimiento, entrega y validación de valor, y
• La mejora continua.

Complejidad: el caso de Scrum

En trabajos complejos, como la construcción de productos, hay más incógnitas que certezas. La experiencia es valiosa, pero no suficiente, y la relación causa-efecto solo se entiende a posteriori. El pensamiento sobre la complejidad (30–35) ofrece herramientas e ideas útiles, y facilita la obtención de perspectivas para abordar este tipo de trabajo. Las personas del equipo Scrum necesitan tiempo para pensar, ayudarse mutuamente, rehacer o cambiar de dirección. La diversidad cognitiva y el empirismo pueden ayudar a abordar el trabajo complejo.

Todo lo que se considera “conocido” —incluyendo el mercado y las personas implicadas (como clientes u otros actores)— puede ser incorrecto. Algunas expectativas, necesidades o deseos emergen o pierden relevancia con el tiempo.Un enfoque empírico proporciona mecanismos para probar, inspeccionar y adaptar suposiciones.

En general, nada permanece en el mismo espacio para siempre. El equipo Scrum puede encontrarse al borde del caos, investigando o trabajando en algo sin precedentes, que nunca se había hecho antes.[e][f] Con el tiempo, a medida que descubre patrones y heurísticas, el entorno se vuelve menos caótico y más complejo. Más adelante, puede que el equipo se acerque a un espacio más ordenado —algo difícil pero planificable—, o que ocurra lo contrario. Es una buena práctica que el equipo Scrum se detenga a reflexionar si realmente está en el tipo de espacio que cree para la situación en cuestión. Lo fundamental es que el desarrollo de productos suele estar marcado por la imprevisibilidad, y Scrum puede ser más útil que otros enfoques que se basan en la ilusión de la predictibilidad.

La información y decisiones emergentes ofrece muchas oportunidades a través de la inspección y adaptación del quién, porqué, qué, cómo, dónde y cuándo. Es importante reducir lo que no funciona y amplificar lo que sí. La transparencia, la inspección y la adaptación orientadas a objetivos concretos, informadas por resultados (y consecuencias no previstas), generan valor, aprendizajes, alertas y suposiciones desafiadas; todo ello puede favorecer la mejora continua.

La confianza se construye a través de un equipo autogestionado, de la inspección y adaptación, de la entrega de trabajo valioso y descubrimiento de nuevos aprendizajes.

información y decisiones emergentes {#información y decisiones emergentes}

La información y decisiones emergentes (71) ocurre cuando surgen patrones o comportamientos significativos a partir de interacciones dentro de sistemas complejos (30–35); patrones que no pueden predecirse simplemente observando las partes por separado. En Scrum, la información y decisiones emergentes no se controla de forma estricta, sino que se guía mediante restricciones habilitadoras como los eventos limitados en tiempo, los roles y los ciclos de retroalimentación. Estas condiciones favorecen la autogestión y la adaptabilidad sin imponer resultados concretos. Estas estructuras actúan como “islas” en un mar de imprevisibilidad, al igual que ciertos sistemas físicos pueden formar patrones organizados de forma espontánea en medio del desorden, como describe Stephen Wolfram (38). La clave es que la estructura de Scrum ofrece suficiente orientación para que los equipos se autogestionen y surjan nuevas soluciones, en lugar de prescribir cada detalle.

Los equipos Scrum, que operan como sistemas adaptativos complejos, se ven influidos —no dirigidos— a través de experimentos cortos, paralelos y seguros para fallar, y mediante retroalimentación continua. Patrones como Swarming, Equipos estables y Kaizen (53) ayudan a identificar y modelar comportamientos emergentes. En lugar de forzar resultados, Scrum permite que el equipo descubra patrones deseables, incluyendo soluciones innovadoras o nuevas formas de trabajo, y los potencie, al tiempo que atenúa los que no resultan útiles.

Este enfoque reconoce que la autogestión (49) no se diseña desde arriba, sino que se descubre cuando se da el entorno adecuado: uno que sea coherente, con propósito y vital, en línea con la idea de “Calidad sin nombre” de Christopher Alexander (39). En última instancia, Scrum no trata la información y decisiones emergentes como un riesgo a evitar, sino como una fuerza a cultivar para alcanzar la excelencia en el desarrollo de productos.

Equipo Scrum autogestionado

Un equipo Scrum autogestionado (49) verifica si está alineado con su objetivo, actúa cuando no lo está, decide cómo trabajar, resuelve conflictos internos y soluciona sus propios problemas. Esto significa que, en general, las figuras de gestión tradicionales (111), cuando existen en el entorno, no deben indicar al equipo qué hacer ni quién debe encargarse de qué, ya sea directa o indirectamente. En su lugar, es preferible que esas figuras se enfoquen en el liderazgo.

Los equipos Scrum autogestionados, organizados en torno a la generación de valor, son fundamentales para resolver problemas de forma creativa y para que emerjan soluciones útiles. En cambio, depender de equipos que no se autogestionan limita la capacidad de afrontar la complejidad (30–35). Un equipo Scrum autogestionado no debe confundirse con la autogestión individual: es la coordinación fluida entre sus miembros lo que permite que emerja un gran equipo. Facilitar la autonomía colectiva y una toma de decisiones ágil en estructuras no jerárquicas puede ayudar a los equipos Scrum a mejorar su capacidad de autogestión.

Profesionalismo

El profesionalismo consiste en aspirar a la excelencia y colaborar para entregar valor de forma respetuosa, transparente y con sentido de responsabilidad. Ser profesional implica hacer siempre ciertas cosas —y evitar otras— independientemente de las circunstancias.

Implica asumir la responsabilidad total del producto, desde su concepción hasta su retirada, a lo largo de todo su ciclo de vida. Incluye también su mantenimiento, que a menudo se manifiesta como operaciones, y ofrece valiosas oportunidades de aprendizaje técnico para las personas desarrolladoras del producto a partir de la retroalimentación.

En el desarrollo de software, el profesionalismo incluye, entre otros, la excelencia técnica (112). Esta comprende prácticas como: especificación por ejemplo, código limpio, integración continua, entrega continua, arquitectura y diseño, así como pruebas intencionadas y rigurosas a varios niveles (unitarias, de aceptación, automatizadas, desarrollo guiado por pruebas).

Pensamiento Lean

El pensamiento lean (63) reduce el desperdicio en el trabajo y en la forma en que se lleva a cabo, y se enfoca en el flujo de valor y la mejora continua. Sus principios se basan en la mejora continua y el respeto por las personas. Al enfocarse en estos principios, las organizaciones pueden mejorar su efectividad con el menor coste a largo plazo, entregar mayor valor a sus clientes y fomentar un entorno de aprendizaje y desarrollo constante.

Empirismo

El empirismo (67) es el principio de tomar decisiones basadas en evidencia objetiva u observable, dentro de ciclos de aprendizaje, a menudo exploratorios. Es útil en situaciones donde la experiencia por sí sola no basta. Scrum se fundamenta en el empirismo: las decisiones se toman a partir de la evidencia o de lo que se observa. Un enfoque empírico implica observación continua, desarrollo o refinamiento de teorías, puesta en práctica y validación o ajuste, con el objetivo de establecer bucles de retroalimentación efectivos.

El empirismo puede ayudar a los equipos Scrum a entregar algo que las personas implicadas consideren valioso cuando el qué o el cómo no están claros. Scrum trata de hacer probable lo improbable mediante el descubrimiento, la entrega y la validación de valor; esto a menudo implica, entre otras cosas, decisiones de compromiso o experimentación. Los experimentos suelen basarse en hipótesis comprobables, aunque a veces se apoyan en intuiciones fundamentadas. Una respuesta clave a la experimentación es tomar decisiones informadas por la evidencia.

Pausar y reflexionar combina elementos del empirismo y del pensamiento lean, sienta las bases para la transparencia, la inspección y la adaptación hacia el objetivo del producto, y ayuda tanto al equipo Scrum como a los aliados a mejorar su propio desempeño y entorno.

Una adopción eficaz de Scrum reduce la distancia entre las personas implicadas que plantean problemas u oportunidades y quienes los abordan, al mantener objetivos tangibles y significativos, y al entregar valor de forma rápida y frecuente. Las personas implicadas a menudo tienen una falsa sensación de certeza sobre el qué y el cómo. El equipo Scrum, por su parte, puede tener una falsa seguridad sobre quién se ve afectado. Inspeccionar y adaptarse debe valorarse más que cumplir promesas o servir a las personas equivocadas. Todas las suposiciones pueden estar equivocadas.

Ritmo

Trabajar en Sprints proporciona un ritmo constante que ayuda al equipo Scrum a centrarse en objetivos claros a corto plazo. Este ritmo facilita la inspección y adaptación regulares, lo que permite al equipo aprender y ajustarse a partir de la retroalimentación. Con el tiempo, esto construye un ritmo sostenible de entrega, mejora la previsibilidad y fomenta la mejora continua.

Los tres pilares del control empírico de procesos en Scrum

En su esencia, el empirismo es la filosofía según la cual el conocimiento surge de la experiencia y la observación. Los aprendizajes valiosos emergen de la curiosidad, la experimentación, los datos, la visualización y la observación. El control empírico de procesos (64–66) es un enfoque para gestionar procesos complejos (30–35), como los que se encuentran en Scrum, mediante la adaptación informada por resultados observados, y se basa en tres pilares: transparencia, inspección y adaptación.

Transparencia

La transparencia es un pilar de Scrum. Revela la realidad, da claridad al trabajo y habilita el empirismo. Permite una percepción más precisa de lo que ocurre y es el punto de entrada a la inspección y la adaptación. El proceso emergente, el trabajo y los resultados deben ser visibles tanto para quienes ejecutan el trabajo como para quienes reciben las entradas, ya sea en forma de objetivos, elementos del Backlog de Producto o incrementos generados.

Las decisiones importantes se toman a partir de artefactos, experimentos, entregas o análisis de resultados. Una baja transparencia puede dificultar la inspección, lo que lleva a decisiones que reducen el valor y aumentan el riesgo. La transparencia hace posible la inspección.

La retroalimentación basada en resultados es información —idealmente tanto cuantitativa como cualitativa— que puede surgir a partir de cambios en el producto o en el entorno. Aporta claridad sobre el valor generado, el esfuerzo realizado, los recursos empleados o los costes. Las personas no son recursos.

Alcanzar la transparencia puede ser poco realista o incluso inaplicable si existen ineficiencias institucionales o falta de confianza. Como consecuencia, Scrum puede hacer transparentes esas ineficiencias, y con voluntad colectiva, se puede construir la confianza.

Inspección

La inspección es un pilar de Scrum. Consiste en observar la realidad en relación con la dirección del producto (el objetivo del producto) así como con la efectividad del equipo Scrum y de las personas implicadas. La inspección posibilita la adaptación. Inspeccionar implica observar intencionadamente lo que se ha hecho visible, incluidos los datos y observaciones. Para fomentar la inspección y la adaptación, Scrum proporciona ritmo mediante sus eventos.

Los artefactos de Scrum, sus compromisos asociados y el progreso hacia los objetivos acordados deben inspeccionarse con frecuencia y rigor para detectar fenómenos emergentes (71). La inspección de artefactos, experimentos, entregas, del mercado o de la retroalimentación puede generar aprendizajes o efectos secundarios. Estos últimos son resultados inesperados o no intencionados.

La inspección sin transparencia está mal informada, induce al error y resulta ineficiente.

Adaptación

La adaptación es un pilar de Scrum. Dada la dirección del producto, se espera que el equipo Scrum y las personas implicadas se adapten a la realidad tan pronto como surjan oportunidades de mejora, como resultados de experimentos, aprendizajes, riesgos u oportunidades. Adaptarse se vuelve más difícil cuando existen ineficiencias institucionales o cuando las personas implicadas no están preparadas, dispuestas o capacitadas para hacer lo necesario.

La adaptación comienza con aceptar la “realidad”, informada por evidencia. Suele manifestarse en los artefactos de Scrum, los compromisos asociados, el equipo Scrum, las personas implicadas, el liderazgo y la organización. Si algún aspecto se desvía más allá de los límites aceptables, o si el producto resultante no es aceptable, deben hacerse ajustes lo antes posible para corregir el rumbo.

Sin adaptación, la transparencia y la inspección pierden sentido.

Los valores de Scrum

Los valores de Scrum foco, apertura, compromiso, coraje y respeto ayudan a crear un entorno dentro del equipo Scrum que favorece la seguridad psicológica y la colaboración positiva, en línea con principios identificados por la neurociencia como beneficiosos para el aprendizaje y el trabajo en equipo eficaz. Todo depende del contexto.

Los valores de Scrum fomentan la transparencia y la confianza, asegurando la coherencia entre lo que se dice y lo que se hace. Juntos, crean una base sólida para la colaboración, el rendimiento y la coherencia dentro del equipo Scrum.

El éxito en la adopción de Scrum depende de que el equipo Scrum y los aliados (y otras personas implicadas) lideren con el ejemplo, como profesionales. Los valores de Scrum ayudan a fortalecer la confianza dentro del equipo y con las personas implicadas. También promueven una ética compartida (57), un lenguaje común, un tono respetuoso, y comportamientos que fomentan la confianza. Ayudan a reducir o evitar la distancia entre lo que se dice y lo que se hace.

El equipo Scrum y los aliados acuerdan ser abiertos sobre el trabajo y los desafíos. La humildad sostiene la apertura. La apertura requiere confianza, y la confianza requiere apertura. Se espera que soliciten y compartan retroalimentación constructiva. Colaboran y aprenden habitualmente mediante conversaciones de alta calidad y feedback cualitativo o cuantitativo.

Las conversaciones de alta calidad son aquellas que permiten el intercambio más rico, rápido y claro de información. Suelen ocurrir cara a cara —ya sea en persona, por videollamada, usando tableros visuales o pizarras físicas o digitales— donde se puede comunicar no solo con palabras, sino también con tono de voz, expresiones, dibujos o lenguaje corporal para lograr comprensión mutua.

Dado que los Sprints son cortos, cualquier fallo debe ser también breve y limitado. El riesgo se identifica y se gestiona mediante retroalimentación rápida y abierta. Quizás el único fracaso real sea no aprender.

El equipo Scrum y los aliados deben tener el coraje de hacer lo correcto y enfrentar los desafíos difíciles. Deben mostrarse valientes al explorar lo desconocido, cambiar de dirección, pedir o compartir información, y participar en desacuerdos respetuosos, como conflictos saludables y disensos constructivos. El equipo Scrum debe pedir ayuda a los aliados o a los líderes si lo necesita.

El equipo Scrum se compromete con lograr el objetivo del Sprint y apoyarse mutuamente. Comprometerse implica completar el trabajo relevante hacia ese objetivo conforme con la definición de “terminado”, preferiblemente antes de finalizar el Sprint. También implica alcanzar los resultados deseados mediante la creación de valor.

Su foco principal es avanzar lo máximo posible hacia el objetivo del Sprint. El foco secundario es avanzar hacia el objetivo del producto. Los aliados se comprometen a ofrecer un entorno psicológicamente seguro para que el equipo Scrum entregue incrementos. Dentro de ese foco, el equipo Scrum y los aliados se comprometen a crear espacios para el aprendizaje continuo, la adaptación y el intercambio de aprendizajes entre equipos Scrum, asegurando efectividad a largo plazo. El equipo y las personas implicadas deben abordar de forma consciente los dilemas, incluyendo los logros rápidos que pueden tener consecuencias a largo plazo.

El equipo Scrum y los aliados (y otras personas implicadas) se respetan mutuamente como profesionales competentes. Respetan las diferentes perspectivas y especialidades, y se comportan de forma constructiva cuando no están de acuerdo. El respeto apoya la confianza. El equipo Scrum y los aliados deben criticar ideas o enfoques para encontrar alternativas más efectivas, y no a las personas.

El respeto ayuda a evitar que los demás valores de Scrum se usen de forma distorsionada. Las demostraciones de respeto pueden incluir, entre otros, elogios genuinos, apoyo mutuo, humildad, seguridad psicológica, desacuerdos constructivos y diversidad cognitiva.

Los miembros del equipo Scrum y las personas implicadas pueden observar los valores de Scrum a través del marco OODA de John Boyd (99, 100, 102). OODA fue creado por el coronel John Boyd de la Fuerza Aérea de EE. UU. para ayudar a los pilotos a tomar decisiones rápidas e inteligentes en situaciones cambiantes, mediante cuatro pasos: Observar, Orientar, Decidir y Actuar. Es una forma simple, continua, iterativa y poderosa (aunque muchas veces inconsciente) de afrontar la incertidumbre: observar cambios del mercado, analizar tendencias y riesgos, elegir funcionalidades para probar, y entregarlas. Scrum puede mejorar el uso del OODA.

Los miembros individuales del equipo pueden aplicar los valores de Scrum en cada paso del OODA para favorecer soluciones emergentes. En este contexto, los valores de Scrum son útiles de la siguiente manera:

• Observar — La apertura y el respeto favorecen la recopilación de evidencia y perspectivas diversas.
• Orientar — El coraje es necesario para interpretar la realidad, moverse en la incertidumbre, y decidir adaptarse o cambiar, haciendo pausas reflexivas para desafiar suposiciones y generar nuevos aprendizajes.
• Decidir — Tomar decisiones requiere análisis oportuno, como el refinamiento del backlog, trayendo a primer plano las siguientes posibles acciones a través de experimentos paralelos y seguros para fallar, para validar hipótesis (los experimentos deben ser pequeños, paralelos y diseñados para que su posible fallo sea informativo y asumible).
• Actuar — Con claridad sobre qué hacer, por qué y quién lo hará, el compromiso impulsa al equipo a ejecutar eficazmente dentro de las restricciones habilitadoras como los Sprints con duración acotada, permitiendo que emerjan soluciones útiles.

Más teoría de apoyo y complementaria

Pensamiento de producto

Las personas consumen productos (incluidos servicios), no proyectos. Un producto es el canal para entregar valor, equilibrando el corto y el largo plazo. Por eso Scrum tiene un Propietario del producto y no un Project Owner. Los productos tienen una vida útil prolongada y deben cuidarse durante toda su existencia, mientras que un proyecto está acotado en el tiempo y, a menudo, deja un producto huérfano cuando se termina.

El pensamiento_de_producto (86–88) aborda la tensión (111) entre enfocarse en el crecimiento a corto plazo y atender también preocupaciones a largo plazo: lograr tracción con los primeros usuarios, “cruzar el abismo” (5), escalar, lanzar nuevas versiones, mantener la evolución continua, maximizar el valor del cliente a lo largo del tiempo y controlar el coste total de propiedad.

Para “cruzar el abismo”, se necesita un cambio estratégico: pasar de dirigirse a usuarios innovadores y tolerantes al riesgo a convencer a compradores, responsables de decisión y usuarios más pragmáticos y adversos al riesgo. Esto se logra enfocándose en un nicho específico y entregando una solución completa, confiable y útil. Este paso es crucial para que un producto pase de tener éxito en un nicho a lograr una adopción generalizada. El segmento de mayoría temprana suele requerir evidencia clara de la fiabilidad del producto y su capacidad para resolver problemas en un contexto concreto. Al enfocarse en un nicho y proporcionar una solución completa, una organización puede ganar credibilidad, obtener referencias de clientes satisfechos y establecer una posición sólida en el mercado, superando así el abismo entre los primeros usuarios y el mercado masivo.

Los Propietarios del Producto deben dominar el equilibrio, el aquí_y_ahora y el allí_y_después (148), mediante coraje, humildad, consulta, colaboración, conflictos_saludables, entre otros.

Cuando las personas implicadas piensan únicamente en el corto plazo, es probable que sufran consecuencias a largo plazo como deuda técnica, baja moral del equipo Scrum, exceso de carga, o una obsesión por la producción. Por eso, es necesario incorporar factores que compensen esa visión y refuercen la sostenibilidad a largo plazo.

La deuda técnica es el trabajo adicional que se acumula —consciente o inconscientemente— cuando se toman atajos en el diseño o la implementación para entregar algo más rápido. Con el tiempo, esta deuda ralentiza el progreso, igual que una deuda financiera: genera “intereses” al dificultar o arriesgar cambios futuros. Las personas profesionales intentan minimizar al máximo la deuda técnica y la negligencia. Si deciden asumir deuda, esta debe ser transparente y, si es posible, contar con un plan emergente de mitigación.

En el caso de los productos, Scrum apoya la factibilidad, usabilidad, deseabilidad, valor y viabilidad dentro de límites éticos (57), mediante:

• Diseño de producto
• Gestión de producto
• Consideración intencionada de la interacción entre personas implicadas, investigación, objetivos, descubrimiento, diseño, entrega y validación continua de valor
• En productos tecnológicos, mediante ingeniería de producto.

Scrum favorece un equilibrio saludable entre el corto y el largo plazo. La orientación a objetivos permite explorar resultados potenciales poniendo el foco en el valor y la reducción de riesgos. El objetivo del Sprint (aquí y ahora) debería ser un paso hacia el objetivo del producto (allí y después), que a su vez habilita caminos hacia el largo plazo. El objetivo del producto suele apoyar la estrategia y la visión del producto.

Pensamiento sistémico

El pensamiento sistémico (55) reconoce la interconexión de elementos dentro de contextos organizativos y sociales, entendiendo que las acciones en un área tienen repercusiones no siempre predecibles o lineales. Los experimentos basados en teoría, los bucles de retroalimentación y el análisis posterior de datos ayudan a revelar aprendizajes útiles y aplicables. El pensamiento sistémico proporciona herramientas valiosas y favorece el entendimiento.

Para que una organización sea adaptativa (80), es necesario evitar suboptimizaciones locales como reducir costes por unidad mientras se aumentan los costes a largo plazo, debilitar la calidad y perder la confianza del cliente, o mejorar un equipo, flujo o proceso que no debería existir. En el trabajo complejo (30–35), no siempre es posible vincular causa y efecto, salvo en retrospectiva. Aun así, conviene considerar los posibles efectos aguas arriba, durante el trabajo o aguas abajo de cualquier intervención.

Descubrimiento

El descubrimiento (50–51) suele comenzar con la comprensión de expectativas, necesidades y deseos de las personas, mediante la observación, análisis, conversaciones y síntesis orientadas a un resultado deseado. Una vez que el equipo Scrum obtiene aprendizajes, enmarca el problema u oportunidad y los ordena por valor potencial. Luego, genera soluciones posibles sin evaluarlas de inmediato. Si el valor potencial es alto pero no hay suficiente evidencia de que se pueda realizar, el equipo debería investigar, validar suposiciones o crear prototipos simples que puedan probar con clientes reales, responsables de decisión o usuarios. El descubrimiento nunca termina: conviene realizar entrevistas u observaciones periódicas.

El descubrimiento consiste en aprender con dirección clara hacia un resultado deseado, priorizando, ejecutando, evitando o mejorando constantemente las ideas basadas en observación, retroalimentación u otros aprendizajes. Hace hincapié en la colaboración, la creatividad y la disposición a fallar y volver a intentarlo. Enmarca el trabajo como problemas u oportunidades, y ayuda al equipo Scrum a generar, priorizar y poner a prueba opciones de solución que equilibren lo que las personas desean, lo que es técnicamente posible y lo que tiene sentido de negocio —todo ello sin perder la motivación y el disfrute.

Si se requiere descubrimiento, este debería —en la medida de lo posible— integrarse de forma coherente con Scrum. Por ejemplo, el trabajo de descubrimiento debe hacerse visible en el Backlog de Producto y el Sprint Backlog, las personas del equipo Scrum deben practicar habilidades de descubrimiento, compartir los aprendizajes durante el Sprint y en los eventos de Scrum, y producir (idealmente entregar) al menos un incremento cada Sprint, sin importar cuánto descubrimiento se haya hecho. Hay que encontrar el equilibrio: el descubrimiento puede evitar que se construya lo equivocado, pero si se exagera, también puede ser un exceso. Al final, la retroalimentación basada en resultados es lo más relevante.

Liderazgo

El liderazgo es la capacidad de influir, guiar e inspirar a un grupo de personas para lograr un objetivo compartido sin desmotivarlas. Inspira el pensamiento, acción y pasión, y favorece una dirección estratégica clara. Abarca la observación activa, la escucha y la comprensión con propósito, obteniendo hechos y observaciones que informan las decisiones; esto se conoce como Genchi Genbutsu (84).

El liderazgo es un proceso social dinámico que implica responsabilidad, construcción de relaciones y empoderamiento. Un liderazgo exitoso co-crea una dirección compartida, alinea eficazmente los recursos y las personas necesarias, y genera compromiso mutuo dentro del grupo.

Scrum promueve un tipo particular de liderazgo: un liderazgo orientado a la resiliencia. Se trata de un conjunto de cualidades, no de una posición jerárquica. Por eso, el liderazgo incluye, entre otras cosas: crear entornos para equipos Scrum autogestionados, promover la claridad, la confianza, la transparencia, la información y decisiones emergentes (71) de una dirección, la satisfacción en el trabajo, la aceptación de la incertidumbre (72) y el error, tomar decisiones basadas en evidencia, gestionar riesgos de forma proactiva y eliminar ineficiencias organizativas.

El liderazgo ocurre desde todos los ángulos, a todos los niveles, y fomenta la reflexión en el momento adecuado. Debe estar orientado implacablemente al valor, pero con compasión y ética. Requiere una acción persistente para transformar flujos de trabajo, procesos, sistemas y entornos de trabajo; esto incluye, entre otras, áreas como RR. HH., finanzas o gestión de proveedores. Una persona líder es quien demuestra liderazgo.

Los Product Owner (Propietarios del Producto) y Scrum Master equilibran el liderazgo, autoridad y control sutil proporcionando dirección clara, fomentando la iniciativa y reforzando la responsabilidad. Guían sin microgestionar, asegurando que el equipo Scrum comprenda la visión y los objetivos, tenga autonomía para ejecutar y se responsabilice de los resultados. Cuando se necesita intervenir, lo hacen con determinación, respetando la autonomía del equipo. Los desarrolladores de producto demuestran liderazgo mediante su orientación a la autogestión, su profesionalismo y su enfoque en objetivos; la autogestión conlleva responsabilidades. Los aliados demuestran liderazgo apoyando la eliminación de impedimentos a corto y largo plazo, mejorando la coherencia entre la gestión y Scrum, y apoyando el cambio emergente cuando se les solicita.

Pensamiento desde los primeros principios

Pensar desde los primeros principios es un método para resolver problemas que consiste en descomponer los desafíos hasta llegar a sus verdades fundamentales, y reconstruir las soluciones desde cero. En lugar de apoyarse en analogías o convenciones, este enfoque plantea: "¿Qué_sabemos_con_certeza?" y desde ahí, se reconfiguran el entendimiento y las soluciones.

Algunos ejemplos son:

• Animar al equipo Scrum a centrarse en los factores clave de efectividad, adaptabilidad (80) y oportunidad, como la autonomía, la transparencia y la adaptación, en lugar de seguir procesos de forma acrítica.
• Cuestionar cada suposición y construir soluciones a partir de hechos y principios esenciales, lo que puede permitir avances significativos.
• Fomentar el pensamiento original, la mejora continua y el coraje para desafiar el statu quo, desbloqueando creatividad y posibilitando resultados transformadores.

Personas y cambio

La dificultad de adoptar Scrum no debe subestimarse. Los elementos de Scrum ofrecen principios orientadores a un enfoque para volver a los primeros principios.

Scrum no se trata de adoptar herramientas. Y Scrum tampoco termina con la eliminación de impedimentos. Un impedimento es cualquier cosa que bloquee o retrase el avance. Es crucial actuar con intención, perseverancia y tenacidad en relación con las personas, el cambio y la comunicación. El cambio a menudo implica desarrollo personal, rediseño de flujos, procesos, sistemas, actitudes, comportamientos, lenguaje, hábitos y clima laboral. La cultura es un resultado emergente.

Una adopción efectiva de Scrum se apoya en un enfoque emergente, agentes de cambio efectivos y el compromiso entusiasta de quienes se ven afectados o afectan el proceso. La intencionalidad y el progreso diario en la adopción son clave. El trabajo de adopción es importante y no debería dejarse para lo último.

Comienza con un cambio emergente disciplinado y con dirección. La meta es que el cambio se vuelva tan natural que pase a formar parte del trabajo planificado. Una adopción de Scrum tiene dirección, pero no destino predeterminado. El cambio es emergente y, por tanto, impredecible. La curiosidad permite detectar, escuchar, aprender y adaptarse en una dirección. Es importante construir relaciones, comprender perspectivas, escuchar lo que no se dice y observar lo que no ocurre. El cambio requiere esfuerzo, pero también puede ser satisfactorio.

Los roles de Scrum en el Paquete de expansión

Los cuatro roles de Scrum son Propietario del producto, Desarrollador, Scrum Master y las partes interesadas. Estos roles crean, recompensan y ganan confianza, y habilitan un liderazgo coherente. Solo las tres responsabilidades (Propietario del producto, desarrollador y Scrum Master) forman parte del equipo Scrum.

Una misma persona puede asumir más de un rol de Scrum. Si lo hace, debe tener cuidado de no sobrepasar los límites. Los roles de Scrum están diseñados para mantener un equilibrio de pesos y contrapesos.

Un equipo Scrum es un equipo que practica Scrum, asume las tres responsabilidades clave (Scrum Master, Propietario del producto y desarrolladores), aborda los problemas u oportunidades planteados por las personas implicadas (como clientes o usuarios), y entrega incrementos útiles, usables y potencialmente valiosos desde las perspectivas del equipo Scrum y de las personas implicadas, avanzando hacia el objetivo del producto. Para trabajo complejo (30–35), un equipo Scrum debe ser pequeño, diverso en su forma de pensar y autogestionado. Sus miembros, con ayuda de la tecnología si es necesario, se interesan por el trabajo del resto y aprenden a colaborar de forma cruzada.

El equipo Scrum debe ser multifuncional, es decir, contar con competencias tanto técnicas como de negocio. No existe jerarquía explícita dentro del equipo. El equipo Scrum debe tener todas las habilidades y apoyos necesarios para:

• Descubrir (incluyendo investigación y diseño) según sea necesario,
• Entregar (incluyendo ingeniería cuando corresponda), y
• Validar la realización de valor (así como la usabilidad, deseabilidad y viabilidad dentro de los límites éticos establecidos) (57).

El equipo Scrum, con el apoyo de los aliados, se ocupa colectivamente del problema u oportunidad, del descubrimiento del producto, su entrega, verificación y calidad integrada, de su salida al mercado y de la validación de valor, siempre en relación con el objetivo del producto. Como equipo autogestionado (49), decide quién hace qué, cómo, cuándo y dónde.

La validación del valor es la confirmación (o refutación) de que se ha alcanzado el resultado esperado.

El equipo Scrum entrega uno o más incrementos en cada Sprint, se autogestiona (49) de forma continua para detectar y resolver problemas, se sincroniza constantemente y realiza entregas frecuentes. Es lo bastante pequeño como para mantener agilidad, y lo bastante grande como para completar trabajo significativo dentro de un Sprint. A menudo, los equipos Scrum más pequeños se comunican mejor y son más productivos.

Scrum se basa en equipos Scrum autogestionados (49) dentro de una estructura organizativa o de producto definida. Estos equipos tienen autonomía, pero enmarcada por los eventos de Scrum, las responsabilidades, artefactos, compromisos, pilares, valores y necesidades organizativas.

Scrum reúne a grupos de personas que, colectivamente, tienen o adquieren todas las habilidades necesarias para realizar el trabajo y comparten competencias según se requiera. Se necesitan interacciones intencionadas, apoyadas por el liderazgo, para mejorar las probabilidades de éxito.

El foco debe mantenerse en lograr los objetivo del producto de la forma más eficaz, con la inversión adecuada y generando resultados valiosos.

Scrum promueve el trabajo en equipo colaborativo, fomentando la interacción continua y la responsabilidad compartida, en lugar de realizar tareas secuenciales en silos. Este enfoque permite que el equipo Scrum y las personas implicadas asuman la incertidumbre (72), adaptándose más rápidamente gracias al aprendizaje y la retroalimentación continua. La superposición entre descubrimiento, desarrollo y validación de valor habilita un enfoque más adaptativo (80) y centrado en el valor para el desarrollo de productos.

El trabajo superpuesto fomenta la responsabilidad compartida dentro del equipo Scrum, aumentando la implicación y el compromiso. El equipo orienta su atención hacia los retos y oportunidades, estimula el comportamiento proactivo, desarrolla habilidades diversas y aumenta la conciencia sobre la dinámica del mercado entre todos sus miembros.

El equipo Scrum se encarga de todas las actividades relacionadas con el producto: desde la colaboración con personas implicadas hasta la validación del valor, incluyendo la verificación, mantenimiento, operaciones, experimentación, investigación y desarrollo, o cualquier otra que sea necesaria. El equipo Scrum incorpora la calidad. Los aliados aseguran que la organización proporcione un entorno adecuado y empodere al equipo Scrum para autogestionarse (49). Trabajar en Sprints a un ritmo sostenible mejora el foco y la coherencia.

El equipo Scrum y las personas implicadas no saben qué van a aprender. Algunos aprendizajes aportan mayor certeza, otros generan más incertidumbre (72). Algunas cosas pueden emerger, desaparecer, perder prioridad o dejar de ser relevantes.

Un equipo Scrum posee una autonomía alineada. Esto significa que tiene libertad para decidir cómo resolver los problemas, sin perder el foco en los objetivos y resultados compartidos, habilitando tanto la innovación como la coherencia organizativa. Fomentar la diversidad cognitiva del equipo Scrum es fundamental. La polinización cruzada es más probable cuando los miembros colaboran, se tienen confianza y saben autorreflexionar.

Para lograr buenos resultados, el equipo Scrum y los aliados deben cultivar la voluntad de desaprender principios obsoletos. La inspección y adaptación requieren un entorno que anticipe y tolere los errores. Es esencial centrar la crítica en las ideas, no en las personas. Todos los miembros del equipo Scrum “juegan en el mismo campo”, con trabajo superpuesto de forma coherente, y todos son responsables del éxito.

Parte interesada

La parte interesada es un rol. Puede ser una entidad, individuo o grupo que tiene interés, se ve afectado o influye en las entradas, actividades y resultados. Puede tener un interés directo o indirecto, dentro o fuera de la organización, sus productos o servicios.

Ejemplos de personas implicadas incluyen, entre otras a: clientes, decisores, usuarios, proveedores, influenciadores, gestores, compañeros, líderes, legisladores, financiadores, expertos en la materia y responsables de gobernanza. No se deben ignorar partes interesadas no humanas o inanimadas, como la ley o la inteligencia artificial. Algunas tienen más influencia o se ven más afectadas que otras, y cada una puede valorar aspectos distintos. Todas tienen un grado distinto de poder o influencia.

Un cliente es cualquier parte interesada que recibe valor del producto al adquirirlo o seleccionarlo. Puede ser quien paga (comprador), quien autoriza su uso (decisor), o quien lo usa directamente (usuario). En ocasiones, el cliente no coincide con el cliente final, como en modelos B2B2C (79) o B2B2B (78).

Para adoptar Scrum con éxito, es crucial mantener interacciones intencionales y frecuentes entre las personas implicadas (clientes y usuarios incluidos) y el equipo Scrum.

Un usuario es una parte interesada que interactúa directamente con el producto para alcanzar objetivos o resolver problemas. Vive la experiencia del producto, ya sea un servicio, plataforma o experiencia. Su retroalimentación es clave para la mejora continua. Puede o no tener poder de decisión sobre la compra, pero su adopción es esencial para el éxito del producto. A veces, el usuario no coincide con el usuario final (como en B2B2C o B2B2B). Las interacciones regulares con los usuarios y, si procede, usuarios finales, son fundamentales.

Un decisor (“chooser”, según Jeff Patton) (82) tiene autoridad para aprobar, seleccionar o autorizar la adopción o compra del producto. Evalúa opciones considerando tanto a usuarios como a la organización. Puede que no use el producto directamente, pero sus decisiones afectan directamente a qué productos se adoptan y cómo se entrega valor. En Scrum, suele ser mejor avanzar con información imperfecta y capturar retroalimentación emergente.

Los legisladores (o responsables de políticas internas o externas) establecen reglas y marcos regulatorios que guían la operación del producto. Aseguran que cumpla con los requisitos legales u organizativos y orientan su evolución y sostenibilidad. Para una buena adopción de Scrum, no se deben exagerar ni subestimar los requisitos legales.

Los financiadores aportan recursos para el desarrollo y mejora del producto. Evalúan su viabilidad y potencial de valor continuo, e influyen en su visión y estrategia para asegurar un retorno sostenible. Para adoptar Scrum con éxito, es clave mantener flexibilidad tanto en actitud como en la financiación según aparezca nueva información.

Los expertos en la materia aportan conocimiento especializado esencial. Ya sea en tecnología, diseño, cumplimiento o dominio específico, mejoran la usabilidad, profesionalismo y extensibilidad del producto, sin interferir con la autogestión del equipo Scrum (49). Ayudan a cerrar brechas de satisfacción, adaptarse y medir la información y decisiones emergentes (71). Es vital que el conocimiento fluya de forma regular desde los expertos hacia el equipo Scrum.

Una brecha de satisfacción es la diferencia entre la experiencia actual de una parte interesada y su experiencia deseada con el producto.

La gobernanza hace referencia a estructuras, normas y prácticas que guían el rumbo del producto, la toma de decisiones y la rendición de cuentas. Fomenta la transparencia y el cumplimiento de estándares de valor, viabilidad y profesionalismo. Proporciona mecanismos para gestionar los riesgos y adaptarse a cambios. Para que Scrum tenga éxito, la gobernanza debe ser coherente con Scrum: un contacto único por área, interacciones intencionadas con el equipo sobre calidad y cumplimiento, inspección y adaptación regular, y sin sorpresas.

Impulsor

El impulsor es un tipo específico de parte interesada. Son agentes de cambio que apoyan la adopción de Scrum. Suelen formar parte de una coalición potente (83) que inspira y elimina factores desmotivadores. Ayudan al equipo Scrum a prosperar y transforman los flujos de trabajo, sistemas y entornos para que sean coherentes con Scrum y con la información y decisiones emergentes (71). Deben participar cuando se les necesite o se les solicite. La creación de valor suele requerir colaboración efectiva con otras personas implicadas.

Según el tamaño de la organización algunos ejemplos de aliados son, entre otros: compañeros, responsables de decisión, financiadores, responsables de gobernanza, gestores, expertos en la materia, marketing, RR. HH., finanzas, compras y usuarios de piloto. Si un impulsor no empodera al equipo Scrum para hacer lo recomendado en este documento, en realidad no es un impulsor. Los ejecutivos y miembros del consejo tienen un papel clave en crear un clima que apoye a los aliados. Estos deben mostrar un liderazgo que el equipo Scrum aprecie.

Inteligencia artificial

La inteligencia artificial (IA) forma parte del entorno de trabajo y puede ampliar significativamente las capacidades del equipo Scrum en descubrimiento, toma de decisiones, desarrollo de producto y validación de valor.

La IA puede mejorar Scrum mediante:

• Control empírico del proceso (64–66): la analítica basada en IA mejora la transparencia, inspección y adaptación.
• Aumento cognitivo: permite que los miembros humanos del equipo se centren en cuestiones estratégicas, creativas y éticas.
• Adaptación continua de valor: puede reordenar el Backlog de Producto según la retroalimentación en tiempo real.
• Perspectiva sistémica: identifica interdependencias ocultas para mejorar la toma de decisiones.

Las posibilidades son infinitas. Un equipo Scrum podría usar IA para:

• Detectar ambigüedades en texto y revisar sus propias recomendaciones frente a sesgos o errores.
• Validar y ajustar modelos y aplicaciones regularmente.
• Mejorar la transparencia en la secuenciación del Backlog de Producto.
• Crear agentes como miembros del equipo.
• Cuestionar ideas existentes de forma intencionada.

Los riesgos también son infinitos. Debe mantenerse la responsabilidad humana sobre todos los resultados (según las responsabilidades de Scrum), utilizando la IA como socio supervisado. Esto se conoce como mantener al “humano en el bucle”. Aunque la IA puede mejorar la innovación y la eficiencia, no sustituye la responsabilidad profesional. Debe apoyar, no anular, el control empírico y la toma de decisiones ética (57). El equipo Scrum sigue siendo responsable del valor entregado, de analizar la evidencia y de mantener el profesionalismo.

La IA puede ser una herramienta de apoyo si se usa con buena intención. Debe evaluarse como cualquier otro factor que contribuya al flujo_psicológico (70) y al aprendizaje: ¿mejora los ciclos de retroalimentación? ¿Ayuda a validar supuestos más rápido? ¿Actúa de forma ética?

El flujo_psicológico (70) es un estado de concentración y disfrute profundo donde acción y percepción se fusionan.

Scrum anima al equipo a experimentar con IA de forma responsable mediante pruebas pequeñas y, en ocasiones, reversibles. La adaptación e inspección se aplican tanto al producto como a la integración de la IA en su entrega.

El foco debe seguir en la dinámica humana del trabajo en equipo, con la IA como apoyo.

Desarrollador

‘Desarrollador’ es un rol y una responsabilidad. Todos los desarrolladores juntos deben poseer las competencias necesarias para crear incrementos. Este conjunto de habilidades se considera multifuncional.

Un desarrollador puede ser humano o automatizado. Los desarrolladores humanos están comprometidos con crear, investigar, inspeccionar y adaptar cualquier aspecto de un incremento liberable, como tarde, cada Sprint. Su foco principal está en el Sprint actual, aunque pueden dedicar parte de su capacidad a la preparación futura, retroalimentación y aprendizaje.

Los desarrolladores se adhieren a la Definición de Hecho de Producto y buscan una mejora neta. Logran mejores resultados cuando se enfocan en un solo producto. Si en algún momento el Propietario del producto o el Scrum Master trabajan activamente en elementos del Sprint Backlog, lo hacen como desarrolladores.

Los desarrolladores deben adoptar comportamientos apropiados según la situación: colaborar, crear, defender la calidad técnica, descubrir, entregar y validar valor.

Al_menos_un_desarrollador_debe_ser_humano. Varios desarrolladores humanos mejoran la diversidad cognitiva, útil para abordar la complejidad.

Los desarrolladores son siempre colectivamente responsables de:

• Crear un plan emergente en el Sprint Backlog para alcanzar el objetivo del Sprint;
• Asegurar calidad cumpliendo y mejorando la Definición de Hecho de Producto;
• Crear al menos un incremento usable en cada Sprint;
• Aprender mediante los datos de la Definición de Hecho de Resultado;
• Adaptar el plan cada día en dirección al objetivo del Sprint;
• Rendir cuentas entre ellos como profesionales; y,
• Lograr una mejora neta.

El contexto importa, pero como regla general, un desarrollador que no esté dispuesto, preparado ni capacitado para actuar como profesional debería dejar de ser desarrollador.

Propietario del producto

“Propietario del producto” (Product Owner) es un rol y una responsabilidad. Debe ser una única persona. Para ser efectivo, debe liderar el producto. Maximiza el valor a largo plazo y necesita saber dónde está el valor y cuándo se necesita entregar. Se espera que trabaje en todos los niveles y áreas relevantes del negocio. Colabora con las personas implicadas, el Scrum Master y los desarrolladores para crear valor.

El Propietario del producto utiliza el Backlog de Producto para definir qué se construye y en qué orden aproximado. Siempre mantiene en mente el objetivo del producto; su foco principal es maximizar el valor a largo plazo en cada paso.

No suele analizar y escribir elementos detallados del Backlog de Producto. Cada minuto que no confía en los desarrolladores es una oportunidad perdida para pensar estratégicamente, colaborar con personas implicadas o generar más valor. El Propietario del producto debe adoptar comportamientos apropiados según el contexto, incluyendo, entre otros: ser visionario, representante del cliente, colaborador, influenciador, experimentador, decisor y promotor de la participación de personas implicadas, crear claridad, fomentar la calidad del producto y la realización de valor.

Siempre es responsable de:

• Implicación de personas implicadas, comprendiendo su poder, expectativas, necesidades y deseos;
• Percibir, escuchar, aprender y adaptarse continuamente;
• Equilibrar continuamente las decisiones, incluyendo:
  • La calidad, velocidad, capacidad, reducción de riesgos, valor y la simplicidad (149);
  • Las expectativas y limitaciones diversas de personas implicadas;
  • El valor, clima laboral y los potenciales clientes;
• Desarrollar y comunicar explícitamente el objetivo del producto;
• Comunicar una narrativa coherente del producto;
• Crear y comunicar claramente los elementos del Backlog de Producto;
• Ordenar los elementos del Backlog de Producto;
• Asegurar que el Backlog de Producto sea transparente y entendido;
• Comunicar resultados respaldados por métricas definidas en la Definición de Hecho de Resultado;
• Tener la última palabra sobre la Definición de Hecho de Resultado;
• Fomentar la alta calidad en la creación, descubrimiento, entrega y validación de valor; y
• Otras actividades de gestión de producto según se requiera.

Puede realizar directamente estas actividades o colaborar con el equipo Scrum para acordar quién las realiza. En cualquier caso, sigue siendo responsable.

Para que el Propietario del producto tenga éxito, todas las personas implicadas y los aliados deben respetar sus decisiones. Estas se reflejan en el contenido y orden del Backlog de Producto y en el incremento inspeccionable de la Revisión del Sprint. El Propietario del producto actúa con autoridad delegada de la organización.

El Propietario del producto necesita habilidades sólidas de gestión de producto y conocimiento del dominio. Si no las tiene, puede necesitar apoyo hasta desarrollarlas. El contexto importa. Pero como regla general, un Propietario del producto que no esté dispuesto, preparado ni capacitado para desarrollar estas habilidades debería dejar el rol. Un experto en la materia del dominio no es necesariamente la mejor opción, ya que se requieren habilidades de producto y liderazgo. A menudo, el rol de desarrollador es más adecuado para este perfil.

Si el equipo Scrum trabaja, aunque no se recomiende, en múltiples productos, plataformas o proyectos, cada responsable de ellos debe ser una parte interesada (y aliada) del Propietario del producto y colaborar para maximizar el valor a largo plazo. Scrum fomenta que el equipo esté enfocado y comprometido, y que evite convertirse en una “fábrica de funcionalidades”.

El Propietario del producto es una sola persona, no un comité ni una tecnología. Quien desee cambiar el Backlog de Producto debe convencerle. El Propietario del producto maximiza el valor a largo plazo y frecuentemente debe tomar decisiones complejas.

Scrum Master

“Scrum Master” es un rol y una responsabilidad. Debe ser una persona. Es un agente de cambio que trabaja a todos los niveles organizativos y en distintas áreas del negocio. Lidera con el ejemplo y guía la eficacia del Propietario del producto, el equipo Scrum, las personas implicadas y los aliados en la adopción de Scrum. Comprende la complejidad (30-35) y sabe facilitar “el siguiente paso correcto”.

El Scrum Master adopta distintos comportamientos según la situación: guía, coach, mentor, formador, observador, eliminador de impedimentos, facilitador del cambio, facilitador de eficacia y promotor de la mejora continua. No es un gestor de equipo, trabajo o seguimiento de la iniciativa. Tampoco es un dictador de normas, gestor de salas, administrador de informes, presidente, héroe, coordinador ni un Scrum Master ausente que delega todo en la autogestión.

Es responsable de la eficacia del equipo Scrum, las personas implicadas, los aliados y otras personas afectadas en la adopción del empirismo (67), la autogestión y Scrum según este documento. Aborda todo aquello que impida o ralentice el progreso del equipo Scrum y que éste no pueda resolver por sí mismo.

Apoya al equipo Scrum, al Propietario del producto y a los aliados de las siguientes formas:

• Ayudando a comprender la teoría y práctica de Scrum;
• Facilitando la mejora continua del equipo Scrum y de los aliados;
• Fomentando interacciones intencionales y oportunas;
• Asegurando que el equipo tenga una Definición de Hecho de Producto adecuada;
• Garantizando que todos los eventos Scrum se realicen, sean productivos y respeten los tiempos establecidos;
• Causando la eliminación de impedimentos del trabajo de producto y de la adopción efectiva de Scrum;
• Guiando hacia la autogestión (49) y la multifuncionalidad;
• Ayudando a comprender la importancia de entregar incrementos de alto valor que cumplan con la Definición de Hecho de Producto y de Resultado;
• Mejorando la adaptabilidad (80) y optimizando el flujo de valor;
• Fomentando confianza basada en la evidencia, evitando la sobreconfianza;
• Promoviendo que el equipo Scrum y los aliados sean agentes de cambio;
• Fomentando comportamientos alineados con los valores Scrum para generar confianza y alto rendimiento; y
• Fomentando la entrega frecuente de trabajo valioso, retroalimentación rápida y retrabajo si es necesario.

Apoya al equipo Scrum también en:

• Su formación, desarrollo y mejora continua;
• Comprender la necesidad de Backlog de Productos claros y orientados a valor;
• Asegurar que todo el equipo colabore de forma intencionada, cumple la Definición de Hecho y se enfoca en crear incrementos valiosos.

El Scrum Master apoya a las personas implicadas de diversas formas, incluyendo:

• Cuando se necesita más que solo experiencia, ayudando a las personas afectadas y a las personas implicadas a comprender y adoptar:
  • Un enfoque empírico para el trabajo complejo (30–35), donde causa y efecto solo se comprenden con perspectiva retrospectiva;
  • Prácticas que van más allá del control empírico del proceso, como ejecutar múltiples experimentos paralelos seguros al fallo, fomentar pensamiento innovador, aplicar la exaptación o probar intuiciones fundamentadas. Exaptación significa tomar algo creado o usado para un propósito y reutilizarlo para otro distinto, especialmente en contextos nuevos o inciertos.
• Fomentando acciones alineadas con el lema: “Deja de empezar cosas; empieza a terminarlas.”
• Facilitando la colaboración con personas implicadas, cuando sea necesario o se solicite;
• Ayudando a las personas implicadas a comprender la necesidad de tener elementos del Backlog de Producto claros y concisos que aporten valor; y
• Ayudando a las personas implicadas a mantener el foco principalmente en la realización de valor.

Apoya a las personas implicadas de diversas formas, incluyendo:

• Comprender y adoptar enfoques empíricos para el trabajo complejo (30-35);
• Explorar la experimentación paralela, el pensamiento innovador, exaptación y validación de hipótesis;
• Fomentar acciones que prioricen finalizar antes que empezar trabajo;
• Facilitar colaboración según se necesite;
• Comprender la necesidad de elementos del Backlog claros y valiosos;
• Enfocarse en la realización de valor.

Colabora con los aliados en:

• Liderar, formar y acompañar la adopción de Scrum;
• Aclarar qué obstaculiza dicha adopción;
• Facilitar el cambio emergente disciplinado;
• Fomentar un entorno centrado en la entrega (más que en la gestión).

Trabaja con la organización en:

• Liderar y acompañar la adopción de Scrum;
• Planificar e impulsar estas adopciones;
• Colaborar con otros departamentos en su alineación;
• Eliminar barreras para la adopción efectiva.

Puede colaborar con otros Scrum Masters o aliados, así como con otros agentes de cambio. Como responsable de la calidad de la adopción de Scrum, debe coordinarse con otros para mejorarla.

Es una sola persona, no un comité ni una tecnología. Sirve al Propietario del producto, al equipo Scrum, a las personas implicadas y a toda la organización. Como agente de cambio, suele invitar a participar en la transformación. Es útil que comprenda el flujo de valor (68, 69), el pensamiento lean (63), la teoría de la complejidad (30-35) y otras teorías complementarias, además de saber ayudar en el “cómo”. También debe tener persistencia y pasión por el aprendizaje y el cambio.

Ser Scrum Master es una vocación donde ayudar a los demás es la recompensa. No busca protagonismo. Como buen líder, da el crédito y asume la responsabilidad. Permanecer más tiempo en el rol ayuda a guiar al equipo hacia su potencial, siempre que los desarrolladores adopten la autogestión. Un Scrum Master con actitud paternalista no favorece la autogestión. El contexto importa. Pero como norma general, si un Scrum Master no está dispuesto, preparado ni capacitado para ser agente de cambio, debería dejar el rol.

Artefactos de Scrum en el Paquete de expansión

Los artefactos de Scrum aportan transparencia sobre lo que el equipo Scrum y las personas implicadas creen que generará valor. Así, todos comparten una base común para la inspección y adaptación.

Cada artefacto tiene un compromiso asociado:

• Para el producto que sirve a las personas implicadas, es la Definición de Hecho de Resultado.
• Para el incremento que es una posible actualización del producto, es la Definición de Hecho de Producto.
• Para el Backlog de Producto, es el Objetivo del Producto.
• Para el Sprint Backlog, es el Objetivo del Sprint.

Cuando se libera un incremento (producto), es el producto quien genera valor (resultados). El valor es el cumplimiento o creación medible u observable de las expectativas, necesidades o deseos desde la perspectiva de las personas implicadas.

Estos compromisos refuerzan los pilares de transparencia, inspección y adaptación, habilitando el control empírico del proceso (64–66). El objetivo del producto se mantiene mientras no surjan evidencias u observaciones que lo contradigan dentro de la Definición de Hecho de Resultado del producto observado. El producto entregado mantiene la Definición de Hecho de Producto durante el Sprint. Entonces, ¿qué podría cambiar si no hay suficiente capacidad durante del Sprint? Podrían ajustarse los criterios de aceptación de un elemento concreto del Backlog de Producto, la implementación o nivel de fidelidad de una funcionalidad, o incluso sustituirse por otros elementos del Backlog de Producto que contribuyan al objetivo del Sprint.

Si el objetivo del producto cambia con frecuencia, podría ser una señal de falta de foco en lo importante. Foco también significa decidir qué no hacer.

Producto

El producto es un artefacto. Puede ser una experiencia completa o una plataforma. También puede ser un servicio, físico, digital o híbrido, que entrega valor continuo a personas implicadas (usuarios incluidos, pero no exclusivamente).

Una experiencia es una solución diseñada para responder a las necesidades de personas implicadas, especialmente usuarios externos. Proporciona una interacción directa que aporta valor, y suele centrarse en resolver problemas u oportunidades concretas para los clientes, responsables de decisión y usuarios.

Una plataforma es una infraestructura o conjunto de herramientas sobre la que se pueden construir productos que ofrecen experiencias. Está pensada para desarrolladores, enfocándose en la escalabilidad, fiabilidad y flexibilidad, más que en la interacción directa con el usuario.

El equipo Scrum y las personas implicadas deben tener siempre claro qué es el producto, quiénes son sus clientes, usuarios o responsables de decisión, y de qué tipo de producto se trata (p.e., para usuarios finales, empleados o equipos Scrum) ya que eso afecta a qué personas implicadas involucra y cómo genera valor. El producto es evolutivo y a menudo tiene una vida larga. Debe tener un único Backlog de Producto para aumentar la transparencia y maximizar el valor.

El contexto importa. Pero como regla general, para que un producto gane y mantenga tracción, conviene que:

• Aborde adecuadamente las brechas de satisfacción;
• Sea valioso, deseable, viable, usable, factible, seguro y confiable;
• Tenga profesionalismo incorporado;
• Cuente con una visión del producto clara, orientada a resultados y con una estrategia y objetivo coherentes, incluyendo su propósito, razones y anti-objetivos;
• Se adapte y mejore para identificar, representar o medir la información y decisiones emergentes (71); y
• Sea extensible y mantenible.

El producto es la manifestación del por_qué hacemos lo_que hacemos.

Compromiso: Definición de Hecho de Resultado

La Definición de Hecho de Resultado es un compromiso. Describe las evidencias observables (cuantitativas o cualitativas) necesarias para demostrar beneficios obtenidos, lo que se conoce como validación de valor. Puede aplicarse al producto completo o a un objetivo específico. Es recomendable definir las métricas antes de comenzar, para evitar sesgos o malinterpretaciones.

Los resultados y su interpretación orientan futuras adaptaciones, idealmente confirmando el impacto previsto en las personas implicadas, ya sean usuarios o negocio, y midiendo si la salida cumplió con los resultados esperados y generó valor real. Puede validarse a nivel de funcionalidad o de producto completo, usando telemetría del producto o midiendo impacto estratégico y eficacia de la estrategia implementada (120–124).

Es preferible usar una evidencia directa frente a una evidencia circunstancial. Por ejemplo:

• Resultados de clientes: aumento de satisfacción, reducción de costes, número de trabajos resueltos.
• Resultados de usuarios: cambio de comportamiento, eficiencia, uso de nuevas funcionalidades.
• Resultados del producto: métricas agregadas como tiempo de entrega, aprendizaje, adaptación.
• Resultados de negocio: cumplimiento, costes, cuota de mercado, satisfacción general, agilidad organizativa.
• Resultados del equipo Scrum: capacidades técnicas, frecuencia de entrega, herramientas, deuda técnica o de experiencia (UX/CX), clima para innovación.

La deuda_de_experiencia_de_usuario_o_cliente es la suma de decisiones que hacen un producto menos usable, agradable o efectivo. Reconocerla, darle seguimiento y reducirla es clave para satisfacer necesidades reales.

Las métricas observadas a lo largo del tiempo permiten ver tendencias del producto, el mercado y las personas implicadas (clientes o usuarios incluidos); pueden revisarse en cualquier momento del Sprint, especialmente en la revisión del Sprint.

Incremento

El incremento es un artefacto. Es la integración del trabajo completado según la Definición de Hecho de Producto. Es una salida y una posible entrega del producto.

Durante el Sprint se pueden crear varios incrementos. Cada uno debe estar verificado, usable e integrado con los anteriores. El incremento final se inspecciona lo antes posible, como máximo en la revisión del Sprint. Debe ser útil y usable para permitir la retroalimentación. Es clave en Scrum porque permite validar el valor de forma continua.

Un candidato a incremento no se considera incremento hasta que cumple con la Definición de Hecho de Producto. Solo un incremento puede ser liberado. Debe ser un paso concreto hacia el objetivo del producto. Puede liberarse antes de la revisión del Sprint. La_mejor_validación_del_valor_se_logra_mediante_retroalimentación_de_resultados.

Compromiso: Definición de Hecho de Producto

La Definición de Hecho de Producto es un compromiso. Describe formalmente los criterios de calidad que garantizan que un incremento podría ser entregado a personas implicadas.

Suele incluir estándares técnicos y cualidades del producto. El equipo Scrum la crea si ésta no existe en la organización. Si hay múltiples equipos Scrum trabajando en el mismo producto, deben compartir la misma Definición de Hecho de Producto como base común, aunque pueden mejorarla internamente.

El equipo Scrum está obligado a cumplirla y mejorarla. El incremento es acumulativo. La Definición de Hecho de Producto aplica a todo el incremento, no a cada ítem individual (como los criterios de aceptación).

Un incremento liberado permite obtener retroalimentación para validar el valor según la Definición de Hecho de Resultado.

Backlog de Producto

El Backlog de Producto es un artefacto. Es la lista emergente y ordenada de elementos necesarios para alcanzar el objetivo del producto. Proporciona transparencia (claridad sobre el trabajo) y es la única fuente de trabajo del equipo Scrum para ese fin. El Propietario del producto ordena los elementos del backlog guiado por el valor. Un Backlog de Producto más pequeño a menudo es más transparente.

Elemento del Backlog de Producto

Un elemento del Backlog de Producto es una pieza de trabajo potencialmente valiosa. No tiene un formato fijo. Sirve para abordar un problema u oportunidad. Puede incluir criterios de aceptación que indiquen cuándo está completado, además cumplir de la Definición de Hecho de Producto. También puede tener criterios de resultado para saber si genera suficiente valor, además de lo incluido en la Definición de Hecho de Resultado.

Es una unidad de trabajo que descubre o entrega valor. Puede evolucionar en cualquier momento, incluso mientras se trabaja en él. En el refinamiento, se descompone en partes más pequeñas, comprensibles principalmente para el equipo Scrum. Si hay muchos elementos no alineados con el objetivo del producto, podría ser síntoma de falta de foco. El equipo Scrum y las personas implicadas deben priorizar resultados sobre entregables, equilibrar las decisiones, y evitar convertirse en una “fábrica de funcionalidades” o de “descubrimientos”.

Criterios de aceptación

Los criterios de aceptación, si existen, describen cuándo una salida está completa para un elemento del Backlog de Producto, además de satisfacer la Definición de Hecho de Producto. Deben proporcionar claridad inequívoca sobre qué se solicita. Incluyen criterios específicos no contemplados en la Definición general, y pueden ser funcionales o no funcionales. Pueden evolucionar en cualquier momento.

Criterios de resultado

Los criterios de resultado, si existen, describen la intención del elemento del Backlog de Producto; es el por _qué detrás del qué. Su cumplimiento complementa la Definición de Hecho de Resultado. Pueden incluir criterios específicos no cubiertos por la definición general. Si surgen dudas, los criterios de resultado orientan la decisión. Pueden tomar forma de narrativas o métricas, preferentemente lo segundo. También pueden evolucionar en cualquier momento.

##############

Refinamiento

El refinamiento es una actividad. Puede ser formal (un evento adicional) o informal. Es un proceso emergente y continuo que favorece la claridad y reduce el riesgo; genera suficiente entendimiento y confianza para que los elementos seleccionados o próximos del Backlog de Producto estén listos (puedan completarse de acuerdo con la Definición de Hecho de Producto en unos pocos días o menos). El refinamiento tiene en cuenta los diversos tipos de dependencias.

El refinamiento implica descomponer elementos del Backlog de Producto en partes más pequeñas y comprensibles (principalmente para el equipo Scrum). Puede añadir detalles como descripción, criterios de aceptación, criterios de resultado, orden y tamaño. Los atributos pueden variar, pero deben ser significativos para el equipo Scrum. Puede incluir investigación, como validación de problemas u oportunidades, experiencia de usuario o cliente y validación de soluciones. Los desarrolladores, y nadie más, son responsables de estimar el tamaño de los elementos del Backlog de Producto. El Propietario del producto puede influirles ayudándoles a entender y elegir posibles alternativas.

Los participantes suelen incluir personas implicadas y miembros del equipo Scrum; no es raro que los desarrolladores trabajen directamente con personas implicadas. El refinamiento suele estar facilitado o respaldado por el Propietario del producto. El Propietario del producto puede enfocarse más en la responsabilidad de producto si los desarrolladores comprenden bien el producto. En general, es una actividad orientada al futuro que aporta claridad, dirección y posible _foco para los próximos Sprints.

Compromiso: Objetivo del Producto

El objetivo del producto es un compromiso. Se representa mediante el Backlog de Producto, que es responsabilidad del Propietario del producto. Es el objetivo actual único, más estratégico y ambicioso (el por_qué). Da dirección al producto y permite el foco de los desarrolladores que trabajan en él. Mejora la transparencia al proporcionar una dirección clara y valiosa hacia la que avanzar, usando como medio el objetivo del Sprint (el por_qué del Sprint).

El objetivo del producto es un objetivo de medio plazo para el equipo Scrum y las personas implicadas (y quienes los apoyan). El equipo Scrum debería cumplir (o abandonar) un objetivo del producto antes de asumir el siguiente.

Normalmente, el objetivo del producto es una afirmación aún no validada sobre el valor. Puede expresarse de muchas formas, incluyendo un conjunto de hipótesis sobre cómo cerrar o reducir brechas de satisfacción. Busca el equilibrio enfocándose en un subconjunto de expectativas y límites de las múltiples personas implicadas (clientes o usuarios incluidos, pero no exclusivamente). Para alcanzar el objetivo de producto, es fundamental usar la inspección y adaptación, abrazar la incertidumbre (72), la retroalimentación de resultados, los efectos secundarios y otros aprendizajes.

¿Y qué pasa con una visión de producto?

Muchas organizaciones trabajan con una visión de producto, que ayuda a imaginar un posible futuro. El equipo Scrum puede usar esta visión como una pista para elegir el objetivo del producto. Una visión de producto es un conjunto valioso de resultados deseados a largo plazo. El objetivo de producto suele ser un peldaño intermedio hacia esa visión.

A medida que el equipo Scrum y las personas implicadas inspeccionan y se adaptan al objetivo del producto, deben estar abiertos a la posibilidad de que tanto la visión como el objetivo necesiten cambiar. A menudo, se alcanzan varios objetivos de producto secuencialmente mientras se avanza hacia la visión.

Lo importante es que una visión de producto es, a menudo, una ficción; puede que nada de ella sea real. Formular hipótesis y hacer experimentos en una dirección es esencial, y ahí es donde Scrum aporta más valor.

Una visión de producto puede ser inspiradora pero abrumadora. El objetivo del producto es reducir esa sensación al actuar como una parte más tangible de la visión o como su habilitador.

Sprint Backlog

El Sprint Backlog es un artefacto. Está compuesto por el objetivo del Sprint (el por_qué), el conjunto de elementos del Backlog de Producto seleccionados (el qué, también conocido como pronóstico) y, a menudo, un plan accionable para entregar el incremento (el cómo). Aporta transparencia (claridad del trabajo) durante todo el Sprint.

Es un plan creado por y para los desarrolladores. Representa su punto de vista sobre el trabajo necesario para alcanzar el objetivo del Sprint. Si se diera un escenario subóptimo donde la mayoría de elementos no se relacionan con el objetivo del producto, los valores de foco y compromiso no estarían presentes.

Dentro del contexto del objetivo del Sprint, los desarrolladores actualizan su plan, incluso el pronóstico, a medida que aprenden durante el Sprint. El Sprint Backlog debe tener suficiente trabajo para empezar, por ejemplo, uno o dos elementos hacia el objetivo del Sprint. Los desarrolladores inspeccionan su progreso en el Daily Scrum o más a menudo. Aprenden a adaptarse y responder ante la incertidumbre (72).

Compromiso: Objetivo del Sprint

El objetivo del Sprint es un compromiso creado y propiedad del equipo Scrum. Es el objetivo unificador del Sprint (el por_qué) para los desarrolladores, creado en la planificación del Sprint. Su entrega es un compromiso por parte de los desarrolladores. El Sprint Backlog (incluyendo el por_qué, el qué y, a menudo, el cómo) ofrece foco y flexibilidad respecto al trabajo en evolución, mejorando así la transparencia.

El objetivo del Sprint anima al equipo Scrum a trabajar de forma conjunta en lugar de iniciativas separadas. Si el trabajo resulta diferente a lo esperado, los desarrolladores colaboran con el Propietario del producto para explorar posibilidades sin afectar al objetivo. Nadie les dice cómo estimar o ejecutar su trabajo.

Eventos de Scrum en el Paquete de expansión

Scrum combina cuatro eventos acotados en el tiempo para la inspección y adaptación, contenidos dentro de un quinto evento de duración determinada: el Sprint. Estos eventos apoyan los pilares de Scrum: transparencia, inspección y adaptación. Las entregas permiten generar valor, idealmente de forma continua. Las entregas poco frecuentes retrasan la retroalimentación de resultados.

Un “tiempo limitado” es una cantidad máxima estipulada de tiempo transcurrido desde el inicio hasta el final de un evento definido, que no debe confundirse con la expectativa de usar todo ese tiempo. El propósito de un tiempo limitado en Scrum es fomentar la selección del trabajo esencial, generando foco para alcanzar resultados deseados rápidamente. En Scrum, para un equipo determinado, la duración del Sprint es constante, por lo tanto, no es un tiempo limitado.

Los eventos crean cadencia y minimizan la necesidad de otras reuniones fuera de Scrum. Idealmente, cada evento se celebra en el mismo horario y lugar para reducir la complejidad (30–35) y fomentar la creación de hábitos. Una facilitación hábil mejora su efectividad. Los eventos ineficaces corren el riesgo de perder el foco en el objetivo del Sprint, el objetivo del producto, la transparencia, la inspección, la adaptación y los valores de Scrum.

Cada evento tiene un propósito propio y debe incluir trabajo profundo y significativo. En conjunto, los eventos de Scrum proporcionan una estructura para inspeccionar y adaptarse, hacer pausas y reflexionar. Apoyan el pensamiento y el trabajo estructurado, la efectividad y una carga de trabajo equilibrada.

La comunicación es clave para asegurar que el equipo Scrum y quienes los apoyan se enfoquen en lo importante. Salvo el Sprint, los eventos pueden durar menos tiempo siempre que no se pierda coherencia.

El Sprint

El Sprint es un evento en el que las ideas se transforman en valor. Es el evento contenedor. Es una iteración de duración determinada en la que se realiza el trabajo. Proporciona foco y estabilidad. Un Sprint no dura más de cuatro semanas. Uno nuevo comienza inmediatamente después de que finalice el anterior. Todo el trabajo necesario para alcanzar el objetivo del producto ocurre dentro de los Sprints.

Los Sprints son el latido de Scrum, donde el equipo convierte las ideas en incrementos utilizables, útiles y potencialmente valiosos. El incremento se libera tan pronto como sea prácticamente posible, considerando el beneficio de una retroalimentación temprana. No liberar a ciertos grupos de personas implicadas (clientes reales, decisores, usuarios, etc.) puede limitar la calidad de la retroalimentación. En un Sprint pueden crearse múltiples incrementos; el equipo debe esforzarse por validar el valor mediante entregas tempranas y frecuentes, cuando sea posible.

Durante el Sprint:

• No se realizan cambios que pongan en riesgo el objetivo del Sprint.
• El o los incrementos no deben perder calidad.
• El Backlog de Producto se refina según sea necesario.
• A medida que se aprende más, el trabajo actual puede aclararse y renegociarse con el Propietario del producto, sin afectar al objetivo del Sprint.

Los Sprints permiten generar resultados al garantizar la inspección y adaptación del progreso hacia el objetivo del Sprint al menos cada cuatro semanas. Cuando un Sprint es demasiado largo, su objetivo puede quedar obsoleto, lo que incrementa la complejidad (30–35) y el riesgo. Los Sprints más cortos suelen generar más ciclos de aprendizaje y pueden reducir el riesgo.

Los Sprints más cortos suelen requerir mejores capacidades (por ejemplo, refinamiento, corte vertical, dominio técnico o de negocio). El contexto importa y el equipo Scrum busca el equilibrio adecuado.

Existen prácticas complementarias para evaluar o prever el progreso, como burndowns, burn-ups, análisis de flujo, pronósticos probabilísticos Monte Carlo, estimaciones de gran esfuerzo, conjuntos difusos (110), etc. Aunque sean útiles, no reemplazan la importancia del empirismo (67). En entornos complejos (30–35), lo que ya ha ocurrido puede usarse para tomar decisiones futuras, pero lo que ocurrirá es desconocido.

Se puede considerar un Sprint como un mini proyecto con un resultado claro, duración determinada y costes conocidos. Sin embargo, las actividades se desarrollan en paralelo y no de forma secuencial y lineal.

Un Sprint puede cancelarse si su objetivo queda obsoleto. Solo el Propietario del producto tiene autoridad para cancelarlo. Los Sprints más cortos reducen esta posibilidad.

Planificación del Sprint

La planificación del Sprint es un evento. Es el primer evento del Sprint, donde el equipo Scrum aporta foco y crea compromiso.

Durante este evento, se considera el objetivo del producto (el por_qué del Backlog de Producto) como guía. A partir de él, los desarrolladores crean el Sprint Backlog, que incluye el objetivo del Sprint (el por_qué del Sprint), el trabajo inicialmente identificado y el plan para entregarlo.

La planificación del Sprint aborda los siguientes temas:

El por qué del Sprint

El Propietario del producto propone ideas para incrementar el valor y utilidad del producto durante el Sprint. Luego, el equipo colabora para definir un objetivo del Sprint que comunique por qué ese Sprint es valioso para las personas implicadas en relación con el objetivo del producto. Este objetivo debe quedar definido al final de la planificación.

El qué hacia el por qué

En colaboración con el Propietario del producto, los desarrolladores seleccionan elementos del Backlog de Producto para incluir en el Sprint actual. El equipo puede refinar estos elementos, aumentando así la comprensión y la confianza. Los elementos seleccionados deben ser alcanzables según la Definición de Hecho de Producto, junto con los demás.

Determinar cuánto trabajo se puede completar puede ser difícil. Pero cuanto más sepan los desarrolladores sobre su rendimiento pasado, el corte vertical, la capacidad próxima y la Definición de Hecho de Producto, mayor confianza tendrán en su pronóstico.

Los equipos Scrum exitosos no se sobrecargan. De hecho, planifican para terminar temprano, a veces dejando margen para imprevistos (85). Esto les ayuda a mantener el foco, mejorar la calidad y satisfacer a las personas implicadas al entregar valor antes. La sobrecarga crónica o los cambios repentinos pueden causar estrés excesivo, lo que Jeff Sutherland llama “sorpresa bayesiana”. Esto puede alterar el flujo psicológico (70) y el rendimiento del equipo. Una comunicación clara, el manejo profesional de la información y decisiones emergentes (71) y pequeños cambios regulares ayudan a prevenirlo. Los equipos deberían apuntar a entregas tempranas.

El cómo para el qué

El cómo se hace el trabajo depende exclusivamente de los desarrolladores. Nadie más les dice cómo hacerlo. Ellos seleccionan su propio trabajo; nadie, ni siquiera el Propietario del producto, les asigna ni les impone elementos del Backlog de Producto.

La planificación del Sprint tiene un tiempo limitado máximo de ocho horas para un Sprint de cuatro semanas. El evento suele ser más corto si el Sprint es más corto. El contexto importa. Pero como regla general, basta con planificar lo necesario para empezar, por ejemplo, unos pocos elementos del Backlog de Producto orientados al objetivo del Sprint.

Daily Scrum

El Daily Scrum es un evento. En él, los desarrolladores colaboran para revisar el progreso hacia el objetivo del Sprint y actualizan el plan de acción, el Sprint Backlog, hasta el siguiente Daily Scrum. Si ya se ha alcanzado el objetivo del Sprint, los desarrolladores colaboran para avanzar significativamente hacia el objetivo del producto.

El Daily Scrum proporciona foco, cohesión y sentido de urgencia, y fomenta la autogestión (49). Normalmente, solo participan los desarrolladores. Para simplificar, suele celebrarse con la misma cadencia, en el mismo lugar y a la misma hora.

Los desarrolladores pueden elegir la estructura y las técnicas que deseen. El Daily Scrum mejora la comunicación orientada a alcanzar el objetivo del Sprint, ayuda a identificar y abordar riesgos e impedimentos, favorece la toma rápida de decisiones y, como consecuencia, elimina la necesidad de otras reuniones.

El Daily Scrum no es el único momento en que los desarrolladores ajustan su plan para el Sprint en el contexto del objetivo del Sprint o del objetivo del producto. Es común que se reúnan durante el día para tratar cuestiones con más detalle.

Para facilitar el flujo de valor (68,69) y posibilitar resultados antes, los desarrolladores deberían concentrarse en un solo elemento o en pocos a la vez, y alcanzar la Definición de Hecho de Producto antes de empezar nuevos elementos. Pueden lograrlo manteniendo el foco, reduciendo el trabajo en curso y terminando el trabajo de forma proactiva antes de iniciar un nuevo trabajo. Supervisan el trabajo que está parado, no a las personas que lo están.

El Daily Scrum tiene un timebox máximo de quince minutos diarios; puede ser más breve.

Revisión del Sprint

La revisión del Sprint es un evento. Es una sesión interactiva y colaborativa. A menudo, el equipo Scrum comparte el objetivo actual del producto y presenta la Definición de Hecho de Producto y la Definición de Hecho de Resultado a las personas implicadas. El equipo comparte los resultados obtenidos, las decisiones de compromiso realizadas y el progreso hacia el objetivo del producto (el porqué del trabajo). Si están disponibles, también se comparten y consideran las métricas actuales y actualizadas relativas a la Definición de Hecho de Resultado.

Durante la revisión del Sprint se inspeccionan muchos aspectos relacionados con el producto, como el objetivo del producto, el Product Backlog, el objetivo del Sprint, los aprendizajes, el incremento, las expectativas y los límites de los interesados, la retroalimentación de resultados, los efectos secundarios, el progreso con el producto, el mercado y también aspectos futuros, como ideas y oportunidades emergentes, así como próximos pasos posibles.

A partir de lo aprendido:

• Las personas participantes perciben, escuchan, aprenden y colaboran para decidir qué hacer a continuación;
• Se adapta el Product Backlog (el qué), y posiblemente el objetivo del producto, preferentemente respaldados por evidencia u observaciones, y guiados por el objetivo del producto u opcionalmente por una visión;
• Se adapta la Definición de Hecho de Resultado del producto para Sprints futuros.

Siempre es importante tener en cuenta a las personas implicadas y lo que valoran, incluyendo a las entidades no humanas como la legislación.

Los elementos del Product Backlog incompletos se devuelven al Backlog para ser considerados más adelante y no se presentan; en ocasiones, se trasladan al siguiente Sprint.

La revisión del Sprint es el penúltimo evento del Sprint y tiene un timebox máximo de cuatro horas para un Sprint de cuatro semanas. Para Sprints más cortos, suele ser más breve.

Retrospectiva del Sprint

La retrospectiva del Sprint es un evento. En él, el equipo Scrum acuerda cómo mejorar. También se analizan suposiciones erróneas, es decir, aquellas que llevaron al equipo en una dirección equivocada. Se pueden destacar o reforzar aspectos positivos como ciertas tecnologías, procesos, patrones, etc. Los elementos inspeccionados varían según el dominio del trabajo. La reflexión es más efectiva en un entorno de seguridad psicológica.

La retrospectiva del Sprint se enfoca en los cambios más útiles para mejorar, tales como:

• El incremento
• Los resultados
• El profesionalismo, por ejemplo, las habilidades, prácticas técnicas, herramientas o la capacidad de innovación;
• El flujo de valor validado (68,69), como métricas de flujo de extremo a extremo, tiempo de llegada al mercado;
• La efectividad (el cómo), como la tecnología, procesos o dependencias;
• Las interacciones y dinámicas del equipo Scrum, como la colaboración o los acuerdos de trabajo;
• Los indicadores visuales de información, como muros de producto o métricas;
• La Definición de Hecho de Producto para futuros Sprints;
• Adaptaciones adicionales a la Definición de Hecho de Resultado para futuros Sprints;
• Cómo alcanzar automáticamente las métricas relacionadas con la Definición de Hecho de Resultado;
• Y más.

Las mejoras con mayor impacto deben abordarse lo antes posible. El equipo Scrum no debe limitarse a hablar de mejora; Scrum depende de un seguimiento significativo y continuo de las mejoras. Algunas acciones de mejora requieren ayuda por parte de quienes apoyan al equipo, pero eso no significa que el equipo no deba esforzarse por lograr una mejora neta de todas formas (como ganancias marginales continuas).

La retrospectiva concluye el Sprint. Tiene un tiempo limitado máximo de tres horas para un Sprint de cuatro semanas. Para Sprints más cortos, suele durar menos.

Productos con múltiples Equipos Scrum

Si un equipo Scrum se vuelve demasiado grande, debería considerar reorganizarse en varios equipos Scrum cohesionados, cada uno centrado en el mismo producto. Cuando hay múltiples equipos Scrum trabajando sobre el mismo producto, deben compartir el mismo objetivo de producto, Product Backlog, Propietario del producto, así como la Definición de Hecho de Resultado y la Definición de Hecho de Producto de referencia.

Se debe tener cuidado con asumir ciegamente que más equipos Scrum producen más valor. Escala sólo cuando los beneficios superen claramente la sobrecarga de trabajo adicional. Antes de escalar, un único equipo Scrum debe ser capaz de producir de forma fiable un incremento en cada Sprint. Pero, si se necesita escalar, se debe utilizar un enfoque coherente con este documento. A menudo, menos equipos generan más resultados.

En un contexto con varios equipos Scrum, estos pueden reducir las dependencias entre ellos haciéndose más multifuncionales mediante la colaboración, la polinización cruzada, la transferencia de aprendizajes y las interacciones intencionales. Las habilidades necesarias son a menudo amplias y varían según el dominio del trabajo. En un entorno con múltiples equipos, las interacciones deliberadas y el profesionalismo (incluida la integración continua) se vuelven aún más importantes.

En una configuración con un único Propietario del producto y un único equipo Scrum, el Propietario del producto puede ser un Product Manager, director de marketing, director de tecnología, etc. En una configuración con múltiples equipos Scrum para un mismo producto, lo ideal sigue siendo tener un solo Propietario del producto, que debe ejercer un rol de liderazgo sobre el producto. Para poder gestionar múltiples equipos Scrum, este Propietario del producto suele asumir un enfoque más estratégico y delega en los desarrolladores problemas por resolver y oportunidades, incluyendo, por ejemplo, aspectos de diseño o gestión del producto.

El Product Backlog es una herramienta para aumentar la transparencia.

En general, cuantos menos Product Backlogs tenga un producto (ya sean implícitos, como filtros, o explícitos):

• Menos silos habrá en el producto y mayor será la transparencia general;
• Mayor será la claridad del seguimiento del progreso a nivel de producto;
• Mejor será la visión general sobre el valor generado;
• Será más probable que un equipo Scrum detecte que está trabajando en ítems de bajo valor;
• Aumentará la probabilidad de observar mejoras en la consecución de valor;
• Y el Propietario del producto podrá asumir un rol más estratégico al delegar el trabajo transversal en los desarrolladores.

Tener menos Product Backlogs por producto favorece la adaptabilidad (80), pero si no hay propiedad empoderada, un ámbito de control coherente o contacto directo con las personas implicadas relevantes, surgirán vacíos. Scrum fomenta un entorno propicio para los hallazgos fortuitos y el aprendizaje múltiple: al colaborar equipos y personas, se pueden compartir y aprovechar descubrimientos e ideas. Esto es poco probable en un entorno donde cada componente tiene un Product Backlog aislado.

“Hallazgo fortuito” (happenstance), según “The New New Product Development Game” (29), se refiere a que a veces surgen ideas útiles por casualidad, no por planificación deliberada. Cuando los equipos Scrum colaboran estrechamente y comparten información, pueden descubrir nuevas soluciones simplemente por estar abiertos a eventos inesperados o descubrimientos accidentales.

“Aprendizaje múltiple” (multi-learning) significa que los miembros del equipo aprenden simultáneamente de muchas formas distintas. Adquieren conocimientos y habilidades tanto en su propio ámbito como en otros, aprendiendo como individuos, como grupo y como parte de la organización. Esto hace que el equipo sea más flexible y capaz de resolver problemas diversos con agilidad, ya que todos aprenden unos de otros y de su experiencia compartida.

Encontrar el equilibrio adecuado es un dilema. Siempre hay decisiones de compromiso que considerar. Sin embargo, una buena heurística es: cuantos menos Product Backlogs (explícitos o implícitos), mejor, habilitado a través del aprendizaje múltiple y de la transferencia organizativa del aprendizaje entre equipos Scrum, departamentos y productos.

La transferencia organizativa del aprendizaje, según “The New New Product Development Game” (29), es el proceso por el cual los conocimientos e ideas generados en el desarrollo de un nuevo producto se comparten y aplican en otras áreas o divisiones de la organización.

Las organizaciones suelen estar diseñadas para facilitar la gestión más que para facilitar la entrega de resultados. Hay que preguntarse cuántos equipos Scrum se ven implicados para que un problema u oportunidad genere valor; por lo general, cuanto menor sea ese número, mejor.

Libera a los equipos del control jerárquico. Inclínate por una autonomía alineada. Fomenta interacciones intencionales dentro y entre equipos Scrum autogestionados (49). Promueve un entorno laboral con procesos de gestión mínimos pero suficientes, estructuras de apoyo y límites claros. Equilibra y cuida las expectativas y límites de los Stakeholders. Integra el rol de agentes del cambio y la mejora continua en una dirección, no solo la entrega, dentro del ritmo de trabajo.

Cuando tengas dudas, estudia “The New New Product Development Game” (29), abraza lo positivo de lo nuevo en el presente y deja atrás cualquier idea de un complejo industrial (30–35) donde solo las personas valientes tienen el poder de actuar.

Nota final

La adopción de Scrum por parte de Jeff Sutherland en Easel en 1993 se inspiró en los trabajos de Christopher Langton (36, 37) sobre la teoría de los Sistemas Complejos Adaptativos (CAS) (74–77) del Laboratorio de Los Álamos, que muestran que los sistemas evolucionan más rápidamente en el borde del caos.

Scrum está descrito en la Guía de Scrum 2020 (40). A Simple Guide to Scrum de Tobias Mayer es una versión abreviada y editada de la Guía oficial de Scrum de Ken Schwaber y Jeff Sutherland. El Scrum Hexis (52) amplía la Guía de Scrum 2020 desde una perspectiva de 2025, aunque esta sigue siendo la referencia esencial sobre Scrum.

Scrum es como un espejo. Si la imagen reflejada no es la esperada, ¿deberíamos ocultar el espejo?

Conviene alcanzar al menos un incremento en cada Sprint como hábito antes de adaptar Scrum. Cada parte de Scrum tiene un propósito; entender el por qué de cada una es esencial. Considera el contexto. El corto plazo trata de la entrega. El largo plazo, del cambio emergente exitoso en una dirección y de la entrega sostenible de valor. El éxito en la adopción de Scrum depende de encontrar el equilibrio adecuado entre el corto y el largo plazo.

Hay que tener cuidado con copiar enfoques de otras organizaciones sin fomentar también su cultura. El cambio emergente en una dirección es el propio cambio. Este incluye (pero no se limita a) liderazgo, flujos de trabajo, procesos y sistemas, incluyendo RR. HH., Finanzas, Compras, y más. Scrum forma parte de una expedición sin fin hacia la mejora continua y la evolución en una dirección de viaje, más que hacia un destino.

Agradecimientos

Scrum se inspiró en Lean (63), el Sistema de Producción de Toyota (59–60), el artículo de Harvard Business Review The_New_New_Product_Development_Game de Hirotaka Takeuchi e Ikujiro Nonaka (29), y en el empirismo aplicado en Dupont (61).

Scrum fue desarrollado a principios de los años 90. Ken Schwaber y Jeff Sutherland lo presentaron juntos por primera vez en la conferencia OOPSLA en 1995 (62). La primera versión de la Guía de Scrum (40) apareció en 2009. Scrum sigue evolucionando.

También agradecemos a quienes ofrecieron comentarios en versiones anteriores del documento, incluyendo, entre otros, a Daryn Basson, Alex Benes, Kurt Bittner, Deb Bhattacharya, Magdalena Firlit, Nichervan Fazel, Peter Fischbach, Michael Forni, Tom Gilb, Martin Hinshelwood, Jesse Houwing, Michael Huynh, Matthew Ijogi, Marc Kaufmann, Tom Mellor, Christian Neverdal, Stas Pavlov, Ian Sharp, Alisa Stolze, Mark Summers y Nader Talai.

Scrum Expandido en una sola página

Scrum está descrito en la Guía de Scrum 2020 (40). Es un marco ligero para abordar trabajo complejo (30–35), especialmente en descubrimiento, desarrollo, entrega y validación de valor de productos. Scrum se basa en el control empírico de procesos (decisiones basadas en evidencia) y el pensamiento Lean (reducción de desperdicios y enfoque en el flujo de valor) (63). Scrum es intencionalmente incompleto: guía interacciones más que prescribir recetas detalladas.

¿Por qué usar Scrum? Scrum permite que los equipos identifiquen, representen o midan la información y decisiones emergentes (71), abracen la incertidumbre, respondan al cambio, entreguen y validen valor frecuentemente y mejoren continuamente. Scrum fomenta la colaboración, la responsabilidad compartida y la toma de decisiones basadas en evidencia, propiciando los mejores resultados posibles en entornos cambiantes. Los equipos autoorganizados centrados en valor son clave para resolver problemas creativos y aprovechar oportunidades; los equipos que no se autogestionan dificultan la capacidad de afrontar la complejidad (30–35). La autogestión del equipo Scrum no debe confundirse con la autogestión individual.

Elementos de Scrum

1. Teoría de Scrum: Se basa en tres pilares:

• Transparencia – Hacer visible el trabajo y el valor para facilitar la inspección.
• Inspección – Evaluar regularmente el progreso y los resultados para adaptarse.
• Adaptación – Ajustar los planes basándose en ideas y retroalimentación.

2. Valores de Scrum: Foco, apertura, coraje, compromiso y respeto permiten un trabajo en equipo eficaz y sustentan la confianza.

3. Roles / Responsabilidades:

• Equipo Scrum – Pequeño, autogestionado, multifuncional y cognitivamente diverso, compuesto por:
  • Propietario del producto – Maximiza el valor a largo plazo, colabora con las Partes implicadas y gestiona el Product Backlog.
  • Scrum Master – Guía la adopción de Scrum, elimina impedimentos y promueve la mejora continua.
  • Desarrolladores – Entregan incrementos cada Sprint mediante sus capacidades multifuncionales.
  • Parte interesada – Entidad, individuo o grupo interesado, afectado o que influye en entradas, actividades y resultados, con interés directo o indirecto dentro o fuera de la organización, sus productos o servicios.
  • Aliado (tipo de parte interesada) – Fomenta el clima y entorno adecuados, y participa cuando se le solicita.
  • IA – Puede ser una herramienta o incluso un desarrollador de producto potencial, pero aún no debe ser completamente confiada.

4. Eventos y actividades de Scrum Scrum opera en Sprints (iteraciones de duración determinada de_hasta_cuatro_semanas) con cuatro eventos acotados en el tiempo:

• Planificación del Sprint – Definir el objetivo del Sprint y planificar el trabajo.
• Daily Scrum – Los desarrolladores se alinean a diario sobre el progreso hacia el objetivo del Sprint o del producto.
• Revisión del Sprint – Inspeccionar el incremento, el valor y el mercado, y adaptar el Product Backlog.
• Retrospectiva del Sprint – Reflexionar y mejorar como equipo.
• Refinamiento – Aclarar trabajo seleccionado o próximo, de manera formal (evento opcional) o informal.

5. Artefactos de Scrum y compromisos

• Producto & Definición de Hecho de Resultado – Producto y resultados valiosos que evidencian beneficios alcanzados.
• Incremento & Definición de Hecho de Producto – Actualización candidata potencialmente valiosa y liberable del producto.
• Product Backlog & Objetivo del Producto – Lista ordenada de trabajo para alcanzar un objetivo más estratégico a medio plazo.
• Sprint Backlog & Objetivo del Sprint – Elementos seleccionados del Product Backlog y un plan para el Sprint, objetivo a corto plazo.

Registro de Expansión

Adiciones

• Sección de IA
• Secciones de equipo Scrum autogestionado, cadencia y profesionalismo
• Sección sobre información y decisiones emergentes, abierta a la idea de que el riesgo o las desviaciones de expectativas no necesariamente disminuyen con el tiempo
• Complejidad (30–35): sección sobre la justificación de Scrum
• Secciones sobre liderazgo y pensamiento sistémico
• Secciones sobre pensamiento de producto y descubrimiento
• Secciones sobre primeros principios, personas y cambio
• Sección sobre productos con múltiples equipos Scrum
• Rol de Parte interesada (incluidos clientes, decisores y usuarios), y aliado como tipo de Parte interesada
• Secciones de Refinamiento y de Elemento del Product Backlog
• Opcionales: visión de producto, criterios de aceptación, criterios de resultado
• Definición de Hecho de Resultado, con énfasis adicional en la adaptación guiada por evidencia de resultados
• Se definen los términos Parte interesada, valor, retroalimentación de resultados, entrega, resultados, riesgo, impedimento y líder
• Análisis de flujo, pronósticos probabilísticos Monte Carlo, estimación a gran escala, conjuntos difusos (todos opcionales)
• Scrum expandido en una sola página
• Necesidad de que los flujos de trabajo, diseños, procesos, sistemas y entorno laboral sean coherentes con la información y decisiones emergentes
• “La propiedad del producto requiere sólidas habilidades de gestión de producto y conocimientos del dominio… Un Propietario del producto que no esté dispuesto, preparado o capacitado para adquirir estas habilidades debería dejar de ser Propietario del producto.”
• Un desarrollador de producto que no esté dispuesto, preparado ni capacitado para actuar profesionalmente debería dejar de ser desarrollador de producto
• Un Scrum Master que no esté dispuesto, preparado ni capacitado para ser agente de cambio debería dejar de ser Scrum Master
• Apéndices: explicación tipo Cynefin® – no oficial ni autorizada, estrategia emergente, empresa adaptativa (80), ejecutivo o miembro del consejo adaptativo

Sugerencias

• Clarificación y modificación de responsabilidades mientras se “abraza la ambigüedad” (73)
• De “Scrum es inmutable o simple” a “Scrum está evolucionando”; en algunos casos, se suaviza el lenguaje de “debe” a “debería”
• De responsabilidad del Propietario del producto a rol de Propietario del producto con responsabilidad; énfasis en maximizar valor a largo plazo
• De responsabilidad del desarrollador a rol de desarrollador de producto con responsabilidad
• De responsabilidad del Scrum Master a rol de Scrum Master con responsabilidad; el Scrum Master es una persona, no una IA
• Los desarrolladores de producto pueden ser humanos o IA, o asistidos por IA; al menos uno debe ser humano; contar con más desarrolladores humanos mejora la diversidad cognitiva y la capacidad para abordar la complejidad
• El equipo Scrum se compromete con el objetivo del Sprint, no los antiguos desarrolladores; es importante que el Propietario del producto esté enfocado
• El Sprint Backlog apunta al objetivo del Sprint o del producto, no solo al del Sprint
• Definición del producto, mención de estrategia de producto, hojas de ruta, modelos de producto, enfoques orientados a objetivos
• Énfasis en el aprendizaje, retroalimentación de resultados, efectos colaterales y foco en resultados por encima de entregables
• Para preservar el flujo de valor, los elementos incompletos del Product Backlog no tienen por qué volver a él
• “Definición de Hecho” renombrada como “Definición de Hecho de Producto”
• Énfasis en el ciclo de vida completo del producto y de las funcionalidades, así como en la realización de valor
• Los temas 1–3 de la planificación del Sprint se renombran como el Por Qué, el Qué y el Cómo; Sprint de hasta 4 semanas en vez de hasta 1 mes
• Posible revisión adicional del incremento y resultados en un entorno psicológicamente más seguro durante la retrospectiva
• Mayor énfasis en que el incremento siempre está hecho, por lo tanto “incremento hecho” es redundante
• Se explicita la maleabilidad del objetivo del producto (dentro de lo razonable)
• De la suposición optimista de entrega de valor a un foco intencional en la realización de valor
• Ética de calidad incorporada, claridad, decisiones basadas en datos, interacciones intencionales, información y decisiones emergentes (71), enfoque en resultados por encima de entregables, pausa y reflexión, realización de valor, comprensión del problema u oportunidad, fomento del clima/entorno para una adopción coherente de Scrum y mejora continua en una dirección
• Menor énfasis en la “organización nebulosa” para vincular el cambio con roles
• Adhesión más intencional de los valores de Scrum, considerando el contexto

Apéndice

Sección 2: Extracto de MORE executive SUCCESS Título: MORE executive SUCCESS extract Autor: John Coleman Fuente: (6) Licencia / Derechos de autor: CC BY-NC-ND 4.0 , © 2017–2025 Orderly Disruption Limited Nota: Esta sección se incluye en su forma original e inalterada con permiso, bajo los términos de la licencia CC BY-NC-ND 4.0 . No se han realizado modificaciones.

La empresa adaptativa

Es difícil que una empresa sea adaptativa (80) sin un clima donde las palabras y las acciones estén alineadas. Se estudiaron más de ochenta modelos de involucración. Entre ellos, están los marcos de escalado o desescalado y modelos operativos de producto, que pueden ser útiles para productos con múltiples equipos Scrum. Estos modelos varían desde hacer demasiado hasta no hacer lo suficiente para ayudar a que la organización de producto se vuelva más adaptativa. No existe una gran verdad universal ni una “zona perfecta” ajena al contexto concreto de las organizaciones.

Entre los modelos estudiados, hay varios candidatos destacados, entre otros: Beyond_Budgeting, Humanocracia y Sociocracia, que, según el contexto, deberían explorarse. Se recomienda considerar su combinación entre ellos y con otros enfoques.

Beyond Budgeting

Beyond_Budgeting (15–28, 90–98, 103) es una filosofía de gestión que rechaza la planificación presupuestaria anual rígida tradicional en favor de un enfoque descentralizado y adaptativo al control organizativo y la gestión del rendimiento. Se basa en 12 principios —seis que están centrados en el liderazgo y los demás seis en procesos de gestión— que promueven la toma de decisiones descentralizada, la transparencia, la autonomía de los equipos y una fuerte alineación con el valor para el cliente.

En lugar de objetivos fijos y planes anuales detallados, Beyond_Budgeting promueve el establecimiento dinámico de objetivos, la planificación continua y la asignación de recursos según las necesidades en tiempo real, fomentando la adaptabilidad y la capacidad de respuesta en un entorno empresarial cambiante. Este enfoque busca empoderar a los equipos, potenciar la innovación y asegurar que las organizaciones estén mejor preparadas para afrontar la incertidumbre (72) y la complejidad (30–35). Beyond Budgeting está mal nombrado (da la falsa impresión de que se limita a Finanzas) y bien nombrado al mismo tiempo (porque efectivamente va más allá del presupuesto).

Humanocracia

Humanocracia (2), tal como la define Gary Hamel, es un modelo de gestión que sustituye las jerarquías rígidas y el control centralizado por sistemas que maximizan la contribución y la creatividad de cada persona. En una humanocracia, las organizaciones existen para servir y empoderar a las personas, no solo para tratarlas como recursos al servicio de los objetivos empresariales.

Se basa en principios como propiedad distribuida, meritocracia, apertura, experimentación y comunidad, fomentando la autonomía y la innovación. La autoridad se basa en la competencia, y la toma de decisiones se descentraliza hacia quienes están más cerca del trabajo. Humanocracia prioriza la confianza, el compromiso y el desarrollo del potencial humano por encima del cumplimiento y el control, con el objetivo de construir entornos laborales resilientes e innovadores donde las personas impulsen cambios significativos.

Aunque modelos como Rendanheyi de Haier (56, 101) comparten los valores de descentralización y empoderamiento, humanocracia es una filosofía más amplia centrada en sustituir la burocracia por principios centrados en las personas que liberen la capacidad y el valor colectivos.

Sociocracia

La sociocracia (1, 11–14) es un sistema de gobernanza que organiza a las personas en círculos autogestionados (49) y toma decisiones por consentimiento, no por mayoría. Desarrollada por Gerard Endenburg (81) en los Países Bajos en los años 70, garantiza que toda persona afectada por una decisión tenga voz, avanzando propuestas salvo que surja una objeción razonada. Guiada por el principio de “lo suficientemente bueno por ahora, lo bastante seguro para intentarlo”, la sociocracia distribuye la autoridad, promueve la transparencia, la responsabilidad, la mejora continua y fomenta la colaboración y la propiedad compartida. Sus principios han influido en modelos como la holacracia y los equipos autogestionados.

La variante más establecida es el Método_de_Organización_en_Círculos_Sociocráticos (SCM), el método original y formalizado. El SCM emplea círculos semiautónomos, enlaces dobles (dos personas que asisten a dos círculos relacionados para conectarlos), toma de decisiones por consentimiento y elecciones abiertas para los roles. Esta estructura mantiene tanto la eficiencia organizativa como la equivalencia entre los miembros, y cuenta con una sólida trayectoria documentada en empresas, cooperativas y escuelas de los Países Bajos.

Aunque variantes más recientes como Sociocracia_3.0(S3) ofrecen mayor flexibilidad, el SCM sigue siendo la forma de sociocracia históricamente más validada y ampliamente documentada.

El ejecutivo o miembro del consejo adaptativo

MORE_Executive_SUCCESS identifica varias oportunidades para ejecutivos y miembros del consejo:

• Adquirir conocimiento sobre las Partes implicadas (incluido el cliente), sus necesidades y límites, el trabajo, cómo funciona el trabajo, los desperdicios, los antipatrones, el espacio del problema, las oportunidades, la evidencia de que puede generarse valor, los comportamientos y los hábitos
• Fomentar un clima de desempeño humano y habilitar la planificación de sucesión que lo proteja y lo mejore
• Desarrollar capacidad de respuesta y de flujo (68, 69) en las redes de valor
• Fomentar la información y decisiones emergentes (71) y la adaptabilidad (80) en una dirección con claridad
• Implicar a las personas, incluidos clientes y colegas
• Promover una planificación de sucesión eficaz y oportuna

Existe abundante información para quienes se encuentran en los niveles estructurales bajos, medios o laterales de una organización sobre cómo mejorar su adaptabilidad (80). Sin embargo, en el nivel ejecutivo, hay poca orientación sobre como ser efectivo en el momento oportuno y considerando los efectos en las personas, interacciones con el cliente y sobre “cómo funciona el trabajo”. Persiste la idea equivocada de que los agentes de cambio contratados pueden llenar ese vacío por sí solos, lo cual es poco realista, ya que el cambio pertenece a la organización.

La efectividad humana y las decisiones ágiles debería impregnar toda la estructura corporativa para obtener sus numerosos beneficios. Incluso las organizaciones que han “tenido éxito en la adopción del cambio” enfrentan riesgos. Las personas se van, otras perspectivas toman el control, y las modas corporativas pueden deshacer los avances en adaptabilidad. Puede surgir el caos negativo.

Muchos agentes y modelos de involucramiento dicen respaldar la adaptabilidad ejecutiva, lo cual es positivo porque distintos contextos organizativos requieren enfoques diferentes. Pero a pesar de todos los recursos disponibles, el panorama general de la adaptabilidad ejecutiva ha cambiado poco en más de 25 años.

Se usen o no tácticas, estrategias, métodos y marcos, las organizaciones deberían primero adoptar la ética que sustenta la ambidestreza, la efectividad humana, la adaptabilidad y la agilidad desde la cima. De lo contrario, los ejecutivos y miembros del consejo seguirán supervisando un “teatro del cambio” y un mosaico incompleto de islas efectivas y humanas dentro de la organización.

Iluminar el comportamiento ejecutivo

La postura o las acciones de los ejecutivos y miembros del consejo influirán más en el nuevo comportamiento de otras personas que sus palabras o directrices. Aun así, conviene revisar las preguntas que se plantean para mejorar la ambidestreza, la efectividad humana, la adaptabilidad y la agilidad.

Estas cualidades requieren eventualmente la extinción del comportamiento ejecutivo incoherente. Ejemplos de conductas más útiles incluyen aceptar el error, buscar información antes de juzgar, dar oportunidades para probar cosas nuevas y aprender, aceptar que no se sabe algo y ayudar a las personas a enfocarse. Existen opciones notables para abordar el comportamiento ejecutivo.

Inmunidad al cambio®

Lisa Laskow Lahey y Robert Kegan (de The Developmental Edge) crearon un enfoque de cambio conocido como Immunity_to_Change® (3, 4). Muchas personas saben lo que deben hacer, pero no lo hacen debido a compromisos internos en conflicto. Metafóricamente, tienen “un pie en el acelerador y otro en el freno”.

Immunity_to_Change® es un marco para definir esos “compromisos ocultos” y “supuestos limitantes” que impiden a las personas cambiar y alcanzar sus metas. La teoría y el mapa de Immunity_to_Change® han ayudado a numerosos profesionales y organizaciones a descubrir y superar los compromisos que obstaculizaban su crecimiento profesional y organizativo.

Intent-Based Leadership®

Intent-Based_Leadership® (IBL) (7, 8, 9) es un lenguaje que los equipos usan para lograr alto rendimiento, sustituyendo el lenguaje programado de la era industrial. IBL enfatiza el concepto de intención tanto del líder como del equipo. Está basado en los libros Turn_the_Ship_Around y Leadership_is_Language de L. David Marquet.

Uno de sus principios fundamentales es que el liderazgo no está reservado a unos pocos en la cima. En las organizaciones altamente efectivas, hay líderes en todos los niveles. L. David Marquet moldeó el liderazgo que desarrolló en el submarino nuclear USS Santa Fe en un sistema llamado Intent-Based_Leadership, para que las organizaciones lo implementen y fomenten el pensamiento y el liderazgo en todos los niveles.

Intent-Based_Leadership ayuda a los líderes a construir organizaciones donde las personas dan lo mejor de sí porque tienen autonomía, se apoyan en su motivación intrínseca, se sienten escuchadas y buscan la excelencia. Sienten un alto grado de pertenencia y control, por lo que implican su corazón y su mente. Obtienen recompensas psicológicas al ver los frutos de sus decisiones y trabajo. Existe una predisposición a la acción, y los equipos son más ágiles y resilientes porque se reduce la generación y propagación de errores.

La práctica de expresar la intención permite la toma de decisiones distribuida sin perder la unidad de esfuerzo. Intent-Based_Leadership_International (sitio web de IBLI) ofrece consultoría, formación, cursos online y libros para líderes.

Sección 3: Una especie de explicación del marco Cynefin – no oficial y no autorizada Título: Una especie de explicación del marco Cynefin – no oficial y no autorizada Fuente: Enlace al wiki original de Cynefin , [Enlace a esta adaptación] Licencia: Creative Commons Attribution-ShareAlike 4.0 International ( CC BY-SA 4.0 ).* © 2017–2025 Cynefin.io. Exención de responsabilidad: No se otorgan garantías. Úsese bajo su propia responsabilidad. Esta sección se ofrece bajo la licencia Creative Commons Attribution-ShareAlike 4.0 International. Al utilizar esta especie de explicación del marco Cynefin no oficial y no autorizada, acepta los términos de la licencia CC BY-SA 4.0 .

Cynefin®

Cynefin® (30–35) ofrece una brújula para la toma de decisiones en liderazgo. Fue popularizado por el artículo de Harvard Business Review “A Leader’s Framework for Decision Making” de Dave Snowden y Mary Boone en 2007, y nuevamente por “Managing complexity (and chaos) in a crisis – a field guide for decision makers inspired by the Cynefin framework”, también conocido como la “Guía de campo de la UE”. Su premisa es que uno debería actuar de forma distinta según las dinámicas del entorno. A menudo se simplifica en exceso. Un mismo problema puede existir en varios dominios al mismo tiempo, cada uno con aspectos diferentes.

Un cambio de fase se refiere a una transición —a menudo abrupta— entre dominios, especialmente del orden al caos, provocada cuando los límites del sistema (reglas, hábitos, barreras y retroalimentación) se desalinean o colapsan. Marca un cambio fundamental en el comportamiento del sistema, donde los métodos anteriores de control o entendimiento dejan de funcionar.

No todos los aspectos del desarrollo de producto son complejos. El equipo Scrum, en una situación dada, puede necesitar considerar distintos cambios de fase entre:

• Ordenado: Idea clave: Estabilidad, rutina, buenas/mejores prácticas, experiencia

  • La experiencia es suficiente, y la relación causa-efecto es predecible o conocida
  • Posibles respuestas: aplicar buenas prácticas, seguir reglas, usar análisis experto, realizar investigación individual
  • Metáforas: Cubo de hielo duro o casi congelado, clima agradable, ajedrez o sudoku
  • Ejemplo natural: Un invernadero moderno con control climático – predecible, controlado, crecimiento planificado
  • Ejemplo de producto: Resolver un problema técnico complejo consultando a expertos y analizando registros

• Complejo (30–35): donde la experiencia es valiosa pero no suficiente, y solo se puede entender por qué ocurrió algo a_posteriori. Idea clave: información y decisiones emergentes, experimentos seguros para fallar

  • Posibles respuestas:
    • Fomentar el aprendizaje y la adaptación
    • Probar varios experimentos pequeños y paralelos que puedan fallar sin riesgo
    • Fomentar ideas frescas mediante diversidad cognitiva y colaboración
    • Probar soluciones de otros contextos si pueden ser útiles
    • Experimentar con hipótesis o corazonadas informadas
  • Todo ello siguiendo principios útiles que permiten que los buenos resultados emerjan
  • Metáforas: Agua en movimiento, lluvia, o una partida de póker
  • Ejemplo natural: Zarzal enmarañado – todo está conectado de forma impredecible
  • Ejemplo de producto: Experimentar con distintas funcionalidades según la retroalimentación del usuario (p. ej., A/B testing de nuevas ideas de producto)

• Caótico:

  • Negativo – Idea clave: Crisis destructiva, colapso, acción urgente

    • Posibles respuestas: actuar de inmediato para restaurar el orden, priorizar la seguridad, hacer algo rápido sin empeorar la situación
    • Metáforas: Hielo que se rompe, explosión fuera de control, gas tóxico, tornado, terremoto, incendio forestal o disturbio en un estadio
    • Ejemplo natural: Desastre natural (p. ej., tsunami) – repentino, destructivo, impredecible
    • Ejemplo de producto: Responder ante una brecha de seguridad crítica aislando sistemas y aplicando parches de información y decisiones emergentes

  • Positivo – Idea clave: Disrupción generativa, innovación rápida

    • Posibles respuestas: provocar disrupción intencionalmente, fomentar la creatividad, canalizar la energía (p. ej., hackathon, incubadora, “viernes de innovación”)
    • Metáforas: Explosión controlada (motor de vapor), fuegos artificiales o hoguera de festival
    • Ejemplo natural: Incendio forestal que elimina la vegetación antigua y permite nuevos brotes – renovación del ecosistema
    • Ejemplo de producto: Pivotar rápidamente un producto ante una disrupción del mercado para aprovechar nuevas oportunidades (p. ej., lanzar una funcionalidad en respuesta a un movimiento de la competencia)

Liminalidad es una etapa “intermedia”, como un umbral. Los cambios de fase menos repentinos suelen ocurrir en los espacios liminales:

• En el liminal entre lo complejo y lo ordenado, este es el punto óptimo por defecto de Scrum:

• Ordenado-Complejo**:

  • De análisis experto a exploración adaptativa
  • Posibles respuestas: relajar algunas reglas, introducir experimentación, prepararse para la información y decisiones emergentes
  • Metáforas: Un cubo de hielo derritiéndose, clima nublado, pasar del ajedrez al póker
  • Ejemplo en la naturaleza: El deshielo estacional: el hielo rígido da paso a arroyos y nuevo crecimiento
  • Ejemplo de producto: Cuando un proceso rutinario deja de funcionar, animar al equipo a probar diferentes enfoques

• Complejo-Ordenado:

  • Posibles respuestas: convertir descubrimientos creativos en rutinas expertas; estabilizar la innovación, observar y codificar patrones exitosos; transición hacia la estandarización
  • Metáforas: Nieve semiderretida (entre hielo y agua), niebla que se disipa tras la lluvia, pasar del póker al ajedrez
  • Ejemplo en la naturaleza: Delta de un río formando canales: de flujo impredecible a estable
  • Ejemplo de producto: Convertir una funcionalidad experimental exitosa en un proceso documentado y repetible

• En el liminal entre lo complejo y lo caótico:

  • Complejo–Caótico (positivo):

    • Una situación en la que es necesario relajar restricciones para crear espacio y tiempo para la innovación. Idea clave: el borde de la creatividad, el riesgo y la innovación
    • Posibles respuestas: relajar restricciones, fomentar la experimentación, buscar ideas rompedoras
    • Metáforas: Agua hirviendo (al borde del vapor), tormenta eléctrica, teatro de improvisación o sesión de jazz
    • Ejemplo en la naturaleza: Volcán creando nueva tierra: transformación creativa al borde del caos
    • Ejemplo de producto: Ejecutar un hackathon de alto riesgo para generar ideas disruptivas

  • Complejo–Caótico (negativo):

    • Idea clave: transición destructiva hacia la crisis
    • Posibles respuestas: reimponer restricciones rápidamente, estabilizar la situación, evitar un colapso mayor
    • Metáforas: Olla a presión explotando, tornado repentino o inundación relámpago, tablero de juego arrojado con rabia
    • Ejemplo en la naturaleza: Deslizamiento de tierra repentino: pérdida de estructura, transición destructiva
    • Ejemplo de producto: Confusión tras el fracaso de un lanzamiento y necesidad urgente de recuperar el control

  • Caótico–Complejo: salir del caos — reagruparse

    • Posibles respuestas: detectar orden emergente, comenzar a explorar, fomentar la colaboración y el reconocimiento de patrones
    • Metáforas: Vapor condensándose en agua, calma tras un huracán, reanudar un partido después de una tormenta
    • Ejemplo en la naturaleza: Especies pioneras colonizando tras un incendio — nuevo crecimiento después de la perturbación
    • Ejemplo de producto: Tras una crisis, reagrupar al equipo para experimentar con nuevas formas de trabajo o nuevas direcciones del producto

• Aporía (liminal paradójico): convivir con la paradoja para obtener nuevos conocimientos, tal vez tras descubrir que la situación no era lo que parecía

  • Posibles respuestas: sostener la ambigüedad, fomentar la reflexión, permitir que emerja una nueva comprensión
  • Metáforas: Punto triple (coexistencia de sólido, líquido y gas), estar en el ojo de una tormenta, resolver un acertijo
  • Ejemplo en la naturaleza: Estuario donde se encuentran río, mar y tierra: todos los estados y posibilidades coexisten
  • Ejemplo de producto: El equipo está atrapado entre estrategias o visiones contradictorias y debe hacer una pausa para reflexionar y realinearse

• Cambio de fase raramente considerado debido a su dificultad**: liminal **Caótico–Ordenado**

  • Posibles respuestas: imponer fuertes restricciones, restablecer reglas y estructura

  • Metáforas: Hielo que se vuelve a congelar rápidamente, ola de frío tras una tormenta, un árbitro estrictamente eficaz tras el caos

  • Ejemplo en la naturaleza: Se construye una presa después de una inundación: un río salvaje contenido de forma repentina y controlada

  • Ejemplo de producto:

    • Tras una gran interrupción de producción o una crisis de producto, un equipo de crisis multifuncional estabiliza rápidamente la situación con reglas claras y protocolos temporales
    • Una vez superado el peligro inmediato, estas reglas se refinan iterativamente y se formalizan como procesos sostenibles y equilibrados, evitando la sobrerreacción o la burocracia excesiva

Un cambio de fase especialmente repentino y negativo es el liminal Ordenado–Caótico:

• Posibles respuestas: reconocer fragilidad y exceso de confianza, actuar rápidamente para restaurar los límites y la seguridad
• Metáforas: Hielo que se quiebra en astillas, granizada violenta repentina, reglas del juego que se desechan de repente
• Ejemplo en la naturaleza: Lago congelado que se rompe en primavera: superficie estable que se fractura de repente
• Ejemplo de producto: Un proceso estable de producto se rompe repentinamente por un evento inesperado (por ejemplo, una interrupción grave)

Sección 4: Estrategia emergente Autores: Roger L. Martin, Tom Gilb Fuente: (41–48) Copyright: Todos los derechos reservados. Adaptado

Estrategia emergente

La estrategia no está limitada por la escala; si existe, debe estar claramente articulada a nivel corporativo, de unidad de negocio o de producto, y mantenerse coherente e integrada entre estos niveles. Es fundamental que la estrategia distinga entre fines (resultados cuantificados y valorados por las personas implicadas) y medios (iniciativas o actividades).

Basándose en los trabajos de Roger L. Martin (41) y Tom Gilb (43–48), y adaptándolos, una estrategia consiste en tomar decisiones explícitas e integradas: decidir qué perseguir y qué no, partiendo de una aspiración ganadora bien definida y medible, no solo de una misión o visión amplia. Una estrategia efectiva responde a:

• ¿Dónde jugaremos?
• ¿Cómo ganaremos de forma ética (57) y sostenible, equilibrando múltiples expectativas y límites?
• ¿Qué capacidades y sistemas deben estar presentes?
• ¿Qué más debe ser cierto para que esta estrategia tenga éxito?

Para situaciones en las que la experiencia por sí sola es suficiente (o casi suficiente), a fin de garantizar que la estrategia sea iterativa, accionable y centrada en el valor:

• Cuantificar y gestionar iterativamente el valor para las personas implicadas, impactos múltiples o efectos secundarios, riesgos y compensaciones:

  • Identificar a todas las personas implicadas clave (incluyendo pero no limitándose a clientes) y definir sus objetivos de valor en términos medibles (por ejemplo, “reducir el tiempo de incorporación de nuevos usuarios de 5–10 a 2–4 días”).
  • Cuantificar explícitamente compensaciones y restricciones, y revisarlas a medida que surja nueva información.
  • Utilizar pensamiento integrador para resolver tensiones de forma creativa.

• Cocrear y priorizar de forma colaborativa:

  • Desarrollar la estrategia combinando percepciones de arriba abajo, de abajo arriba y colaboración lateral.
  • Usar talleres estructurados y bucles de retroalimentación para fomentar la alineación y adaptabilidad, y reordenar continuamente el trabajo aún no iniciado.

• Entregar valor de forma incremental y medir resultados:

  • Descomponer aspiraciones estratégicas en incrementos pequeños, priorizados y medibles.
  • Entregar valor en ciclos cortos (por ejemplo, Sprints o semanas), midiendo los resultados reales y efectos secundarios frente a los objetivos cuantificados originales.
  • Usar revisiones periódicas para ajustar la estrategia con base en retroalimentación real.

• Permitir la información y decisiones emergentes:

  • Dejar que la estrategia evolucione según nuevos datos y retroalimentación de las personas implicadas (incluyendo, entre otros, usuarios), dentro de un marco de objetivos claros, cuantificados, tendencias medibles y evaluación regular de riesgos/beneficios.
  • Hacer correcciones de rumbo rápidamente y con transparencia conforme se desarrolla la realidad.

• Asegurar que tanto la estrategia como su despliegue estén orientados a resultados y tengan foco (decidir en qué trabajar y en qué no). Distinguir entre:

  • Estrategia: incluyendo la intención, la razón, los objetivos y los antiobjetivos (el qué y el por_qué),
  • Despliegue estratégico: operacionalización de la estrategia, secuenciación iterativa o descomposición de elecciones integradas para la estrategia, usualmente en porciones pequeñas orientadas a resultados (el qué y el por_qué),
  • Elementos del Product Backlog orientados a resultados y con foco (porciones más pequeñas para quién), y
  • Listas de actividades o iniciativas (el “qué haremos” o cómo).

• Evitar confundir una colección de proyectos con una estrategia coherente y orientada al valor.

Para situaciones donde la experiencia es valiosa pero insuficiente, la relación causa–efecto solo se entiende a posteriori, y es necesario abrazar la incertidumbre, los equipos Scrum y las personas implicadas deben:

• Aceptar la complejidad del trabajo menos estructurado y orientado a resultados en una dirección de avance.

• Reconocer que los planes detallados a largo plazo son ineficaces. En su lugar, centrarse en crear condiciones donde los patrones útiles y la innovación emerjan de las interacciones dentro del sistema.

• En lugar de probar una sola idea cada vez y seguir con lo que funcionó antes, considerar varios experimentos seguros en paralelo para ver qué ocurre y aprender de lo que emerja.

• Fomentar un clima de exploración creativa, innovación y evolución desde el presente. Crear procesos y entornos donde las personas puedan conectar ideas novedosas, aprendizajes, intuiciones fundamentadas, y aprender entre sí, en lugar de imponer uniformidad o KPIs rígidos.

• Las posibles respuestas no se limitan a:

  • Mapear lo que ya se conoce y entender el potencial evolutivo del sistema antes de intentar cambiarlo
  • Fomentar la autoorganización
  • Ejecutar experimentos seguros (probes): pequeños, paralelos y diseñados para que el fallo sea asumible y aporte aprendizaje
  • Buscar pensamiento fresco
  • Probar soluciones de problemas distintos para aplicarlas a la situación actual
  • Poner a prueba intuiciones fundamentadas
  • Observar lo que emerge, amplificar los patrones exitosos y atenuar o detener los que no funcionan
  • La innovación es importante, pero las soluciones probadas deben reutilizarse para problemas recurrentes
  • Realizar una interpretación continua del contexto (sense-making)
  • Capturar narrativas

• Metáfora: El rol de liderazgo es preparar y gestionar activamente el suelo, los límites y las condiciones (el “sustrato”) para fomentar el crecimiento de plantas sanas (soluciones emergentes). Esto incluye, en sentido figurado, eliminar malas hierbas, podar y dar forma al entorno, no solo esperar pasivamente resultados.

En general, deben evitarse las recompensas por motivación extrínseca debido al “efecto cobra” (104), a menos que sean coherentes con Beyond Budgeting. Del mismo modo, el rendimiento individual o de equipo debe desvincularse de los resultados, ya que puede que los resultados se hayan logrado, pero ¿de qué forma se lograron?, ¿con qué efectos secundarios?, ¿cómo afectaron a la moral del equipo?

No obstante:

• Hay desacuerdo en artículos revisados por pares (105–108) y en un artículo fundacional no revisado (109) sobre si cuantificar las expectativas, límites u objetivos de las personas implicadas ayuda o perjudica, y si reduce la motivación intrínseca.
• Considerar el contexto. También si la cuantificación apoya la autonomía y el sentido o impone restricciones controladoras.
• Por ahora, este documento prefiere errar del lado de la clarificación y el entendimiento compartido, cuantificando expectativas, límites y dirección de avance, respaldado por narrativas de calidad y precisión (más historias como esta, menos historias como aquella).

Una estrategia emergente se apoya en una hoja de ruta orientada a resultados y también emergente, que puede ir desde el objetivo del Sprint hasta la visión de producto y más allá. El despliegue de la estrategia emergente (120–123) no debe confundirse con la estrategia emergente. Los modelos de cambio vectorial (30–35, 54), modelos operativos de producto (113–119), modelos de escalado y desescalado (134–147) y modelos emergentes orientados a objetivos (120–133) pueden ser muy beneficiosos para el despliegue de estrategia emergente. Es preferible optar por modelos coherentes con el cambio vectorial, es decir, dirección de avance más que metas fijas.

El despliegue de estrategia emergente implica permitir que los planes y acciones se desarrollen de forma natural conforme el equipo Scrum y las personas implicadas responden a los cambios reales. En lugar de seguir un camino fijo, prestan atención a lo que ocurre a su alrededor y se adaptan sobre la marcha. Con el tiempo, los pasos dados forman un patrón que se convierte en la estrategia real, incluso si difiere de lo inicialmente previsto.

Atribución de la colección del Paquete de expansión de la Guía Scrum

Esta colección fue escrita y compilada por Ralph Jocham, John Coleman y Jeff Sutherland. Cada sección está atribuida individualmente más arriba y conserva su licencia original. La colección en su conjunto tiene fines informativos; por favor, respeta los términos de licencia de cada sección.

Referencias bibliográficas

1. Rau, T. (2022) Sociocracy - Basic Concepts and principles, Sociocracy For All. At: https://www.sociocracyforall.org/sociocracy/ (Accessed: April 5, 2023).
2. Hamel, G. and Zanini, M. (2023) Humanocracy. At: https://www.humanocracy.com/ (Accessed: April 5, 2023).
3. Kegan, R. and Laskow Lahey, L. (2019) An everyone culture, The Developmental Edge. At: https://developmentaledge.com/an-everyone-culture/ (Accessed: April 4, 2023).
4. Laskow Lahey, L. and Kegan, R. (2023) News & thinking, The Developmental Edge. At: https://developmentaledge.com/newsthinking/#methodologies (Accessed: April 3, 2023).
5. Moore, G.A., 1991. Crossing the Chasm: Marketing and Selling High-Tech Products to Mainstream Customers. New York: Harper Business.
6. Coleman, J., (2025) MORE executive SUCCESS. Unpublished.
7. Marquet, L. D. (2013) Turn the Ship Around! A True Story of Turning Followers into Leaders. Portfolio.
8. Marquet, L.D. (2021) Leadership is language: The hidden power of what you say and what you don’t. Nakskov, Denmark: Nota.
9. Marquet, L. D. (2021) Based Leadership® International with L. David Marquet - IBLI. At: https://davidmarquet.com/ (Accessed: April 5, 2023).
10. Rau, T.J. and Koch-Gonzalez, J. (2018) Many voices one song: Shared power with sociocracy. Amherst, MA: Sociocracy for All.
11. Buck, J. & Endenburg, G. (2012) The creative forces of self-organization. Sociocratic Center.
12. Buck, J. & Villines, S. (2017) We the people: Consenting to a deeper democracy. 2nd edn. Sociocracy.info Press.
13. Endenburg, G. (1998) Sociocracy: The organization of decision-making. Delft: Eburon Publishers.
14. Priest, J. & Bockelbrink, B. (2018) Sociocracy 3.0 – The practical guide. Available at: https://sociocracy30.org/ (Accessed: 17 May 2025).
15. Bogsnes, B. (2023) This is beyond budgeting: A guide to more adaptive and human organizations. Hoboken, NJ: John Wiley & Sons, Inc.
16. Bogsnes, B. (2023) Beyond budgeting at 25 - bbrt.org , Beyond Budgeting Round Table. At: https://bbrt.org/wp-content/uploads/bb-white-paper_a.pdf (Accessed: April 7, 2023).
17. Olesen, A. (2016) Beyond budgeting: Principle 1 - purpose, YouTube. At: https://youtu.be/_9ZW2NjyFxE (Accessed: April 7, 2023).
18. Larsson, D. (2016) Beyond budgeting: Principle 2 - values, YouTube. At: https://youtu.be/pl1BPrITbm4 (Accessed: April 7, 2023).
19. Player, S. (2016) Beyond budgeting: Principle 3 - transparency, YouTube. At: https://youtu.be/Mb7K8App2vw (Accessed: April 7, 2023).
20. Röösli, F. (2016) Beyond budgeting: Principle 4 - Organization, YouTube. At: https://youtu.be/i8HIgc8OZYM (Accessed: April 7, 2023).
21. Larsson, D. (2016) Beyond budgeting: Principle 5 - autonomy, YouTube. At: https://youtu.be/ipnjHtXYi-g (Accessed: April 7, 2023).
22. Player, S. (2016) Beyond budgeting: Principle 6 - customers, YouTube. At: https://youtu.be/_6fut4R_wVw (Accessed: April 7, 2023).
23. Bogsnes, B. (2016) Beyond budgeting: Principle 7 - rhythm, YouTube. At: https://youtu.be/rb_NsnPNIQQ (Accessed: April 7, 2023).
24. Röösli, F. (2016) Beyond budgeting: Principle 8 - targets, YouTube. At: https://youtu.be/up3mp7jN6XU (Accessed: April 7, 2023).
25. Player, S. (2016) Beyond budgeting: Principle 9 - plans and forecasts, YouTube. At: https://youtu.be/OWM7FUuXejI (Accessed: April 7, 2023).
26. Olesen, A. (2016) Beyond budgeting: Principle 10 - resource allocation, YouTube. At: https://youtu.be/mPCYHmvi_b8 (Accessed: April 7, 2023).
27. Bogsnes, B. (2016) Beyond budgeting: Principle 11 - performance evaluation, YouTube. At: https://youtu.be/RfPVtG2B27E (Accessed: April 7, 2023).
28. Röösli, F. (2016) Beyond budgeting: Principle 12 - rewards, YouTube. At: https://youtu.be/ETU5TzNYiC0 (Accessed: April 7, 2023).
29. Takeuchi, H. and Nonaka, I. (2014) The new new product development game, Harvard Business Review. At: https://hbr.org/1986/01/the-new-new-product-development-game (Accessed: 21 January 2024).
30. Cynefin.io , V. (2022) Cynefin wiki, Cynefin.io . Cynefin.io . At: https://cynefin.io/ (Accessed: April 4, 2023).
31. Rancati, A. and Snowden, D. (2021) Managing complexity (and chaos) in a crisis - a field guide for decision makers inspired by the Cynefin framework. Luxembourg, Belgium: Publications Office of the European Union.
32. Snowden, D. et al. (2022) Cynefin® weaving sense-making into the fabric of our world. 2nd edn. Edited by R. Greenberg and B. Bertsch. Singapore, Singapore: Cognitive Edge - The Cynefin Co.
33. Snowden, D. (2023) Cynefin St David’s 2023 1 of 2, Cynefin Co. https://thecynefin.co/cynefin-st-davids-2023-1-of-2/ (Accessed: April 20, 2023).
34. Snowden, D. (2023) Managing for emergence through abduction, The Cynefin Co. At: https://thecynefin.co/managing-for-emergence/ (Accessed: June 24, 2023).
35. Snowden, D. and Smith, N. (2023) Leadership discussion: Dave and Natalie - the Cynefin co, YouTube. At: https://youtu.be/WcPZ8ybDF0w (Accessed: April 7, 2023).
36. Langton, C.G. (ed.) (1989) Artificial Life: Proceedings of an Interdisciplinary Workshop on the Synthesis and Simulation of Living Systems, Los Alamos, New Mexico, September 1987. Santa Fe Institute Studies in the Sciences of Complexity, vol. VI. Redwood City, CA: Addison-Wesley.
37. Langton, C.G. (1989) ‘Life at the edge of chaos’, in Langton, C.G. (ed.) Artificial Life: Proceedings of an Interdisciplinary Workshop on the Synthesis and Simulation of Living Systems. Santa Fe In stitute Studies in the Sciences of Complexity, vol. VI. Redwood City, CA: Addison-Wesley, pp. 41–91.
38. Wolfram, S. (2002) A new kind of science. Champaign, IL: Wolfram Media.
39. Alexander, C. (1979) The timeless way of building. New York: Oxford University Press.
40. Schwaber, K. & Sutherland, J. (2020) The Scrum Guide: The definitive guide to Scrum: The rules of the game. Available at: https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf (Accessed: 17 May 2025)
41. Martin, R.L. (2022) A new way to think your guide to Superior Management Effectiveness. Boston, MA, MA, USA: Harvard Business Review Press.
42. Gilb, T. & Graham, D. (1993) Software Inspection. Harlow: Addison-Wesley.
43. Gilb, T. (1988) ‘Deeper perspectives on evolutionary delivery, in Principles of Software Engineering Management. Wokingham: Addison-Wesley, pp. [chapter 15]. Also available at: https://bit.ly/TomGilbEvo .
44. Gilb, Tom & Maier, Mark. (2005). Managing Priorities: A Key to Systematic Decision Making. INCOSE International Symposium. 15. 10.1002/j.2334-5837.2005.tb00782.x. Also available at: https://bit.ly/TomGilbPriorities .
45. Gilb, T. (1988) ‘Deeper perspectives on evolutionary delivery’, in Principles of Software Engineering Management. Wokingham: Addison-Wesley, pp. [chapter 15].
46. Gilb, T. (2005) Competitive Engineering: A Handbook for Systems Engineering, Requirements Engineering, and Software Engineering Using Planguage. Oxford: Elsevier Butterworth-Heinemann. Also available at: https://bit.ly/TomGilbCompEng .
47. Gilb, T. (2009) ‘Agile specification quality control: Shifting emphasis from cleanup to sampling defects’, Testing Experience, March. Available at: https://www.researchgate.net/publication/294196272_Agile_specification_quality_control [Accessed: 17 May 2025].
48. Gilb, T. & Gilb, K. (1989) ‘The McDonnell-Douglas case study of SQC and engineering improvement: Case DAC Inspection 1988–89’. Available at: https://bit.ly/TomGilbMcDonnell-Douglas [Accessed: 17 May 2025].
49. LeSS.works (n.d.) Self-managing teams. Available at: https://less.works/less/management/self-managing-teams (Accessed: 17 May 2025).
50. Gothelf, J. & Seiden, J. (2021) Lean UX: Designing great products with agile teams. 3rd edn. Sebastopol, CA: O’Reilly Media
51. Torres, T. (2021) Continuous discovery habits: Discover products that create customer value and business value. North Charleston, SC: Product Talk
52. Scrum.org (2025) Scrum Hexis. Available at: https://thecynefin.co/product/hexi-scrumorg/?srsltid=AfmBOorcohLYeVy0qBsQFI6mK_bZtJA_uGC6hPL2BdptiTwNmMwpKTQv (Accessed: 17 May 2025).
53. Sutherland, J., Coplien, J.O., Heasman, L., den Hollander, M., Ramos, C. and The Scrum Patterns Group (2019) A Scrum Book: The Spirit of the Game. Raleigh, NC: Pragmatic Press.
    Members of The Scrum Patterns Group: Vervloed, E., Harrison, N., Harada, K., Yoder, J., Kim, J., O’Callaghan, A., Beedle, M., Bjørnvig, G., Friis, D., Reijonen, V., Benefield, G., Østergaard, J., Eloranta, V.-P., Leonard, E. & Aguiar, A.
54. Snowden, D. (2025) ‘Estuarine mapping first edition’, The Cynefin Co, 22 April. Available at: https://thecynefin.co/estuarine-mapping/ (Accessed: 8 June 2025)
55. Ackoff, R.L. (1999) Ackoff’s Best: His Classic Writings on Management. New York: John Wiley & Sons.
56. Fischer, B., Minnaar, J., Moehrle, M., & Cornuel, E. (2020) RenDanHeYi: Pioneering the Quantum Organisation. EFMD Global Focus, Special Supplement. Available at: https://bit.ly/RenDanHeYi [Accessed 27 May 2025]
57. Blackburn, S. (2003) Ethics: A Very Short Introduction. Oxford: Oxford University Press.
58. Mayer, T. (2025) A Simple Guide to Scrum. [Online]. Available at: https://scrum.academy/guide/ (Accessed: 17 May 2025)
59. Ohno, T. (1988) Toyota Production System: Beyond Large-Scale Production. Portland, OR: Productivity Press.
60. Toyota Motor Corporation (2024) Toyota Production System. Available at: https://global.toyota/en/company/vision-and-philosophy/production-system/index.html (Accessed: 17 May 2025).
61. Hounshell, D.A. & Smith, J.K. (1988) Science and Corporate Strategy: DuPont R&D, 1902–1980. Cambridge: Cambridge University Press.
62. Schwaber, K. and Sutherland, J. (1995) ‘SCRUM Development Process’, OOPSLA Business Object Design and Implementation Workshop. Austin, Texas, October 1995. Available at: http://jeffsutherland.org/oopsla/schwapub.pdf (Accessed: 17 May 2025).
63. Womack, J.P. and Jones, D.T. (1996) Lean Thinking: Banish Waste and Create Wealth in Your Corporation. New York: Simon & Schuster.
64. Thurlow, N., Turner, J.R. and Podder, A. (2020) The Flow System: The Evolution of Agile and Lean Thinking in an Age of Complexity. Flow Consortium. Available at: https://flowguides.org/Flow_Guide.pdf (Accessed: 17 May 2025).
65. Felderer, M. and Travassos, G.H. (2020) ‘The Evolution of Empirical Methods in Software Engineering’. Available at: https://arxiv.org/pdf/1912.11512.pdf (Accessed: 17 May 2025).
66. Creative Wisdom (n.d.) ‘Abduction, Deduction and Induction’. Available at: https://www.creative-wisdom.com/teaching/WBI/abduction5.pdf (Accessed: 17 May 2025).
67. Campbell, J. (2025) ‘Empiricism’, EBSCO Research Starters. Available at: https://www.ebsco.com/research-starters/religion-and-philosophy/empiricism (Accessed: 17 May 2025)
68. Kanban Guides (2025) Available at: https://kanbanguides.org (Accessed: 17 May 2025)
69. Scrum.org et al. (2021) The Kanban Guide for Scrum Teams. Available at: https://www.scrum.org/resources/kanban-guide-scrum-teams (Accessed: 17 May 2025)
70. Csíkszentmihályi, M. (1990) Flow: The Psychology of Optimal Experience. New York: Harper & Row
71. Templeton Foundation (2023) ‘What Is Emergence?’ John Templeton Foundation. Available at: https://www.templeton.org/news/what-is-emergence (Accessed: 17 May 2025).
72. van der Bles, A.M., van der Linden, S., Freeman, A.L.J. and Spiegelhalter, D.J. (2019) ‘Communicating uncertainty about facts, numbers and science’, Royal Society Open Science, 6(5), 181870. Available at: https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6549952/ (Accessed: 17 May 2025).
73. Morieux, Y. (2015) How too many rules at work keep you from getting things done: Yves Morieux: Ted Talks, YouTube. At: https://youtu.be/t NoFstCmQ (April 3, 2023).
74. Holland, J.H. (1992) Complex Adaptive Systems. Daedalus, 121(1), pp. 17–30. Available at: https://www.jstor.org/stable/20025416 (Accessed: 17 May 2025).
75. Axelrod, R. and Cohen, M.D. (2000) Harnessing Complexity: Organizational Implications of a Scientific Frontier. New York: Free Press.
76. Juarrero, A. (1999) Dynamics in Action: Intentional Behavior as a Complex System. Cambridge, MA: MIT Press.
77. Snowden, D.J. and Boone, M.E. (2007) ‘A leader’s framework for decision making’, Harvard Business Review, 85(11), pp. 68–76. Available at: https://hbr.org/2007/11/a-leaders-framework-for-decision-making (Accessed: 17 May 2025)
78. Dictionary Marketing (2024) ‘B2B2B’. Available at: https://dictionarymarketing.com/definition/b2b2b/ (Accessed: 17 May 2025).
79. NetSuite (2023) ‘What Is Business to Business to Consumer (B2B2C)?’ Available at: https://www.netsuite.com/portal/resource/articles/ecommerce/b2b2c.shtml (Accessed: 17 May 2025).
80. LeSS (n.d.) ‘Why LeSS? Achieving adaptiveness’. Available at: https://less.works/less/framework/why-less (Accessed: 17 May 2025).
81. Sociocracy For All (n.d.) ‘Gerard Endenburg: founder of Sociocratic Circle Method and pioneer of self-management’. Available at: https://www.sociocracyforall.org/gerard-endenburg-founder-of-sociocratic-circle-method-and-pioneer-of-self-management/ (Accessed: 18 May 2025).
82. Patton, J. and Economy, P. (2014) User Story Mapping: Discover the Whole Story, Build the Right Product. Sebastopol, CA: O’Reilly Media.
83. Kotter, J.P., 1996. Leading Change. Boston: Harvard Business School Press.
84. ‘Genchi Genbutsu’ (2024) Wikipedia. Available at: https://en.wikipedia.org/wiki/Genchi_genbutsu (Accessed: 18 May 2025).
85. ScrumPlop, n.d. Illigitimus Non Interruptis. The Scrum Book: The Spirit of the Game. Available at: https://sites.google.com/a/scrumplop.org/published-patterns/product-organization-pattern-language/illegitimus-non-interruptus [Accessed: 18 May 2025].
86. Cagan, M., 2018. Inspired: How to Create Tech Products Customers Love. 2nd ed. Hoboken, NJ: Wiley.
87. Cagan, M. & Jones, C., 2020. Empowered: Ordinary People, Extraordinary Products. Hoboken, NJ: Wiley.
88. Cagan, M., 2024. Transformed: Moving to the Product Operating Model. Hoboken, NJ: Wiley.
89. Schwaber, K. (2023) ‘Scrum Guide’, Ken Schwaber’s Blog, 25 September. Available at: https://kenschwaber.wordpress.com/2023/09/25/scrum-guide/ (Accessed: 20 May 2025).
90. Future Ready: How to Master Business Forecasting
    Morlidge, S. & Player, S., 2010. Future Ready: How to Master Business Forecasting. Chichester: John Wiley & Sons.
91. The Little Book of Beyond Budgeting
    Morlidge, S., 2024. The Little Book of Beyond Budgeting: A New Management Model for Organisations (Second Edition) [Beyond Books Press]
92. The Little (Illustrated) Book of Operational Forecasting
    Morlidge, S., 2019. The Little (Illustrated) Book of Operational Forecasting. [Troubador].
93. Present Sense
    Morlidge, S., 2019. Present Sense. [Troubador].
94. Zen and the Art of Organising Work
    Morlidge, S., 2021. Zen and the Art of Organising Work. [Troubador].
95. Cost Matters
    Morlidge, S., 2023. Cost Matters. [Beyond Books Press].
96. Beyond Budgeting i praktiken Fahlén, K., 2016. Beyond Budgeting i praktiken. Stockholm: Liber.
97. Fahlén, K., 2018. Dynamic Management Strategy: A guide to management innovation and competitive advantage. Gothenburg: BAS
98. Bogsnes, B., 2016. Implementing Beyond Budgeting: Unlocking the Performance Potential. 2nd ed. Chichester: John Wiley & Sons.
99. Boyd, J.R. (1995–1996) The Essence of Winning and Losing. Unpublished briefing slides. Note: Boyd’s OODA was primarily disseminated through military briefings and unpublished manuscripts. His final conceptualization appears in The Essence of Winning and Losing, which emphasizes nonlinear decision-making and adaptation in complex environments.
100. Turner, J.R., Thurlow, N. and Rivera, B. (2019) The Flow System Guide. Available at: https://flowguides.org/Flow_Guide.pdf (Accessed: 24 May 2025). Summary: This guide integrates Boyd’s OODA with complexity theory and agile practices, framing it as a dynamic, non-linear decision-making process for organizational flow.
101. Williamson, P.J. & Yin, E. (2018) ‘Management Innovation Made in China: Haier’s Rendanheyi’, California Management Review, 61(1), pp. 71-93.
102. Richards, C. (2004) Certain to Win: The Strategy of John Boyd, Applied to Business. Bloomington, IN: Xlibris
103. Becker, S et al (co-author) The Viable Map Workbook 2023 [Beyond Books Press]
104. Frey, B.S. and Jegen, R. (2001) ‘Motivation crowding theory’, Journal of Economic Surveys, 15(5), pp. 589–611.
105. Cameron, J., Banko, K.M. and Pierce, W.D. (2001) ‘Pervasive negative effects of rewards on intrinsic motivation: The myth continues’, The Behavior Analyst, 24(1), pp. 1–44.
106. Deci, E.L., Koestner, R. and Ryan, R.M. (1999) ‘A meta-analytic review of experiments examining the effects of extrinsic rewards on intrinsic motivation’, Psychological Bulletin, 125(6), pp. 627–668.
107. Ryan, R.M. and Deci, E.L. (2000) ‘Intrinsic and extrinsic motivations: Classic definitions and new directions’, Contemporary Educational Psychology, 25(1), pp. 54–67.
108. Sandel, M.J. (2012) What money can’t buy: The moral limits of markets. London: Allen Lane.
109. Kohn, A. (1993) ‘Why incentive plans cannot work’, Harvard Business Review, 71(5), pp. 54–63.
110. Fuzzy Business: How to be roughly right rather than precisely wrong (unpublished).
111. Lewis, R. (2023) An operating model for business agility: Agile for managers of the digital age. Independently published.
112. less.works (n.d.) Technical Excellence. Available at: https://less.works/less/technical-excellence (Accessed: 7 June 2025)
113. Cagan, M. (2024) Transformed: Moving to the Product Operating Model. Hoboken, NJ: Wiley.
114. Cagan, M. (2025) ‘The Product Operating Model’, Silicon Valley Product Group, 17 March. Available at: https://www.svpg.com/the-product-operating-model/ (Accessed: 8 June 2025).
115. Cagan, M. (n.d.) ‘The Product Operating Model: An Introduction’, Silicon Valley Product Group. Available at: https://www.svpg.com/the-product-operating-model-an-introduction/ (Accessed: 8 June 2025)
116. Scrum.org (2025) ‘The Agile Product Operating Model’, Scrum.org, 1 May. Available at: https://www.scrum.org/resources/agile-product-operating-model (Accessed: 8 June 2025).
117. Scrum.org (2025) ‘Agile Product Operating Model State of Play - Part 1 - Fundamentals’, Scrum.org, 12 May. Available at: https://www.scrum.org/resources/blog/agile-product-operating-model-state-play-part-1-fundamentals (Accessed: 8 June 2025).
118. Scrum.org (2024) ‘Project to Product and the Agile Product Operating Model’, Scrum.org, 7 November. Available at: https://www.scrum.org/resources/blog/project-product-and-agile-product-operating-model (Accessed: 8 June 2025).
119. Scrum.org (2024) Moving to an Agile Product Operating Model [PDF]. Available at: https://www.scrum.org/resources/moving-agile-product-operating-model-evidence-based-approach-delivering-products-digital-age or https://bit.ly/SDOAPOM . (Accessed: 8 June 2025)
120. Scotland, K. (2023) Why strategy deployment? Here are three great reasons, AvailAgility. At: https://availagility.co.uk/2023/02/16/why-strategy-deployment-here-are-three-great-reasons/ (Accessed: April 3, 2023).
121. Scotland, K. (2019) Deploying strategies as choices, AvailAgility. At: https://availagility.co.uk/2019/02/08/deploying-strategies-as-choices/ (Accessed: April 3, 2023).
122. Scotland, K. (2017) Strategy deployment and playing to win, AvailAgility. At: https://availagility.co.uk/2017/07/14/strategy-deployment-and-playing-to-win/ (Accessed: April 3, 2023).
123. Scotland, K. (2017) A strategy deployment cadence, AvailAgility. At: https://availagility.co.uk/2017/09/06/a-strategy-deployment-cadence/ (Accessed: April 3, 2023).
124. Scotland, K. (2022) The ultimate X-matrix for your agile transformation is here, AvailAgility. At: https://availagility.co.uk/2022/11/03/the-ultimate-x-matrix-for-youragile-transformation-is-here/ (Accessed: April 5, 2023).
125. Krebs, J. (2023) Agile kata pro, Agile Kata Pro. At: https://agilekata.pro/ (Accessed: April 4, 2023).
126. Doerr, J. (2023) OKRs 101, What Matters. At: https://www.whatmatters.com/get-started/ (Accessed: April 4, 2023).
127. Wodtke, C. (2021) Radical focus achieving your most important goals with objectives and key results–. Palo Alto, CA: Cucina Media.
128. Gothelf, J. & Seiden, J. (2024) Who Does What By How Much?: A Practical Guide to Customer-Centric OKRs. New York: Sense & Respond Press.
129. Appelo, J. (2023) Sometimes, you *don’t* want focus, unFIX. At: https://unfix.com/blog/sometimes-you-dont-want-focus (Accessed: 14 January 2024).
130. Appelo, J. (2023) Bets and objectives, unFIX. At: https://unfix.com/bets-and-objectives (Accessed: 14 January 2024).
131. McChesney, C. (2023) The 4 disciplines of execution (new), FranklinCovey. At: https://www.franklincovey.com/the-4-disciplines/ (Accessed: April 4, 2023).
132. Scrum.org (2024) Evidence-Based Management (EBM) Framework, Scrum.org. Available at: https://www.scrum.org/resources/evidence-based-management . (Accessed: 8 June 2025).
133. Burrows, M. (2023) Home: Agendashift™, Agendashift. At: https://www.agendashift.com/ (Accessed: April 4, 2023).
134. Kniberg, H. and Ivarsson, A. (2012) Scaling at Spotify, Crisp. At: https://blog.crisp.se/wp-content/uploads/2012/11/SpotifyScaling.pdf (Accessed: April 5, 2023).
135. Ambler, S.W. and Lines, M. (2023) Disciplined Agile® Toolkit - Project Management Institute, PMI. At: https://www.pmi.org/disciplined-agile/ (Accessed: April 5, 2023).
136. Leffingwell, D. and Knaster, R. (2023) Safe 6.0 framework, Scaled Agile Framework. At: https://www.scaledagileframework.com/ (Accessed: April 5, 2023).
137. Sutherland, J. (2021) Scrum@Scale - the scaling framework created by dr. Jeff Sutherland, Scrum@Scale Framework. At: https://www.scrumatscale.com/ (Accessed: April 5, 2023).
138. Skelton, M. and Pais, M. (2023) Team topologies, Team Topologies. At: https://teamtopologies.com/ (Accessed: April 5, 2023).
139. Appelo, J. (2023) Versatile Organization Design, unFIX. At: https://unfix.com/ (Accessed: April 5, 2023).
140. Merel, P. (2023) Xscale Alliance, XSCALE Alliance. At: https://xscalealliance.org/#manifesto (Accessed: April 5, 2023).
141. Schwaber, K. et al. (2021) Online nexus guide, Scrum.org. At: https://www.scrum.org/resources/online-nexus-guide (Accessed: April 5, 2023).
142. Quartel, R. et al. (2024) FaST guide, Fluid Scaling Technology. At: https://www.fastagile.io/ (Accessed: December 6, 2023).
143. Ramos, C. and Pavlichenko, I. (2023) Creating agile organizations, Creating Agile Organizations. At: https://creatingagileorganizations.com/ (Accessed: April 15, 2023).
144. Larman, C. & Vodde, B. (2025) LeSS (Large-Scale Scrum) Framework. Available at: https://less.works/less/framework (Accessed: 8 June 2025)
145. Flight Levels GmbH (2025) Flight Levels Framework. Available at: https://www.flightlevels.io/what-is-flight-levels/ (Accessed: 8 June 2025).
146. Krivitsky, A. and Flemm, R. (2022) Org topologies, Org Topologies. At: https://www.orgtopologies.com/ (Accessed: April 4, 2023).
147. Singh, P. (2023) Scaling Simplified: A Practitioner’s Guide to Scaling Flow. Florida: Self-published. Available at: https://leanpub.com/scalingsimplified (Accessed: 8 June 2025)
148. Davies, Dan. (2025) The Unaccountability Machine: Why Big Systems Make Terrible Decisions—and How the World Lost Its Mind. London: Profile Books Ltd. (Paperback edition).
149. Stripe (2025) ‘Sir Jony Ive and Patrick Collison Fireside Chat | Stripe Sessions 2025’, YouTube video, 8 May. Available at: https://youtu.be/wLb9g_8r-mE?si=1rEJxU0sxixvblQ3&t=1390 (Accessed: 8 June 2025)

[a]Aquí yo anadiría una traducción mas literal. “Los profesionales y partes interesadas deben adoptar Scrum”….. cuando sea adecuado, [b]Me queda un poco rara esta frase. evolución continua, mantener y retirar productos o funcionalidades. [c]He simplificado un poco la frase. Ahora creo que se lee mejor. Revísalo p.f. [d]Perfecto [e]en España la expresión “nunca hecho antes " es común. Me gusta más que la propuesta. [f]Lo entiendo. Aún así, voy a intentar priorizar un lenguaje lo más neutral posible que no suene mal ni en España ni en Latam. A ver si podemos.