El origen de scrum: entre el conocimiento abierto y los modelos propietarios

Scrum es un marco de trabajo ágil muy popular en el desarrollo de software y la gestión ágil de proyectos. Pero, ¿de dónde procede? A diferencia de otros marcos y metodologías con autoría clara y definida, el origen de scrum puede resultar menos simple: ¿es un modelo con autoría y propiedad o una corriente emergente, colaborativa y compartida?

Y lo más importante, ¿puede la perspectiva su origen influir directamente en cómo se implementa? ¡Cuéntanos tu opinión en los comentarios!

Un breve recorrido por el origen de scrum

Scrum como conocimiento emergente (1980)

Scrum no surgió como un diseño teórico impuesto. Sus principios fundamentales comenzaron a manifestarse de forma orgánica en los años 80: ingenieros de empresas como 3M, Fuji, Honda y HP, insatisfechos con los modelos de producción en cascada, comenzaron a desarrollar patrones iterativos con solapamiento de fases.

En 1986 Hirotaka Takeuchi e Ikujiro Nonaka identificaron estos patrones emergentes en su artículo «The New New Product Development Game». Fueron ellos quienes bautizaron este enfoque como «scrum», utilizando la analogía de la formación de rugby. Es decir, identificaron, nombraron y dieron visibilidad a prácticas que ya estaban ocurriendo de forma espontánea.

La primera formalización (1990-1995)

En 1990 Peter DeGrace y Leslie Hulet Stahl publicaron Wicked Problems, Righteous Solutions. En él presentaron una propuesta de desarrollo iterativo basada en los principios identificados por Nonaka y Takeuchi, a la que también llamaron «scrum».

Sin embargo, esta propuesta no sería la más conocida: quienes dieron mayor difusión al término “scrum” fueron Jeff Sutherland y Ken Schwaber durante el congreso OOPSLA (Object-Oriented Programming, Systems, Languages & Applications).

Evolución colaborativa (1995-presente)

En 2001 Sutherland y Schwaber participaron en la creación del Manifiesto Ágil, que ayudó a consolidar muchos de los principios de Scrum dentro de un movimiento más amplio.

Y en 2010 Schwaber y Jeff Sutherland publicaron la primera versión oficial de la Guía Scrum, un documento que ha sido actualizado periódicamente y que representa la visión «oficial» del marco.

Sin embargo, Scrum ha evolucionado de forma continua también gracias a las ideas y prácticas aportadas por la comunidad ágil global. Por ejemplo:

• Al principio las iteraciones (sprints) podían durar desde 1-2 meses; a día de hoy suelen durar desde 1-2 semanas (adaptándose al contexto del equipo y la organización).
• Se incorporaron las reuniones retrospectivas para fomentar la mejora continua.
• Se añadió el refinamiento de la pila de producto (product backlog) como práctica recomendada.
• Se desarrollaron diversas técnicas para estimar (o no estimar) tareas e historias de usuario.
• Se integraron conceptos de tableros kanban para la gestión visual del trabajo, dando origen a prácticas híbridas.
• Se refinó el rol del Product Owner y su relación con los stakeholders.

Perspectivas sobre la propiedad de Scrum

Scrum como conocimiento propietario

Hay quien promueve una visión de Scrum como un marco definido con una guía oficial actualizada periódicamente por sus creadores. Esta perspectiva ofrece:

• Una definición acotada y estandarizada del marco, con roles, eventos y artefactos claramente definidos.
• Un punto de partida estructurado y común que busca mantener la integridad del marco.
• Actualizaciones controladas a través de revisiones periódicas de la Guía Scrum.

Scrum como conocimiento abierto

Otras organizaciones promueven una visión de Scrum como conocimiento común emergente, evolutivo y de dominio público. Esta perspectiva considera que:

• Scrum es un punto de partida, no un destino final o un conjunto rígido de reglas.
• La verdadera potencia de Scrum se desarrolla cuando los equipos aprenden a adaptar el marco técnico estándar a sus necesidades específicas.
• La rigidez conceptual podría limitar la innovación y adaptación necesarias en entornos complejos y cambiantes.
• El conocimiento sobre mejores prácticas pertenece a la comunidad, no a organizaciones específicas.

Impacto en la aplicación práctica

¿Puede el origen de scrum influir en cómo se implementa en una organización? Una empresa que considere Scrum como un modelo propietario probablemente tenga algunas de las siguientes limitaciones:

1. Rigidez operativa. Ceñirse estrictamente a la guía oficial puede generar miedo a “romper” Scrum y, por tanto, miedo a realizar cualquier cambio aunque el contexto lo pida. 
2. Parálisis de innovación. Se espera que todas las mejoras vengan de las actualizaciones oficiales de la guía. Por tanto, no se experimenta con adaptaciones para resolver problemas específicos.
3. Implementación superficial. La obsesión por seguir a rajatabla la guías oficial puede fomentar que se adopten solamente los elementos visibles (ceremonias, roles), pero no los principios subyacentes. Se le da más prioridad a “hacer scrum” que a “ser ágil”.

Quizás lo más adecuado sea buscar el equilibrio: usar la guía oficial como un marco de referencia valioso para comenzar, pero no cerrarse la posibilidad a adaptaciones o cambios dados por el contexto y las necesidades del entorno particular.

---

A diferencia de otros marcos y metodologías con autoría clara, Scrum emergió de forma colaborativa desde la base profesional, fue identificado y formalizado por profesionales y ha continuado evolucionando gracias a las aportaciones de una comunidad global.

Independientemente de la perspectiva adoptada, es importante mantener el espíritu de mejora continua y adaptación que constituye la esencia de Scrum. Después de todo, la agilidad que Scrum promueve debería aplicarse también a la forma en que entendemos y utilizamos el propio marco.

Referencias

1. DeGrace, P., & Stahl, L. H. (1990). Wicked Problems, Righteous Solutions: A Catalogue of Modern Software Engineering Paradigms. Prentice Hall.
2. Manifesto for Agile Software Development (2001). http://agilemanifesto.org/
3. Palacio Bañares, Juan (2023). «Origen de scrum más allá de los mitos», Navegapolis.
4. Schwaber, K. (1995). «SCRUM Development Process». OOPSLA’95 Workshop on Business Object Design and Implementation.
5. Schwaber, K., & Sutherland, J. (2020). The Scrum Guide: The Definitive Guide to Scrum.
6. Sutherland, J. (2014). Scrum: The Art of Doing Twice the Work in Half the Time.
7. Takeuchi, H., & Nonaka, I. (1986). «The New New Product Development Game». Harvard Business Review, 64 (1), 137-146.