Según la guía de Scrum 2020 realizada por los creadores de Scrum (Ken Schwaber & Jeff Sutherland) tal como lo conocemos hoy, definen Scrum de la siguiente manera:
¿Qué es Scrum?
“Scrum es un marco de trabajo liviano que ayuda a la personas, equipos y organizaciones a generar valor a través de soluciones adaptativas para problemas complejos"
Muchas veces a Scrum, se le apoda el concepto de metodología Scrum. Pero debemos hacer diferencia entre el concepto de metodología y marco de trabajo (Framework).
El concepto de metodología hace referencia al conjunto de procedimientos racionales utilizados para alcanzar el objetivo o los objetivos que rige una serie de tareas que requieran habilidades y conocimientos. Es decir, en otras palabras, una metodología nos da mayor detalle sobre los pasos a seguir. En cambio, un marco de trabajo se define como un conjunto estandarizado de conceptos, prácticas y criterios para enfocar un tipo de problemática particular que sirve como referencia para enfrentar y resolver nuevos problemas de índole similar.
La teoría de Scrum se basa en la teoría de control de procesos empírica o empirismo y en el pensamiento Lean. El empirismo asegura que el conocimiento procede de la experiencia y de tomar decisiones basándose en lo que se conoce. Y el pensamiento Lean reduce el desperdicio y se enfoca en lo esencial.
El empirismo está compuesto por tres pilares que soportan su implementación, los cuales son los siguientes:
La transparencia implica dar visibilidad a todo lo que está pasando en el proyecto, mediante la visualización del flujo de trabajo que permitirá tomar decisiones correctas al equipo de trabajo, el hecho de no ocultar información al equipo de trabajo u otros interesados es la base para cimentar la “confianza” en el entorno del proyecto. La inspección se debe realizar de manera frecuente, nos sirve para identificar y corregir las variaciones no deseadas en el avance hacia un objetivo. Por último, la adaptación es el resultado, implica realizar ajustes que permitan mantener los objetivos alcanzables, es decir minimizar las desviaciones a través del “aprendizaje” y la “mejora continua”.
Origen de Scrum
Sobre los inicios de Scrum, este se remonta al año 1986. Este modelo fue identificado y definido por Ikujiro Nonaka e Hirotaka Takeuchi al analizar cómo desarrollaban los nuevos productos las principales empresas de manufactura tecnológica: Fuji-Xerox, Canon, Honda, Nec, Epson, Brother, 3M y Hewlett-Packard (Nonaka & Takeuchi, The New New Product Development Game, 1986). A través de entrevistas con miembros de la organización, desde el CEO hasta jóvenes ingenieros, se llegó a aprender que las empresas líderes muestran seis características en la gestión de sus procesos de desarrollo de nuevos productos:
Inestabilidad incorporada
Equipos de proyectos auto-organizados
Fases de desarrollo solapadas
"Aprendizaje múltiple"
Control sutil
Transferencia organizacional del aprendizaje.
Por lo que, el origen del nombre Scrum se debe a la comparación de cómo los equipos de rugby se forman y avanzan de forma auto-organizada por el campo de juego.
Continuando con los orígenes de Scrum, es sumamente importante diferenciar el origen de Scrum con relación al marco técnico del Scrum. El Scrum técnico es el marco de reglas para el desarrollo de software, basado en los principios de scrum. Este marco técnico de Scrum nos permite iniciarnos en el mundo de la gestión ágil de proyecto.
Origen del Marco de Reglas de Scrum
Ken Schwaber y Jeff Sutherland copresentaron Scrum por primera vez en la Conferencia OOPSLA en 1995. Básicamente, presentaron un conjunto de reglas y de buenas prácticas enfocadas en el desarrollo de software, en donde se publicó la primera definición formal de Scrum.
Por lo que, el proceso de Scrum referente al marco técnico de Scrum está compuesto por: roles, eventos y artefactos.
Roles
En relación con los roles cabe aclarar que un equipo Scrum está compuesto por los Developers, Product Owner, y Scrum Master. En los equipos Scrum no existe relación de jerarquía entre los roles, por lo que es un equipo que trabaja de forma cohesionada que se enfoca en cumplir el objetivo del producto.
El éxito de una implementación del proceso de Scrum dependerá de una serie de características claves que necesita el equipo Scrum como la colaboración, autogestión y la multifuncionalidad para que cumplan con la responsabilidad de entregar valor continuamente al cliente en entornos que evolucionan rápidamente. Por lo que, en entornos cambiantes, se requiere personas motivadas que sean capaces de adaptarse al cambio de forma continua para el éxito de Scrum.
Developers: Los Desarrolladores son los responsables de realizar el trabajo durante el Sprint (Iteración) para entregar valor al cliente, es decir, ellos son los responsables de cumplir el objetivo de Sprint a través de la entrega de incrementos. Este es un equipo compuesto por una cantidad recomendada entre 3 a 9 personas, donde no se cuenta ni al Product Owner, y tampoco al Scrum Master. El número de personas recomendado busca mantener una comunicación eficaz, eficiente y directa entre los Desarrolladores, más allá de esa cantidad, se generan e intensifican los roces entre las personas del equipo.
Es ideal que los integrantes del equipo sean multifuncionales, pero muchas veces en los proyectos puede haber profesionales que son especialistas en algún área o proceso específico. Pero, eso no significa que la responsabilidad del logro del Sprint sea individual por cada miembro, sino que es una responsabilidad compartida por todos los desarrolladores.
Product Owner: Es el propietario del producto, el cual tiene la responsabilidad de aumentar el valor del producto. El Product Owner es un rol que recae en una única persona, donde recopila las necesidades, los problemas y expectativas de uno o varios cliente. Esta persona representa al cliente, y debe tener el conocimiento del negocio, mercado, industria, entre otros. Y a su vez, las atribuciones necesarias para tomar decisiones en el proyecto por parte de la alta dirección.
Scrum Master: Es el responsable de que se cumpla el marco de reglas de Scrum. El Scrum Master ayuda a que todo el equipo Scrum y la organización entiendan la teoría y prácticas de Scrum. El liderazgo de un Scrum Master es de forma servicial que apoya al Product Owner, Desarrolladores y a la organización en general de forma continua.
Por otro lado, el Scrum Master tiene la responsabilidad de moderar las reuniones diarias de Scrum, gestionar los problemas que se puedan producir en el equipo, y resolver los impedimentos que pudiesen ocurrir en las reuniones diarias de Scrum para evitar desviaciones en el Sprint.
Artefactos
Los artefactos de Scrum permiten aumentar la transparencia de la información clave del proyecto al equipo Scrum y a todos los interesados del proyecto. Los artefactos de Scrum son 3, y estos son: Product Backlog, Sprint Backlog e Incremento.
Product Backlog: El Product Backlog es la lista priorizada y ordenada de lo que se necesita para mejorar el producto a través de los Sprints. Representa todo aquello que esperan clientes, usuarios y otras partes interesadas para cumplir con el objetivo del producto en base a su visión compartida. Este es un artefacto que está en continua evolución y que facilita la comunicación de información al equipo Scrum y otros interesados de la organización.
El Product Owner es el responsable del Product Backlog, el cual por lo general se representa a través de las Historias de Usuario que se desarrollan en conjunto con los Desarrolladores para estimar los tamaños de estas, prioridades y orden en el evento de la Planificación del Sprint o en instancias de refinamiento del Backlog que no ocupen más del 10% de la capacidad del equipo Scrum.
Sprint Backlog: El Sprint Backlog es la lista de todas las tareas que se requieren construir para cumplir con las Historias de Usuario seleccionadas en un Sprint. Este artefacto permite seguir en tiempo real el trabajo que realizan los Desarrolladores durante el Sprint para lograr el objetivo del Sprint.
Los Desarrolladores son los responsables del Sprint Backlog, el cual permite monitorizar la planificación del Sprint y la monitorización del avance del trabajo en el evento del Scrum Diario.
Incremento: El incremento es la parte del producto terminada en un Sprint, y que ya está condiciones de ser entregada al cliente. Cabe destacar, que este entregable debe estar terminado, probado, operativo e integrado a los incrementos anteriores.
La Definición de Terminado (DoD) crea la transparencia para un entendimiento común de que el incremento cumple con su definición para poder ser entregado. En el caso de que un elemento no cumpla con esta la definición, no se puede presentar en el Sprint Review, y vuelve al Product Backlog para poder ser considerado más adelante.
Eventos
Los eventos de Scrum oficialmente son 5, donde se considera el Sprint como el evento contenedor, y 4 eventos contenidos que son: Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective.
Sprint: Los Sprints son el corazón de Scrum en donde se desarrolla la generación de valor al cliente. Los Sprints son iteraciones de duración fijas que pueden durar cómo mínimo 1 semana y máximo 4 semanas donde se construye el incremento del producto.
Los Sprints permiten aumentar la transparencia a través de sus reuniones y el uso de artefactos como fuente de comunicación al equipo Scrum y a los interesados del proyecto. Con ello, se busca minimizar la necesidad de reuniones “extras” que no aporten al valor al proyecto. Por otro lado, los Sprints permiten manejar la previsibilidad mediante la inspección y adaptación del progreso sobre el objetivo del producto cómo máximo en una duración de 4 semanas.
La importancia de que los Sprint sean de duraciones fijas y constantes, también llamado “Timeboxing” es que generan mayores ciclos de aprendizajes sobre el producto, y así aumentar la generación de valor sobre el producto. Por lo que cada Sprint puede considerarse como un pequeño proyecto.
Sprint Planning: Esta reunión es el punto de partida para el comienzo del Sprint, donde se toman las necesidades, problemas y expectativas sobre el negocio del cliente y se determinan cuáles y cómo serán las funcionalidades que tendrá el producto al entregar el incremento al final del Sprint.
La planificación del Sprint tiene el objetivo de dar respuesta a las siguientes preguntas:
¿Por qué es valioso este Sprint?
El Product Owner expone de qué manera el producto puede incrementar su valor y utilidad en el sprint que se realizará. En este evento el Product Owner presenta los elementos más importante del Product Backlog mediante las Historias de Usuario. Después de esto, todo el equipo Scrum colabora para definir el objetivo del Sprint, que pudiese ser un lema que identifique el objetivo principal.
¿Qué se puede hacer en este Sprint?
Una vez expuesto cómo se incrementará el valor esperado por el Product Owner, los Desarrolladores seleccionan los elementos del Product Backlog que se van a realizar. En esta instancia también se genera una conversación entre Desarrolladores y el Product Owner con el objetivo de refinar los elementos del Product Backlog que requieran una mayor comprensión.
Cuántos elementos del Product Backlog que se puedan seleccionar dependerá del desempeño de Sprint anteriores que estarán basados en la velocidad o rendimiento del equipo para estimar la cantidad de trabajo a realizar, o cuántas Historias de Usuario se podrían seleccionar en un Sprint.
¿Cómo se realizará el trabajo elegido?
Los desarrolladores descomponen los elementos seleccionados del Product Backlog en elementos de trabajos más pequeños que se pueden realizar en un día de trabajo o menos, es decir, las Historias de Usuario se descomponen en tareas que se deben realizar máximo en una jornada laboral. Cabe destacar, que esta instancia es exclusiva de los Desarrolladores.
La tareas que obtiene el equipo de desarrollo, el objetivo del Sprint, más el plan para entregarlos conforman el Sprint Backlog.
La Planificación del Sprint tiene una duración máxima de 8 horas para un Sprint de 4 semanas, y para Sprints más cortos este evento tiene una duración menor.
Daily Scrum: El Scrum Diario es un evento de 15 minutos, el cual se realiza de pie. En este evento los desarrolladores sincronizan el trabajo y establecen el plan para las 24 horas siguientes.
Este es un evento en donde asisten todos los desarrolladores, y pueden asistir otros interesados en modalidad de oyente. En este reunión cada integrante del equipo de desarrollo responde las tres siguientes preguntas:
¿Qué hice ayer?
¿Hubo algún impedimento?
¿Qué haré hoy?
Las Daily Scrum permiten una mejora en la comunicación, identifican impedimentos y permiten una mejor toma de decisiones. Aunque, cabe destacar que durante el día el equipo de Desarrolladores se puede reunir para planificar con mayor detalle el trabajo del Sprint.
Sprint Review: Este evento se realiza al final del Sprint con el objetivo de inspeccionar el incremento entregado. El equipo Scrum presenta los resultados del Sprint a los interesados del proyecto para validar el cumplimiento del objetivo del Sprint.
El principal valor que genera la Revisión del Sprint es el feedback que se recibe por parte de los interesados del proyecto, ya que esto permite futuras adaptaciones a la planificación de los requisitos del proyecto y mejorar la visión del producto.
La Revisión del Sprint es el penúltimo evento del Sprint y tiene un límite de tiempo de máximo 4 horas para un Sprint de 4 semanas, y para Sprints más cortos este evento tiene una duración menor.
Sprint Retrospective: Este evento tiene el objetivo de planificar el aumento de la calidad y la efectividad del trabajo. El equipo Scrum inspecciona el último Sprint en relación con las personas, interacciones, procesos y herramientas y de acuerdo con su Definición de Terminado (DoD).
La esencia de inspeccionar todo lo que sucede en el Sprint, es poder adaptar las acciones de mejoras para los próximos Sprints. Por lo general, se responden 3 preguntas en el evento de Retrospectiva, las cuales son:
¿Qué se hizo bien?
¿Qué falto hacer?
¿Cuáles son las mejoras a adaptar?
La Sprint Retrospective concluye el Sprint. Tiene un tiempo limitado a máximo tres horas para un Sprint de 4 semanas. Para Sprints más cortos, este evento tiene una duración menor.
Si deseas partir con un breve curso introductorio a los fundamentos de la Agilidad y el framework Scrum.
Pincha en el siguiente enlace -->
Saludos Agilista, 😉