.png?locale=es "Visión Scrum")
¿Cuáles son las características de Scrum, sus ventajas y desventajas?
"Scrum es un marco de trabajo liviano que ayuda a las personas, equipos y organizaciones a generar valor a través de soluciones adaptativas para problemas complejos" - Guía Oficial de Scrum
Más allá de una metodología
El marco de trabajo Scrum ha tenido un impacto significativo en la creación ágil de productos durante las últimas dos décadas, principalmente en el desarrollo de software, y su influencia se ha extendido a numerosas industrias. Este enfoque ofrece valor temprano y adaptabilidad en escenarios complejos, donde los enfoques predictivos a menudo fallan.
Contrario a la creencia común, Scrum no es una metodología, sino un diseño deliberadamente incompleto y minimalista. Esta característica implica que cualquier individuo, equipo u organización que busque mejorar la calidad de los productos a través de Scrum necesitará complementarlo con técnicas y prácticas específicas de su campo. En esencia, Scrum proporciona el qué pero no el cómo, y el Scrum Master es la persona encargada de garantizar su correcta implementación.
El marco de trabajo Scrum se ha vuelto una herramienta esencial para el trabajo en equipo, gracias a su énfasis en equipos multifuncionales y autogestionados. Estos equipos no solo producen resultados, sino que también evalúan constantemente su forma de trabajar.
Toda la base de la práctica de Scrum se puede encontrar en la Guía oficial de Scrum cuyos autores son Ken Schwaber y Jeff Sutherland. La guía oficial de Scrum en español nos brinda una explicación para poder comprender que sí es Scrum y que no es, qué es y qué hace un Scrum Master, un Product Owner y un Desarrollador.
Scrum vs. Waterfall: un cambio de paradigma en la gestión de proyectos
A diferencia del modelo secuencial Waterfall o de cascada de gestión de proyectos, Scrum no es una metodología con procesos, subprocesos, inputs y outputs. Tampoco es un método para hacer seguimiento detallado de las tareas individuales de los miembros del equipo Scrum. Por ello, Scrum no funciona como enfoque tradicional para gestionar proyectos ni equipos.
En Scrum no hay gerentes que dirijan y controlen el trabajo que realizan las personas del equipo. Específicamente en este punto, Scrum se basa en la capacidad de autogestión del equipo, quien tiene completa autonomía para elegir en qué trabajar, cómo hacerlo y quiénes lo hacen dentro del equipo.
Este marco ofrece es una manera de trabajar en equipo muy útil a la hora de desarrollar productos en contextos complejos. Ya sea para una campaña de marketing, la creación de una identidad corporativa, el desarrollo de una solución digital o la construcción de una aplicación móvil, Scrum se destaca por su flexibilidad. La principal ventaja que ofrece Scrum es su falta de rigidez, lo que permite aplicarlo en entornos complejos con requerimientos cambiantes.
La "desventaja" es que no ofrece una guía paso a paso porque el sentido de su uso está en aplicarlo en contextos inciertos como aquellos que involucran la interacción permanente con lo usuarios. Es el típico ejemplo de los productos digitales, donde no solo se debe construir un producto, sino también descubrir en paralelo qué producto construir, mediante el uso de las técnicas adecuadas de Product Discovery.
Otra ventaja de usar Scrum es que puedas ver el producto funcionando a medida que se construye, crece y evoluciona. De esta manera lo podrás inspeccionar y adaptar tanto como consideres necesario.
Si quieres aprender más sobre Scrum, puedes tomar el siguiente curso gratis en español:
Decidiendo la aplicación de Scrum: ¿Es lo adecuado para ti?
Para responder a la pregunta de si Scrum es la elección correcta para tu equipo, podemos referirnos al marco Cynefin de terminología actualizada y originalmente publicado en 2003 por C. F. Kurtz y D. J. Snowden (The new dynamics of strategy: Sense-making in a complex and complicated world). Este marco describe de manera clara y concisa las diferentes situaciones en las que te puedes encontrar y cómo responder de manera más eficiente a cada una de ellas al tomar decisiones.
Explorando el Marco Cynefin: los dominios de complejidad
Cynefin plantea 5 dominios de complejidad diferentes: claro (simple), complicado, complejo, caótico y confundido. El dominio complejo se caracteriza por la incertidumbre: no puedes saber con anticipación si una solución determinada será efectiva y no puedes recurrir a "mejores prácticas" preexistentes. Simplemente, no sabes con anticipación si una determinada solución va a funcionar.
Para poder operar en este tipo de espacio necesitas tener la posibilidad de la experimentación, el aprendizaje y que los errores sean de bajo impacto. Aquí es donde Scrum brilla, ya que te permite no solo construir un producto, sino también descubrir cuál es ese producto que necesitas construir.
Tres preguntas claves
Al decidir si usar Scrum, puedes considerar tres preguntas clave:
- ¿Cuánta confianza tienes de que el producto que el producto que planeas resolverá la necesidad que buscas resolver?
- ¿Cuánta seguridad tienes que la tecnología elegida resolverá la necesidad que pretendes resolver?
- ¿Cuál es la naturaleza del trabajo del equipo: principalmente mecánico o principalmente cognitivo?
Si no estás seguro de que el producto o la tecnología resolverán el problema, aunque conozcas el alcance del producto en detalle, es posible que no sepas qué construir ni cómo utilizar la tecnología para satisfacer esa necesidad. En este caso, tiene sentido utilizar Scrum.
Por el contrario, si tienes seguridad de que el producto a construir y la tecnología a emplear resolverán el problema que se pretende resolver, entonces, no tiene tanto sentido utilizar Scrum.
Si te interesa saber más sobre los otros dominios del Marco Cynefin, que no es tan conocido como se merece por la claridad que nos aporta, puedes leer este artículo del Modelo Cynefin.
Al no ser una metodología, Scrum no es adecuado para trabajos de naturaleza mecánica o física, pero puede ser muy efectivo para tareas cognitivas o creativas, especialmente cuando la predicción es inviable o incierta. Esta es una de las diferencias entre los procesos de seguimiento y control predictivo y empírico.
¿Cómo es un Equipo Scrum?
"La unidad fundamental de Scrum es un pequeño equipo de personas, un Equipo Scrum. El Equipo Scrum consta de un Scrum Master, un Scrum Product Owner y Desarrolladores." - Guía Oficial de Scrum
Los integrantes
Dentro del Equipo Scrum puedes ocupar uno de tres roles: Desarrollador, Scrum Product Owner o Scrum Master. Es importante notar que la guía oficial de Scrum, escrita por Ken Schwaber y Jeff Sutherland, no hay "roles" sino "responsabilidades". Además, a diferencia de las estructuras tradicionales de trabajo, una de las características de los Equipos en Scrum es no reconocer ningún tipo de jerarquía dentro del equipo, sub-equipos ni otros miembros que el Scrum Master, Product Owner y Desarrolladores.
Tamaño del Equipo
El tamaño típico de un Equipo Scrum no supera las 10 personas. Esto se debe a que equipos más grandes pueden enfrentar dificultades para tomar decisiones y cambiar de dirección rápidamente. No obstante, el equipo no debe ser demasiado pequeño; debe ser lo suficientemente grande como para producir un valor significativo en cada iteración.
Cuando se trabaja a gran escala, los equipos grandes se dividen en múltiples Equipos Scrum, todos trabajando en un solo producto con un único Product Owner y compartiendo un único objetivo de producto y Product Backlog. En el caso que desees profundizar en el uso de Scrum a gran escala puedes investigar acerca de LeSS (Large Scale Scrum).
Mutifuncionalidad
Se espera que dentro de tu Equipo Scrum cuenten con todas las habilidades necesarias para poder entregar Incrementos terminados y usables al final de cada Sprint. A esto se lo conoce como equipos multifuncionales e implica que no necesites de la intervención de personas externas a tu equipo.
Tanto si ocupas el lugar de Scrum Master o de Scrum Product Owner podrías ocupar en paralelo el rol de Desarrollador, aunque no es requerido. Pero cuidado, no debes ocupar el lugar de Scrum Product Owner y el de Scrum Master simultáneamente dado que ambos funcionan por oposición de intereses.
¿Qué hace el Scrum Master?
"El Scrum Master es responsable de establecer Scrum como se define en la Guía oficial de Scrum. Logra esto ayudando a todos a comprender la teoría y la práctica de Scrum, tanto dentro del Equipo Scrum como de la organización" - Guía Oficial de Scrum
Siguiendo la guía oficial de Scrum, la responsabilidad del Scrum Master se centra en el proceso de trabajo y en la mejora continua. El objetivo principal del Scrum Master es fomentar el desarrollo del Equipo Scrum, llevándolo a ser competente en el uso de Scrum, autogestionado y multifuncional.
En la práctica, puede suceder que al Scrum Master también se lo llame Facilitador o Coach porque su responsabilidad consiste en asegurar que se siga Scrum sin interferir directamente en el desarrollo del Incremento. El Equipo Scrum es quien elige la forma de trabajo que más prefiera, siempre que se cumplan las pautas básicas de Scrum, por ello mientras lo hagan no existe una forma “errónea” de trabajar.
Dado que el rol de Scrum Master también incluye asegurar desde su lugar que el desarrollo del producto tenga la mayor probabilidad de ser completado de forma exitosa, un buen Scrum Master pone en práctica el liderazgo servicial, dando servicio de cerca al Equipo Scrum, al Scrum Product Owner y a la organización.
El Scrum Master y la autogestión del Equipo
Siguiendo la versión en español de la Guía oficial de Scrum, otra de las responsabilidades del Scrum Master es entrenar a los miembros del equipo en autogestión y multifuncionalidad.
Entre sus responsabilidades, también ayuda al equipo a concentrarse en crear Incrementos de alto valor que cumplan con la Definición de Terminado; canaliza la eliminación de impedimentos para el progreso del equipo, y se ocupa de que todos los eventos de Scrum tengan lugar y sean positivos, productivos y se mantengan dentro del marco de tiempo.
La relación del Scrum Master con el Product Owner
El Scrum Master ayuda al Product Owner a encontrar técnicas para la definición de los objetivos del producto y la gestión del Product Backlog.
También asiste al Equipo Scrum en dar importancia a la necesidad de contar con Ítems del Product Backlog claros y concisos, contribuye con el Product Owner a establecer una planificación de producto empírica para un entorno complejo, y facilita la colaboración de los stakeholders según se solicite o necesite.
El Scrum Master también asiste a su organización
Un buen Scrum Master acompaña a la organización en la adopción de Scrum a través de su liderazgo, la capacitación y coaching a la organización. El Scrum Master también planifica y asesora en implementaciones y los beneficios de Scrum dentro de la organización.
Por último, también brinda ayuda a los stakeholders a comprender y aplicar un enfoque empírico para el trabajo complejo y elimina barreras entre stakeholders y Equipos Scrum para evitar las fallas de comunicación.
El Product Owner y la creación de valor
"El Scrum Product Owner es responsable de maximizar el valor del producto resultante del trabajo del Equipo Scrum" - Guía Oficial de Scrum
Dentro del Equipo Scrum, el Product Owner es el responsable del producto desde el punto de vista de negocio. Aunque puede recibir ayuda de otros, este trabajo no lo realiza un grupo de personas, sino solo el Scrum Product Owner.
Los objetivos y la visión del producto
Para desempeñarse como un Product Owner eficaz, es esencial comunicar de manera clara los objetivos del producto. En el contexto colaborativo de Scrum, estos objetivos idealmente surgirán de una creación conjunta en torno a una visión de producto, en lugar de ser impuestos desde arriba.
La visión de producto establece el escenario futuro a lograr con el producto. Esta visión, generalmente utópica e inspiradora, define la dirección a seguir, pero difícilmente ayude a medir el progreso. Aunque la visión de producto no es parte del marco de Scrum, es un elemento crucial para el Scrum Product Owner.
Partiendo de esta visión, el Product Owner establece la estrategia para la creación del producto. Esta estrategia traza los distintos objetivos del producto que se deben alcanzar. Estos Objetivos de Producto sí forman parte integral del marco de Scrum.
Los Objetivos de Producto pueden considerarse como hitos de negocio concretos y medibles que, una vez alcanzados, determinan la estrategia del producto en relación con la visión. Tanto la visión, la estrategia y los objetivos surgen de un trabajo colaborativo que involucra a los stakeholders y miembros del Equipo Scrum.
Garantizar el entendimiento y visibilidad del Product Backlog
Una de las responsabilidades esenciales del Scrum Product Owner es garantizar que todos los miembros del equipo tengan una comprensión clara del Product Backlog. Esto implica mantener un diálogo constante y asegurarse, durante el Sprint, de que el Incremento de producto cumpla con las expectativas establecidas, sin necesidad de detallar exhaustivamente los requerimientos.
Para lograr una comprensión unificada del Product Backlog, el Scrum Product Owner se mantiene en comunicación constante con el resto del equipo a lo largo de todo el ciclo. Ya sea que el equipo trabaje de forma remota o presencial, el Product Owner está siempre accesible y disponible.
Al mismo tiempo, el Product Owner coordina y facilita actividades que llamaremos de Refinamiento donde los developers se involucran activamente, y convocan a stakeholders y usuarios, para la definición del producto a mediano plazo y en detalle a corto plazo.
Un buen Scrum Product Owner asegura que el Product Backlog sea accesible y conocido por todos los involucrados, ya sean miembros del Equipo Scrum, stakeholders o cualquier persona en la organización. Independientemente de la herramienta utilizada para almacenar el Product Backlog -como Excel, Google Spreadsheets, Trello, Monday, Jira, entre otras-, el Product Owner debe garantizar que no existan restricciones de acceso.
Fundamentos en Product Ownership
El Ordenamiento de los Product Backlog Items
El Product Backlog se encuentra meticulosamente ordenado, especialmente en el caso de los elementos prioritarios que se convertirán en Incrementos a corto plazo.
Es importante tener en cuenta que no es necesario invertir una gran precisión en el orden de los Product Backlog Items (PBIs) de menor prioridad, que se abordarán a mediano plazo. Dedicar tiempo y esfuerzo en un ordenamiento detallado de estos ítems puede resultar innecesario, ya que las prioridades podrían cambiar según el feedback y el aprendizaje obtenidos.
En definitiva, no tiene sentido establecer un orden para los ítems del Product Backlog a largo plazo. Conforme se acerquen en el tiempo, durante los Refinamientos, el Scrum Product Owner los irá ordenando con mayor precisión y adecuación.
¿Qué hacen los Developers?
"Los desarrolladores son las personas del Equipo Scrum que están comprometidas a crear cualquier aspecto de un Incremento utilizable en cada Sprint" - Guía Oficial de Scrum
El término Desarrollador o Developer abarca todos los roles necesarios para construir el producto. Por ejemplo, en el desarrollo de software, el tester sería un desarrollador, el programador sería un desarrollador, al igual que el analista de negocio, el diseñador de producto, la persona de interfaz de usuario, back-end, administrador de bases de datos, etc.
Si ocupas este lugar, además de las habilidades técnicas requeridas en tu industria específica, existen ciertas responsabilidades fundamentales que son compratidas por todos los desarrolladores:
Crear el Plan del Sprint
Los Desarrolladores tienen la responsabilidad de crear el plan para cada Sprint. Para lograrlo, es fundamental que realicen estimaciones del trabajo a realizar y determinen cuánto de ese trabajo pueden completar durante la iteración actual. Además, deben desglosar el trabajo en tareas más pequeñas y asegurarse de que exista coherencia en el conjunto de tareas. Este plan se reflejará en el Sprint Backlog.
Entregar solo aquello que esté “terminado”
Un aspecto clave es el compromiso de los Desarrolladores con los estándares de calidad establecidos y registrados en la Definición de Terminado. Es fundamental que no se permita la modificación de estos criterios con el objetivo de finalizar más rápido o entregar una mayor cantidad de producto. La calidad del trabajo es un aspecto no negociable que debe ser defendido.
Por respeto a tu propio trabajo, a tus compañeros de equipo y a los stakeholders, no vas a entregar nada que no esté terminado.
Adaptar el plan frecuentemente
En el marco de Scrum, los Desarrolladores tienen la responsabilidad de evaluar diariamente el progreso hacia el Objetivo del Sprint. Como equipo, deben identificar desviaciones y tomar decisiones para adaptar el plan de las próximas 24 horas con el fin de corregir cualquier desviación. Este proceso se lleva a cabo en la reunión de sincronización conocida como Daily Scrum.
Los Desarrolladores poseen un amplio conjunto de habilidades, conocimientos y herramientas necesarios para construir el producto, sin importar la industria en la que operen. Trabajan de cerca con los usuarios y tienen la capacidad de tomar decisiones de diseño y adaptación en tiempo real, respondiendo rápidamente a los cambios en las condiciones del negocio. Este enfoque ágil evita las burocracias obsoletas y fomenta la agilidad y la eficiencia.
Además de la táctica de trabajo, los Desarrolladores son responsables de mantener la calidad del producto. Esto se logra mediante la creación de incrementos sucesivos en los Sprints. En este contexto, las personas pasan a formar parte de un conjunto interdependiente en lugar de ser percibidas como recursos o individuos independientes. El éxito o el fracaso es un resultado colectivo en lugar de ser individual.
Los artefactos de Scrum
Según la Guía oficial de Scrum, los artefactos representan valor o trabajo y su objetivo es maximizar la transparencia de la información clave. La Guía menciona tres artefactos Scrum: el Product Backlog, el Sprint Backlog y el Incremento.
El Product Backlog y el ordenamiento de los PBIs
¿Qué es el Product Backlog y cuál es su propósito? El Product Backlog, también conocido como Backlog del Producto, es una lista dinámica y ordenada de los ítems (Product Backlog Items o PBIs) que representan las características del producto a construir. Esta lista es mantenida y organizada por el Scrum Product Owner y es la única fuente de trabajo para el Equipo Scrum.
Cada PBI en el Product Backlog tiene un propósito específico, el cual es contribuir a un objetivo de producto. El orden de los PBIs en el Product Backlog es fundamental, ya que determina la estrategia de evolución del producto y establece las prioridades con las cuales los desarrolladores transformarán los ítems del Product Backlog en Incrementos del producto.
Existe una diferencia entre priorizar y ordenar. Cuando se habla de priorizar, una opción es acomodar todo en tres grandes grupos: prioridad alta, media y baja. A diferencia de eso, los PBIs de un Product Backlog deben estar en una fila, nunca compartiendo un mismo grupo, salvo ciertas excepciones que ya veremos, por eso decimos que se encuentran "ordenados" en fila.
Quién determina el ordenamiento
El Scrum Product Owner es el responsable exclusivo de determinar el orden del Product Backlog. Aunque todos los miembros del equipo pueden hacer sugerencias, el Product Owner tiene la autoridad final para definir el orden definitivo de los ítems del Product Backlog, teniendo en cuenta el contexto del negocio, las necesidades del producto y las condiciones del mercado.
Existen diferentes enfoques para el ordenamiento del Product Backlog. Uno de ellos es basarse en la contribución de cada ítem al objetivo del producto, es decir, su relevancia en el cumplimiento del objetivo. Otro enfoque consiste en calcular el beneficio económico en relación al esfuerzo invertido (ROI). Sin embargo, este último enfoque implica la dificultad de determinar el valor económico asociado a cada característica del producto.
Ya sea que ordenes los ítems del Product Backlog por aporte al objetivo del producto o por ROI, en cualquier caso, llamémosle “ordenar por importancia”, éstos pueden verse afectados por el nivel de riesgo asociado a cada uno de ellos.
Por esta razón, deberías aprovechar la construcción iterativa y evolutiva de Scrum para mitigar riesgos en forma implícita: construyendo primero aquellos Product Backlog Items con mayor riesgo asociado y dejando los que poseen menor riesgo para etapas posteriores. Se recomienda evitar los PBIs de baja importancia y alto riesgo.
El Sprint Backlog es un plan deliberadamente incompleto
El Sprint Backlog se compone del Objetivo del Sprint (por qué), el conjunto de PBIs seleccionados para el Sprint (qué), así como un plan de acción para entregar el Incremento (cómo). - Guía Oficial de Scrum
En Scrum, el Sprint Backlog representa todo el trabajo que se realizará durante la iteración. Está compuesto por el Objetivo del Sprint, un conjunto de Product Backlog Items seleccionados y las tareas que los desarrolladores han identificado para poder entregar un Incremento al finalizar el Sprint.
El objetivo del Sprint
El Objetivo del Sprint se establece en la reunión de Sprint Planning y describe la razón por la cual se realiza el trabajo en ese ciclo. Es colaborativamente definido por el Scrum Product Owner y los Desarrolladores. Inicialmente los Objetivos estarán centrados en validar los supuestos más críticos, aquellos que podrían hacer fracasar el producto en su totalidad.
Luego, se pasa a validar supuestos de usabilidad, comportamiento específico de los usuarios de tu producto, cumplimiento de ciertos hitos en outcomes de negocio y, por último, habrá objetivos de optimización, performance y terminaciones cada vez más finas.
El Objetivo del Sprint refuerza la alineación entre el Equipo Scrum y los stakeholders. Al finalizar el Sprint, se espera que el Equipo Scrum haya construido un Incremento que cumpla con el Objetivo. Ese es un compromiso, mientras que el trabajo a realizar, PBIs y tareas, son un mero pronóstico para alcanzar ese logro.
Selección de PBIs para el Sprint Backlog
Los PBIs que finalmente queden seleccionados para el ciclo actual pasan a formar parte del Sprint Backlog. Este es un conjunto de PBIs que cobran cierta coherencia con respecto al Objetivo del Sprint. Heredan el orden que tenían en el Product Backlog, por lo tanto, no es lo mismo trabajar en cualquiera de ellos.
El plan de acción del Sprint consiste en las tareas necesarias para construir el Incremento a partir de los PBIs seleccionados. Estas tareas son identificadas por los Desarrolladores durante el Sprint Planning, y aunque algunas tareas pueden surgir durante el Sprint, se estima que su duración sea de un día o menos.
Incremento de Producto como resultado del Sprint
Un Incremento es un escalón concreto hacia el logro del Objetivo del Producto. - Guía Oficial de Scrum
En Scrum, el Incremento de Producto representa un movimiento hacia el logro del Objetivo de Producto y respeta la Definición de Terminado (DoD).
La coherencia del Incremento
Un Incremento no tiene sentido si es considerado de forma aislada con respecto al resto del producto. El nuevo Incremento se integra a todos los Incrementos anteriores formando una coherencia de producto 100% terminada y funcional hasta ese momento. Nada ha quedado pendiente, nada ha sido creado a medias, nada será terminado en futuras iteraciones.
Es tan fuerte esta intención en Scrum que es preferible no entregar nada a entregar un Incremento que no se pueda utilizar. La falsa sensación de progreso y baja calidad resulta más perjudicial para el Equipo Scrum y los stakeholders que no entregar nada.
Definition of Done (DoD)
La Definición de Terminado (DoD) es el compromiso con respecto a la entrega de un Incremento al finalizar un Sprint. Representa el nivel mínimo de calidad que debe cumplir un ítem del Product Backlog para ser considerado parte del Incremento. Puede ser un estándar organizacional o un acuerdo a nivel de producto.
Cualquier construcción que no respete la Definición de Terminado no formará parte del Incremento y, por lo tanto, no participará del Sprint Review.
Los Eventos de Scrum
Todo el trabajo de Scrum se realiza en momentos específicos llamados Eventos.
Los eventos de Scrum suceden siempre al mismo momento dentro del Sprint y tienen una duración específica. Los eventos de Scrum son cinco: el Sprint, la Sprint Planning, la Daily Scrum, el Sprint Review y la Sprint Retrospective (o Retrospectiva).
El Sprint
El Sprint es un contenedor para todos los demás eventos… Los Sprints son el corazón de Scrum, donde las ideas se convierten en valor. - Guía Oficial de Scrum
Duración sugerida
Scrum utiliza periodos consecutivos de tiempo corto llamados Sprints para construir el producto de manera incremental y evolutiva. Incremento tras Incremento, el equipo inspecciona y adapta frecuentemente tanto el producto como el proceso utilizado.
En general, se recomienda una duración de un mes o menos, siendo una o dos semanas lo más común. La duración no se modifica una vez establecida, a menos que el equipo decida probar con Sprints más largos o cortos. La volatilidad del contexto puede influir en esta decisión. Todos los otros eventos de Scrum, y todo el trabajo que sea necesario hacer para transformar los PBIs en un Incremento sucede dentro de un Sprint.
El Sprint Backlog contiene el plan del Sprint, que puede modificarse a medida que se avanza y se aprende, siempre y cuando no se altere el Objetivo del Sprint. Los cambios en el plan son gestionados por los Desarrolladores.
Cancelación de un Sprint y pausas entre sprints
Un Sprint puede ser cancelado si su Objetivo se vuelve obsoleto debido a cambios drásticos en el entorno. Sin embargo, el descubrimiento de que no se completa todo el trabajo planificado no es motivo suficiente para cancelarlo, ya que aún se puede lograr el Objetivo con un Incremento más pequeño. La cancelación de un Sprint es una decisión que solo el Scrum Product Owner puede tomar.
Con respecto a tomar pausas entre Sprints, tener un descanso no atenta contra el ritmo sostenido. El ritmo sostenido en Scrum es como su nombre lo indica: “ritmo", los latidos del corazón. Es decir, podemos tener un Sprint de longitud fija, sin alteraciones y una pausa de longitud fija, digamos de medio día. Si lo hacemos de esa manera, y preservamos esas longitudes en el tiempo, entonces todavía seguimos hablando de ritmo sostenido.
La situación podría ser completamente diferente si tenemos longitudes de tiempo aleatorias, como la mitad un día después del primer Sprint, dos días después del segundo Sprint y un día después del tercer Sprint. Esto atenta completamente contra el “ritmo sostenido”.
Sprint Planning para construir el Incremento
La Sprint Planning inicia el Sprint al establecer el trabajo que se realizará para el Sprint. - Guía Oficial de Scrum
Introducción y dinámica
El Sprint Planning es el primer evento que se lleva a cabo dentro del Sprint. La dinámica de este evento es de tipo taller donde todo el Equipo Scrum se involucra activamente. La duración máxima de una Sprint Planning suele de ocho horas para un Sprint de cuatro semanas, reduciéndose en longitud para Sprints más cortos.
Durante la Planning, se toman tres decisiones importantes: el Objetivo del Sprint, los PBIs que formarán parte del Sprint y el plan del Sprint. Estas decisiones en conjunto conforman el Sprint Backlog.
El Objetivo del Sprint describe la razón por la cual es valioso realizar el trabajo durante el Sprint. Es creado de manera colaborativa por el Equipo Scrum, basándose en el aporte del Scrum Product Owner.
El Scrum Product Owner y los Desarrolladores seleccionan los PBIs del Product Backlog que formarán parte del Sprint actual. Esta decisión se basa en el Objetivo, el orden de los PBIs en el Product Backlog y un pronóstico del trabajo que los Desarrolladores pueden realizar para convertir los PBIs en Incrementos. El pronóstico se basa en experiencias pasadas.
Durante esta conversación los Desarrolladores realizan todas las preguntas que crean necesarias para conocer los detalles de cada uno de los PBIs y así corroborar o ajustar sus supuestos (refinamiento).
Aún asumiendo que los PBIs ya han sido explorados en detalle durante los refinamientos previos, debido al principio del Manifiesto Ágil por el Desarrollo de Software que determina que una ventaja competitiva consta de “aceptar los cambios aun en etapas avanzadas del proyecto”, es posible que en esta reunión aparezcan PBIs que no habían sido refinados anteriormente.
El Scrum Master facilita la Sprint Planning y se asegura de que los stakeholders necesarios estén presentes o sean contactados para brindar información adicional sobre los detalles de los PBIs.
La Daily Scrum
El propósito de la Daily Scrum es inspeccionar el progreso hacia el Objetivo del Sprint y adaptar el Sprint Backlog según sea necesario, ajustando el trabajo planificado por delante. - Guía Oficial de Scrum
Ciclos de inspección y adaptación
El control empírico de procesos se basa en ciclos continuos de inspección y adaptación en un entorno donde se fomenta la transparencia a todo nivel. Estos ciclos se aplican tanto al producto como al proceso, y se llevan a cabo a través de los Sprints. Sin embargo, para controlar el progreso hacia el Objetivo del Sprint, se utiliza el ciclo de control de 24 horas en las reuniones diarias llamadas Daily Scrum.
¿Cuánto dura la Daily Scrum? La Daily Scrum no debería exceder los 15 minutos. Durante este tiempo, los developers se enfocan en visibilizar el progreso y no en resolver problemas. Los Desarrolladores relevantes pueden abordar los problemas en momentos posteriores a la reunión. Se recomienda realizar la Daily Scrum a la misma hora y en el mismo lugar para reducir la complejidad.
Su objetivo es que los developers compartan impedimentos o desvíos que afecten el logro del objetivo del Sprint y ajustar el plan de las próximas 24hs. Aunque tradicionalmente se utilizaban tres preguntas: ¿Qué hice ayer?, ¿Qué voy a hacer hoy? y ¿Qué impedimentos tengo o tuve en mi trabajo?, el uso de esas preguntas ya no es un requisito con la Guía Oficial de Scrum 2020.
De desarrolladores para desarrolladores
La Daily Scrum es una reunión destinada a los Desarrolladores, facilitada inicialmente por el Scrum Master pero que eventualmente es transferida para que los propios Desarrolladores la faciliten.
Sprint Review para inspeccionar el Incremento
El propósito de la Review es inspeccionar el resultado del Sprint y determinar futuras adaptaciones. - Guía Oficial de Scrum
En la Sprint Review, todo el Equipo Scrum colabora con los stakeholders para revisar el Incremento creado en el Sprint y su integración con el resto del producto para decidir los próximos pasos hacia el logro del Objetivo de Producto. La duración máxima es de cuatro horas para un Sprint de cuatro semanas, siendo más corta para Sprints de menor duración.
Enfoque del Sprint Review
Es importante asegurarse de que la Sprint Review no se convierta en una Demo donde el Equipo Scrum le muestra lo construido a los stakeholders. El feedback valioso y las mejores decisiones surgen de una revisión activa, donde todos los involucrados utilizan el producto en lugar de simplemente observar lo realizado.
Todo el feedback emergente durante la Sprint Review puede ser considerado para adaptar el producto. La decisión dependerá del Scrum Product Owner y de la alineación con el Objetivo del Producto. Las adaptaciones que contribuyan al Objetivo del Producto tendrán alta prioridad, mientras que aquellas que no lo hagan podrían tener baja prioridad. La prioridad determinará la inclusión de las adaptaciones en el Product Backlog como PBIs.
La Retrospectiva del Sprint y cierre
El propósito de la Sprint Retrospective es planificar formas de aumentar la calidad y la efectividad. - Guía Oficial de Scrum
La Retrospectiva es el momento en el que el equipo inspecciona su desempeño durante el último Sprint en términos de personas, interacciones, procesos, herramientas y la Definición de Terminado. Este evento es el corazón de la mejora continua y las prácticas emergentes. Su duración es de un máximo de tres horas para un Sprint de cuatro semanas, siendo más corta para Sprints más cortos.
La Retrospectiva es considerada el cierre del Sprint en Scrum y se lleva a cabo inmediatamente después de la Sprint Review. A diferencia de la revisión del producto, la Retrospectiva se centra en la inspección y adaptación del proceso de trabajo. Se busca crear un ambiente seguro donde el Equipo Scrum pueda expresarse libremente y utilizar técnicas de facilitación ágil y análisis de causas raíz para identificar fortalezas y oportunidades de mejora. Luego, el Equipo Scrum decide cuáles serán las acciones de mejora a llevar adelante en futuros Sprints.
Es importante tener en cuenta que la diferencia clave entre la Retrospectiva y la Review radica en su enfoque: mientras la Review se centra en inspeccionar el incremento construido, la Retrospectiva se enfoca en inspeccionar y adaptar el proceso de trabajo. Es importante evitar la confusión entre estos dos eventos de Scrum.
Pilares de Scrum
Dentro de un Sprint de Scrum hay varios eventos. Cada uno de esos eventos está relacionado de una u otra forma con alguno de los tres pilares: transparencia, inspección y adaptación.
Transparencia
El pilar de la transparencia en Scrum implica hacer visible la información de manera deliberada. La toma de decisiones importantes en Scrum se basa en la información disponible. Para evitar riesgos, es crucial que esta información esté accesible y visible para todos los involucrados. Al visibilizar los artefactos y asegurar el acceso a ellos por parte del equipo y los interesados, se logra alcanzar la transparencia.
La transparencia va en ambas direcciones, no solo del equipo Scrum hacia afuera, sino también desde los interesados hacia el equipo Scrum. Al priorizar la transparencia, se facilita el flujo de información clave y se crea un ambiente propicio para la colaboración y la mejora continua.
Inspección
Tanto la evolución del producto como las mejoras en el proceso de creación deben ser inspeccionados de forma frecuente en Scrum. La evolución del producto te acerca o aleja del objetivo buscado, por lo que es importante descubrir y corregir los desvíos a lo largo del camino. Dado que el contexto es complejo y no se puede predecir con certeza, es necesario inspeccionar y evaluar los supuestos en los que se basan las decisiones.
En Scrum, el Incremento es el artefacto que permite inspeccionar la evolución del producto, y la Sprint Review es el evento destinado a esa inspección al final de cada Sprint. La mejora continua del proceso de creación del producto también debe ser inspeccionada para asegurarse de que los cambios en la forma de trabajar estén fundamentados en supuestos correctos. La Retrospectiva es el evento donde se evalúan los cambios al proceso y su eficiencia.
Para que estas inspecciones sean eficientes, es fundamental contar con transparencia. La transparencia garantiza que se inspeccione una realidad precisa y se tomen decisiones correctas. Es necesario que la información esté accesible y visible para todos los involucrados, fomentando así la confianza y la colaboración en el equipo Scrum.
Adaptación
Si descubres que el producto se desvía considerablemente de su objetivo o el proceso se sale de los límites tolerables, será necesario tomar decisiones de adaptación en Scrum. Estas decisiones deben tomarse lo antes posible para evitar desviaciones mayores.
En la Retrospectiva es donde se toman decisiones de adaptación del proceso, lo que implica cambios en la forma de trabajar. En el Sprint Planning, al comenzar un nuevo Sprint, también se toman decisiones de adaptación del producto. Estos eventos en Scrum están diseñados específicamente para realizar ajustes y adaptaciones necesarios en función de la evolución del producto y del proceso de creación.
Los 5 Valores de Scrum
El éxito de Scrum radica en la capacidad que tengas de llevarlo adelante abriéndote a cinco valores: compromiso, foco, franqueza, respeto y coraje.
Ellos determinan tu dirección con respecto al trabajo que realizas, las acciones que emprendes y el comportamiento que muestras.
Debes tenerlos presentes en cada uno de los eventos de Scrum. Cuando encarnas estos valores junto al resto del equipo y los interesados, logras sacar el máximo provecho de los tres pilares de transparencia, inspección y adaptación.
Cualquier decisión que tomes sobre la mejora continua del proceso, debe resguardarlos y no ir contra ellos. Ahora, veamos a qué se refiere cada uno de los cinco.
Compromiso
“El equipo Scrum se compromete a lograr sus objetivos y a apoyarse entre ellos.” - Guía Oficial de Scrum
Al trabajar en equipo, tu compromiso con el resto del equipo Scrum está por encima de los intereses personales. Te comprometes a apoyar a los otros miembros, a actuar con solidaridad y empatía, a colaborar, a crear un incremento de calidad, a hacer tu trabajo de forma profesional. Te comprometes con el objetivo del producto, te comprometes a ser parte de un equipo autogestionado y multi-funcional, a buscar la mejora continua de los procesos, a seguir los valores y principios del manifiesto ágil. A ser transparente y a desafiar el status-quo.
Una conducta frecuente es exigir al equipo entregar al final del sprint todo aquello que al iniciarlo había seleccionado. Es decir, se toma el trabajo escogido para el Sprint como un compromiso irrenunciable en vez de como lo que realmente es, un pronóstico. De esta forma se está desaprovechando el beneficio de Scrum.
Esta interpretación errónea de este valor se sustenta en la también errónea interpretación de Scrum como metodología predictiva. Hay una creencia que el compromiso es del equipo para con el Incremento y significa entregar sí o sí aquello a lo que se comprometió en el Sprint. Ten cuidado de no caer en esta creencia en la cual el compromiso es un contrato tácito y un elemento de presión para que el equipo entregue cierto Incremento.
Foco
"El foco principal del equipo Scrum está puesto en el trabajo del Sprint para lograr el mayor progreso posible hacia el objetivo" - Guía Oficial de Scrum
Te enfocas en lo más importante, y lo más importante en este momento es el trabajo de este Sprint para lograr un Incremento de producto. ¿Qué es un Sprint?La definición de Sprint la veremos adelante pero básicamente el Sprint es un evento de tiempo preestablecido y fijo (a esto llamamos time-box) con un objetivo y un Incremento ya planificado que se utiliza en Scrum para la creación de productos. Durante el Sprint tu máxima prioridad es construir ese Incremento.
Uno de los aspectos que más cuesta en la puesta en práctica de este valor es la tentación de hacer cosas “por las dudas que se necesiten en un futuro”. Recuerda, debes trabajar solo en lo que es importante ahora y no en lo que puede llegar a ser importante en el futuro. Estás en un contexto complejo y anticiparte demasiado podría hacerte pagar un alto precio por basar tus decisiones en supuestos equivocados.
Otros peligros que atentan contra el foco son las interrupciones durante el Sprint con reuniones imprevistas o trabajo referente a temas no incluidos en el Sprint o perteneciente a otros equipos. Todas estas situaciones debes evitarlas para no corromper el valor potencial de Scrum. Enfócate en lo que hay que hacer ahora, trabaja en un solo equipo.
Frente a la incertidumbre, el foco también te ayudará a evitar el análisis-parálisis. Debes concentrarte en tener un Incremento funcionando en unas pocas semanas, no te enredas en tus propios pensamientos creyendo que analizando las posibilidades llegarás a la respuesta correcta ya que en un entorno complejo esto rara vez funciona. La clave es experimentar y validar en los hechos y no en los supuestos.
Estar enfocado significa que harás una cosa a la vez. Antes de comenzar algo nuevo, asegúrate de haber terminado lo anterior.
Franqueza
“El equipo Scrum y los interesados muestran franqueza con respecto al trabajo y a los desafíos.” - Guía Oficial de Scrum
La naturaleza empírica de Scrum requiere que aprendas a partir de la inspección frecuente de la realidad. Pero ¿cómo? Para que la realidad que veas sea lo más cercana a la verdad posible, necesitas un ambiente transparente. Esa transparencia no se manifestará si en primer lugar no hay honestidad. Para sacar el mayor provecho posible de este valor, podemos concebir la honestidad o franqueza en una doble via.
Si los miembros del equipo abrazan la franqueza como un valor, bajarán tus defensas y la necesidad de cuidar tu imagen frente a la posibilidad de cometer un error o equivocación. Ser abierto te permitirá admitir los errores y cambiar de dirección sin apegos como parte del ejercicio de inspección y adaptación continua.
Para poder ser sinceros con los demás, también debemos practicar la franqueza para con nosotros mismos. Por ejemplo, si logramos una humilde honestidad frente a nuestras capacidades y falencias, sabremos qué aprendizajes nos están faltando y posiblemente tendremos mayor tolerancia con nuestro entorno.
Respeto
“Los miembros del Equipo Scrum se respetan entre sí como personas capaces e independientes y son respetados como tales por las personas con quienes ellos trabajan.” - Guía Oficial de Scrum
No importa el rol que ocupes, muestra respeto por tus compañeros de equipo, por sus habilidades, experiencias y competencias.
Muestra respeto por su derecho a decidir cómo hacer su trabajo. Respeta sus decisiones y opiniones, tienes una gran oportunidad de aprender de ellas. Cuando las personas se sienten escuchadas y tenidas en cuenta es más probable que apoyen las decisiones del equipo, aun estando en desacuerdo. Eso se llama consentimiento.
Juzga las acciones y respeta a las personas. Esto garantizará un ambiente mucho más seguro para poner en práctica la mejora continua.
Y por sobre todas las cosas, respétate a ti. Di “no” cuando sientas la necesidad de decir que no. Al hacerlo enalteces tu autonomía y legitimidad como persona. No aceptes el status-quo si crees que se puede mejorar.
Coraje
“Los miembros del Equipo Scrum tienen el coraje de hacer lo correcto y de trabajar en problemas difíciles.” - Guía Oficial de Scrum
Coraje es valentía. Eres valiente cuando decides construir solo aquello que aporta valor y no trabajar en las cosas que nadie utilizará. Valentía es enfocarte en lo que es importante ahora y no en lo que podría llegar a ser importante en el futuro.
Eres valiente cuando no dudas en poner manos a la obra, aun sabiendo que ningún plan es perfecto y que habrá retos por delante.
Eres valiente cuando reconoces abiertamente que no se lograron hacer aquellas cosas que se pretendía realizar. Valentía es no utilizar excusas. Valentía es hacerte cargo de lo que suceda. Valentía es no fingir frente a tus clientes mostrando cosas no terminadas.
Eres valiente cuando compartes toda la información que tienes para beneficiar al resto del equipo y a la organización, en especial cuando muchos podríamos haber sido educados con la premisa de "la información es poder". En un contexto colaborativo como Scrum, muestras valentía cuando eres transparente, aun sintiendo presión por no serlo.
Muestras valentía al admitir que los supuestos sobre los cuales basaste tus decisiones no fueron los correctos. Eres valiente cuando lo aceptas y cambias de dirección. Valentía es asumir tus errores abiertamente. Valentía es reconocer que no tienes acceso a la información completa y que tus puntos de vista pueden cambiar a medida que aprendes. Valentía es ser humilde en lo intelectual.
En conclusión:
Podríamos afirmar que hay cinco cuestiones que son esenciales para la práctica de Scrum:
- Hacerlo de forma iterativa e incremental.
- No querer abarcar todo desde el principio.
- Controlar las expectativas de los primeros Sprints.
- No abrumarse frente a los impedimentos al progreso que van a surgir.
- Tener coraje, experimentar y dejar experimentar - Errar no es malo, lo malo es no aprender del error.