Fundamentos de Scrum Framework: Pilares y Valores
- Agilidad Empresarial
- Artículo, Infografía
Alonso Alvarez
Este artículo cierra la serie en la que revisamos los fundamentos de Scrum complementados con infografías que los explican. Puede sonar raro terminar por la visión general, pero ahora que tenemos los detalles, podemos alejarnos y ver el conjunto con perspectiva.
Autores: Alonso Álvarez y Patricia Parreira.
Scrum nace a mediados de los años 90 para solucionar un problema muy concreto: ¿Cómo desarrollar software de forma efectiva y eficiente con equipos pequeños?
Con el tiempo, Scrum ha evolucionado mucho y en varias líneas: se ha convertido en uno de los componentes fundacionales del movimiento de la Agilidad, y ha inspirado (para bien o para mal) a muchos otros marcos ágiles; ha incorporado muchos elementos procedentes de otros marcos; se ha abierto a otros contextos y hace mucho que se aplica fuera del software. También ha dejado caer muchas cosas de su definición oficial, que es cada día más reducida (como las tres preguntas de la Daily, que entraron en una edición y salieron en la siguiente).
Los creadores de Scrum, Shutherland y Schwaber, se inspiraron en varias fuentes, empezando por el artículo “The New New Development Game” de los profesores Takeuchi y Nonaka para hacer una adaptación de la filosofía Lean originada en Toyota, combinada con su propia experiencia personal.
NOTA: “The new new development game” es también la inspiración para el nombre de Scrum. En el artículo original se usaba la metáfora del rugby para explicar cómo se “pasa la pelota” (el trabajo) entre los miembros del equipo. Sutherland y Schwaber eligieron “Scrum” (que en inglés es “Melee”), una jugada del rugby en la que el equipo empuja al unísono para superar un obstáculo, el equipo contrario.
Scrum comenzó en la práctica en 1993 (según Shutherland, es cuando arrancó el primer Sprint) y luego se presentó en una conferencia y empezaron a aparecer artículos y libros. En 2001, Shutherland y Schwaber participaron en la elaboración de Manifiesto Ágil y desde entonces su influencia no ha dejado de crecer. Se estima que más del 80% de las organizaciones que aplican agilidad usan Scrum, más otro porcentaje adicional que usan híbridos o variantes.
Scrum es un marco de trabajo
Aunque es frecuente escuchar la expresión “metodología Ágil” para hablar de Scrum, lo primero que hay que dejar muy claro es que Scrum no es una metodología. Sus autores lo definen como un “marco de trabajo” (framework) ligero. No hay más que ver la Guía Scrum para darse cuenta de que estamos hablando de algo muy poco prescriptivo: 14 páginas bastan para contar todo lo que hay que saber de Scrum (14 en la versión inglesa original, 17 en la española, incluyendo portada, índice y agradecimientos). Es más, esa Guía siempre ha sido corta, e incluso se ha reducido con el tiempo desde las 21 páginas de su versión inicial de 2010.
Scrum se define como “un marco ligero que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptables para problemas complejos”. Eso no quiere decir que su aplicación sea simple: tradicionalmente se ha comparado a Scrum con el ajedrez, donde unas reglas sencillas dan lugar a un juego con muchas variantes complejas.
Esto justifica la cantidad de literatura que hay alrededor de Scrum: la enorme variabilidad de situaciones en su aplicación, el gran abanico de posibles situaciones que se pueden dar en un equipo, hace que la experiencia de llevar Scrum a la práctica sea un complemento que enriquece lo simple de su diseño.
Los fundamentos de Scrum
Los aspectos más visibles y conocidos de Scrum son sus eventos, responsabilidades y artefactos, pero la única forma de entender de qué estamos hablando es conocer en qué se basa: sus pilares y valores.
Scrum se basa en el empirismo y el pensamiento Lean. El empirismo afirma que el conocimiento proviene de la experiencia y la toma de decisiones basadas en lo que se observa. El pensamiento Lean reduce los desperdicios y se centra en lo esencial. (Guía Scrum, 2020)
El empirismo, la toma de decisiones a partir de datos y evidencias y no de opiniones y percepciones personales, es básico. Esto quiere decir que la aplicación efectiva de Scrum requiere obtener y analizar esos datos. Scrum no define oficialmente métricas o indicadores, pero deja bien claro que el empirismo es la base sobre la que se construye todo lo demás.
Los pilares
Y ese “todo lo demás” es, en primer lugar, los pilares sobre los que se asienta Scrum. Son tres:
- Transparencia. El trabajo en un equipo pequeño no puede tener zonas oscuras o privadas. No es posible tomar decisiones importantes sin contar con toda la información. No hay trabajo efectivo si la información se compartimenta, y, sobre todo, la falta de transparencia impide la inspección y adaptación, los otros dos pilares de Scrum.
- Inspección. El trabajo con Scrum, su avance y resultados deben ser inspeccionados con frecuencia para detectar y anticiparse a dificultades, e identificar aspectos de mejora. Los eventos de Scrum están diseñados para ayudar la inspección. Este pilar va siempre de la mano del siguiente, la adaptación.
- Adaptación. No tiene sentido sin la inspección. Recordemos que la agilidad nació sobre todo con la idea de potenciar la capacidad de adaptación en entornos complejos y sujetos a cambio. Si durante el trabajo se detectan desviaciones, o si los resultados se alejan de lo esperado, lo que nos dicta el sentido común es introducir cambios, no perseverar ciegamente. El cambio, la adaptación, debe hacerse lo antes posible para mitigar el efecto de la desviación. Sin el conocimiento previo (inspección) la adaptación no es posible. Tampoco lo es si las personas involucradas no tienen capacidad para tomar sus propias decisiones, de ahí la importancia del empoderamiento y autogestión.
Para acabar de ligar este pilar con el anterior, se dice que un equipo Scrum se adapta cuando aprende algo nuevo por medio del proceso de inspección.
Los valores
El complemento de los pilares de Scrum son sus valores. En este caso son cinco:
- Compromiso. El equipo Scrum se define como “autogestionado”, con autonomía y una gran capacidad para tomar sus propias decisiones. Eso es un verdadero superpoder, pero ya sabemos que “un gran superpoder conlleva una gran responsabilidad”, en este caso es el compromiso de alcanzar los objetivos planteados y apoyarse mutuamente para lograrlo. Todos los esfuerzos del equipo deben encaminarse hacia el logro de esos objetivos.
- Enfoque (o foco). El equipo debe poner toda su atención en avanzar hacia sus objetivos. Eso supone que el foco principal de su actividad debe estar puesto aquí. Evitar distracciones y desviaciones se convierte así en un elemento fundamental del trabajo de Scrum.
- Apertura. El trabajo del equipo está sujeto, como todo lo demás, a inspección y adaptación. Es no es posible si hay una visión rígida e inflexible. Por ello es tan importante que equipo y sus stakeholders estén abiertos a otras posibilidades sobre el trabajo (el cómo y el qué).
- Respeto. Se trata de algo básico: las personas del equipo se respetan entre sí, y son respetadas por el resto de personas de su entorno.
- Coraje. Las personas del equipo tienen el valor (y se sienten con la capacidad de) dar un paso adelante y hacer lo correcto. Este valor implica la existencia de una “seguridad psicológica”: no hay miedo a expresar puntos de vista y señalar aquello que no está bien.
Los valores y pilares son elementos básicos en Scrum, mucho más importantes que los eventos, las responsabilidades o los artefactos. Ya que hacer Scrum sin aplicar estos valores, es hacerlo de una forma hueca y mecánica. Scrum sin valores, es una colección de reuniones y responsabilidades cuyo sentido se escapa a quienes participan en ellas.
Pilares y valores en la práctica
¿Todo esto suena muy abstracto? En realidad, todo ello tiene aplicación directa en el día a día de un equipo Scrum.
Si revisamos los eventos de Scrum, veremos la huella de estos pilares y valores en todos ellos. Para empezar, el Sprint es una aproximación cíclica que promueve la inspección y adaptación de forma regular por el mero hecho de generar y reflexionar sobre los resultados a intervalos regulares.
- En la planificación se introducen cambios y ajustes para alinear el trabajo con el Objetivo del Producto. La Planificación es un momento donde se ejerce el compromiso, pero también tiene mucho que ver el foco o el coraje.
- Durante el Sprint, las personas trabajan dentro de un entorno de respeto, poniendo foco en el trabajo que les permite cumplir con sus compromisos, con apertura a nuevas ideas y posibilidades y el coraje para llevarlas a la práctica.
- La reunión diaria o Daily es un evento donde se hace Inspección y Adaptación para detectar y corregir desalineamientos del Objetivo del Sprint. Es preciso poner foco en lo importante para cumplir los compromisos y tener el coraje para cambiar el rumbo si los objetivos están en riesgo, y para hacer ver los impedimentos detectados.
- La Review es un evento donde, sobre todo, se inspeccionan los resultados, se recoge feedback y se plantean acciones de adaptación que se materializan en el siguiente Sprint. Es un momento para la apertura a la hora de hablar equipo y stakeholders de dificultades y cambios. También es un momento donde señalar con coraje las desviaciones, y mostrar el compromiso del equipo con los objetivos.
- La Retrospectiva es otro evento de Inspección y Adaptación sobre el funcionamiento del equipo. Al igual que en la Review, se ejerce la apertura a distintas ideas y opciones. Además, en un entorno de respeto, se debe tener el coraje de señalar aquello que no funciona para comprometerse a solucionarlo, abriéndose a nuevas ideas.
Todos estos eventos son oportunidades de aprendizaje. Todos ellos requieren transparencia para poder ser llevados a cabo de forma eficaz. Ninguno de ellos se entiende sin aplicar empirismo, es decir, sin usar datos y evidencias a la hora de tomar decisiones.
Si miramos a las responsabilidades, vemos que todas ellas requieren ejercer los valores para alcanzar los objetivos: compromiso compartido por todos, foco en el trabajo, respeto mutuo, abrirse a nuevas ideas y posibilidades, y coraje de no dejar pasar oportunidades de hacer las preguntas necesarias e introducir cambios por medio de la inspección y adaptación. Y todo ello bajo la premisa de transparencia ya que sin ella es imposible un verdadero trabajo de equipo.
Scrum es una más de las distintas implementaciones de la filosofía ágil. Es la más popular, pero hay muchas otras alternativas. Scrum no es una solución universal para los problemas de una organización o un equipo, pero si es una forma muy efectiva de hacerlos aflorar y ofrece herramientas para que el equipo los resuelva.
De la misma forma que la agilidad es la aproximación más indicada en cierto tipo de contextos, Scrum es el marco más indicado en cierto tipo de problemas y organizaciones. En otras ocasiones será mejor usar otros marcos y técnicas. Implantar rígidamente Scrum sin entender qué problema tiene el equipo puede dar lugar a frustraciones y disfunciones. Aplicar Scrum sin atender a sus fundamentos, lo convierte en una secuencia vacía y sin sentido de reuniones que rápidamente se pervierten.
Scrum permite acomodar variantes y mejoras, pero no se debe romper con los requisitos (muy) mínimos que establece la Guía. ¿”Weeklies”, Revisiones sin feedback, dailies para hacer reporting, Sprints sin objetivo, PO y SM en la misma persona, sin retrospectivas o muy de vez en cuando, PO ausente…? Es sorprende la variedad de disfunciones que pueden introducirse en un marco tan sencillo como es Scrum.
Cada elemento tiene un propósito específico y es esencial para desarrollar productos complejos. No hay nada superfluo, no lo olvidemos.
Scrum se puede definir como una forma de poner en práctica el empirismo, la verdadera gestión científica del trabajo. Cuando se aplica con rigor, siendo conscientes de lo que implican valores y principios, y respetando el espíritu de Scrum, los resultados son sorprendentes. La popularidad de Scrum no es casual: no es una solución mágica, pero si una buena manera de descubrir nuestros problemas y darnos la capacidad de solucionarlos, en lugar de que alguien lo haga por nosotros.
¿Quieres conocer más prácticas Scrum?
Sobre el autor
