Scrum está de moda y es imposible negar la influencia que tiene en todos los modelos de gestión y trabajo en equipo. Este «modelo» es protagonista de una transformación a escala global. Si la pandemia aceleró la transformación organizacional, entonces Scrum es el combustible que potencia cientos de miles de equipos remotos y virtuales a nivel global.
¿Pero, qué es Scrum y por qué es tan famoso?
En el contexto de gestión, Scrum fue creado a inicios de los años 90. Sin embargo, tomó casi dos décadas la publicación de la primera versión de la Guía Oficial, que es, como diríamos los geeks, el modelo canónico de hoy.
Los padres de Scrum son Jeff Sutherland y Ken Schwaber. Y su visión ha evolucionado con los años. Por eso para muchos es difícil definir qué es Scrum, ¿un método? ¿un modelo? ¿un proceso? ¿o una metodología?
¿Metodología Scrum o proceso?
Scrum es un marco de trabajo – framework. ¿Y qué significa que sea un marco de trabajo? Vamos con un ejemplo de qué es un marco de trabajo. Un ejemplo de los que me gustan.
Imagina que eres fan de los LEGO® y que has comprado una caja de fichas. Pero decides no seguir las instrucciones sino crear tu propio modelo. Modo creativo dirían los jugadores de Minecraft.
Cuando estas en modo creativo con tus fichas, es posible que tengas preferencia por unas fichas que te sirvan siempre como base para tus modelos. Esas fichas fundamentales, que son la base de modelos más complejos, podrías llamarlas: marco de trabajo o framework.
Scrum: un conjunto base
Scrum es un conjunto de «reglas básicas» que incluye:
- Eventos – un conjunto de actividades que algunos «innovadores de la palabra» llaman ceremonias o rituales.
- Artefactos – herramientas e instrumentos como el Backlog de Producto y el Backlog de Iteración, o la Definición de Completado – definition of done
- Roles – donde se describe el famoso Scrum Master y el Product Owner
Este conjunto base es tierra fértil para incorporar nuevas prácticas o escalar el modelo. Y allí está el éxito de Scrum y por qué es tan famoso. Scrum es simple, sencillo y liviano. Esa es su mayor ventaja – y su mayor debilidad.
Si tu equipo estructura bien aquello que construye encima de Scrum, será exitoso. Si tu equipo no estructura bien como extender el marco, seguramente sufrirá muchos problemas que te harán pensar en abandonar el camino.
¿Qué son los Sprints?
Antes de hablar de los eventos de Scrum, es bueno hablar del concepto de sprint. Y, aunque Scrum no es un proceso prescriptivo, si plantea un modelo de gestión basado en sprints.
Los sprints son periodos de tiempo de duración fija y corta – no más de 4 semanas. Estos ciclos se conocen como iteraciones en otros modelos de gestión. En muchos casos, las personas intercambian los términos indistintamente.
Los Sprints deben durar siempre lo mismo. A lo largo de los años la recomendación sobre la duración de los Sprints se ha ido reduciendo. Hace no mucho se recomendaban ciclos de entre 2 a 8 semanas. Hoy en día, la recomendación es que un Sprint dure de 1 a 4 semanas.
Si estás haciendo Scrum, tus sprints deberían durar siempre lo mismo. Es decir, no deberías tener sprints de una semana y otros de 4 semanas y otros de 2 semanas.
Ciclo Scrum
El modelo define una secuencia de eventos que se repite sprint a sprint. Este ciclo contempla:
- Planificación, que busca responder a las preguntas:
- ¿Cuál es el objetivo de este Sprint?
- ¿Cómo esperamos alcanzar dicho objetivo?
- Seguimiento diario, cuyo objetivo es mantener sincronizado al equipo y responder a las preguntas:
- ¿Qué hemos logrado?
- ¿En qué estamos enfocados ahora?
- ¿Qué problemas tenemos o qué riesgos anticipamos como equipo?
- Cierre a nivel de producto. Busca responder:
- ¿Qué hemos completado durante el Sprint?
- ¿Lo que hemos completado resuelve la necesidad o el objetivo planteado?
- Un cierre a nivel de proceso. Responde a las preguntas:
- ¿Qué hicimos bien como equipo?
- ¿Qué debemos o podemos mejorar?
- ¿Qué acciones vamos a tomar para mejorar o corregir malos hábitos como equipo?
Refinamiento del Backlog del Producto
El refinamiento del backlog es una actividad que ha ido ganando terreno a lo largo de los años. El refinamiento del backlog se conocía antes como grooming.
No obstante, y creo que, por terquedad, esta actividad – que se menciona con frecuencia con el término scrum, no aparece como un evento oficial del marco de trabajo.
Yo estoy abiertamente en contra de no dejarlo explícito como un evento.
Ejemplo de Scrum: eventos del ciclo a manera de agenda
Como dije antes, el ciclo Scrum se repite cada sprint. Así que, si la duración de tus iteraciones es de una semana, este ciclo de eventos se repite cada semana. Si tus iteraciones duran dos semanas, podrías tener una agenda similar a esta – es un ejemplo, no es para copiar y pegar con todos tus equipos y proyectos. Seguro te ayudará a tener una idea de lo que sucede.
Tipos de Scrum
Aunque solo hay un scrum canónico, definitivamente hay varias versiones o visiones del marco de trabajo. Desde luego, la más aceptada y respetada es la del Scrum Guide.
Pero acá te presento gran parte de la literatura disponible – cada una con su versión ajustada a Scrum – qué es un poco lo que yo hago con este artículo. Sumar un poco de contexto y experiencia, intentando no romper las reglas básicas – los pilares y los valores.
Guía Oficial: modelo canónico
Ya he hablado de la guía de Scrum. Acá sus características:
- Es mantenida y actualizada por los «padres» de Scrum.
- Fue originalmente concebida para el desarrollo de software.
- Es la versión más popular y ampliamente aceptada.
- Es también la versión más ambigua y menos restrictiva. Esto puede llevar a equipos sin experiencia y acompañamiento apropiado a perder el norte.
Scrum Body of Knowledge: el más odiado
Si la Guía Oficial tiene la visión más amplia y flexible, el SBOK es lo totalmente opuesto. La empresa detrás de este (monstruoso) documento quiso emular el PMBOK del PMI. Tuvo mucho éxito hace algunos años y sus certificaciones eran muy comunes. Hoy, con la llegada de otros jugadores aún más cuestionables y menos estrictos, ha perdido mucho terreno. Aunque no me agrada su aproximación, admito que en el esfuerzo de estructurar todo el trabajo hay valor y algunas soluciones interesantes a los retos de adoptar la metodología.
Scrum en Scaled Agile Framework (SAFe)
SAFe es un marco de agilidad a escala. Su propuesta intenta resolver el hecho de que el marco de trabajo no plantea opciones sobre esfuerzos o estructuras organizacionales de otra magnitud – 50, 70 o 150 personas.
Aunque SAFe no describe el marco, es evidente que hace modificaciones claras al modelo canónico.
Scrum @Scale
Otro intento – algo simplista para mi gusto- de promover Scrum a nivel organizacional. Una de sus mayores críticas es que construye aquello que el modelo sin escala intentó desacreditar. Es inevitable, la escala requiere estructura y algo de burocracia.
Otras versiones: certificaciones sin aporte conceptual
Podría asegurar que hay 1000 versiones del marco de trabajo. Casi todas ellas asociadas a una «certificación» en alguno de los roles. Pero puedo asegurar con confianza que detrás de este esfuerzo hay más intención de ganar dinero con cursos y certificaciones, que de verdad aportar a la profesión o el ejercicio mismo de los equipos que adoptan Scrum
Artefactos de Scrum
El marco Scrum tiene muy pocos artefactos. Esto lo hace difícil de «aterrizar». Y, sin el conocimiento y la experiencia, puede llevar al equipo a sentir frustración al desconocer cómo sacar mayor provecho de ellos.
Aquí encontrarás una lista de artefactos «oficiales» y otros que se usan sobre el «conjunto base» y son muy populares.
Backlog
El backlog es una lista priorizada de requerimientos. A diferencia de otras estructuras de descomposición, el backlog está diseñado para soportar movimiento y dinamismo en los requerimientos. Es fácil gestionar cambios, nuevos requerimientos e incluso diferentes niveles de detalle.
Hay dos tipos de backlog:
- Backlog de producto. Una versión orientada al valor del negocio.
- Backlog del sprint. Una especie de hijo del Backlog de producto que, aunque orientada al negocio, contiene casi siempre mucho más detalle e incluso elementos orientados a desarrollo o mantenimiento del producto – conocidos como habilitadores o tareas y subtareas.
Incremento
El incremento es un concepto simple, muy difícil de llevar a la práctica. El incremento es un «paso decidido» o una «victoria concreta» en dirección al cumplimiento del objetivo del producto.
Entonces, si hablamos de software, es una versión del producto que es desarrollada o «evolucionada» dentro del sprint y que agrega una porción de valor clara y comprobable – no olvidemos los pilares de scrum.
¿Pero, qué es un incremento si mi equipo no desarrolla software? Bueno, ahí está el truco. Cómo estructurar un plan de trabajo de alto nivel, orientado a victorias tempranas. Nada fácil.
Definición de Completado – Definition of Done
Esta es una especie de lista chequeo que pacta el equipo de desarrollo con el Product Owner. El objetivo de esta lista es similar a cuando llevas tu auto al concesionario – o taller oficial. Antes de poder retirar tu auto, seguro te entregan una hoja de control que debería tener todos los pasos marcados como completados. Así saben que está listo para que tu «lo apruebes».
Definición de Listo para Trabajar – Definition of Ready
Este es un artefacto popular, pero no es oficial.
Si existe una lista para validar si un trabajo ha sido completado. Es posible definir también una lista para validar que un elemento del backlog de producto está listo para ser evaluado por el equipo en la planificación de un sprint.
Historias de Usuario – User Stories
Las historias de usuario NO son un artefacto scrum. Es más NO es obligación alguna usar este tipo de instrumento como elementos del backlog – aunque muchos insisten que si no usas historias de usuario no eres ágil.
A pesar de la creencia popular, las historias de usuario y scrum no tienen el mismo origen. Las US, como se les conoce popularmente, no son condición sine qua non para tener un backlog o adoptar scrum. Es decir, puedes adoptar scrum y NUNCA usar historias de usuario.
Las historias de usuario son instrumentos valiosos como artefacto cuando el equipo intenta desarrollar nuevos productos. Las historias de usuario se enfocan en el valor de lo que quiero lograr y no en el alcance de lo que quiero lograr.
Vamos con un ejemplo. Empecemos con algo de contexto.
Alberto es un trabajador dedicado y comprometido. Ha pasado algún tiempo desde que Alberto tomó vacaciones. En consecuencia, ha decidido tomarse unos días para descansar en familia.
Requerimiento orientado al alcance – scope
Tenemos un contexto que plantea una necesidad. Eso es fundamental, y voy a escribir un requerimiento que busca resolver dicha necesidad con un alcance específico – es decir, determinando de paso la solución a la necesidad.
Reservar tiquetes, alojamiento todo incluido y traslados durante un fin semana completo – de viernes a domingo – en la turística ciudad de Punta Cana en la Rep. Dominicana, para Alberto y su familia.
A simple vista, viajar un fin de semana es un requerimiento que, ciertamente, resolverá mis ganas de tomar vacaciones. Si no conoces Punta Cana, digamos, es un lugar para relajarse y disfrutar del clima, las playas y un buen ron.
No obstante, la ejecución de ese requerimiento limita a una (1) las opciones de resolución de la necesidad, es decir, solo puedo ir a Punta Cana. ¿Qué sucede si cancelan los vuelos a Punta Cana, o no hay disponibilidad en los hoteles? No podemos resolver el requerimiento.
Requerimiento orientado al valor de negocio
Una historia de usuario – más o menos bien escrita y con la firme intención de explicar la diferencia académica, diría algo así:
Como trabajador dedicado y comprometido deseo pasar unos días lejos del trabajo y familia para descansar y recargar la energía que necesito para hacer bien mi trabajo.
Este requerimiento no dice específicamente lo que se debe hacer para ofrecerle a Alberto unos días de descanso. Eso puede ser malo, si como equipo no tenemos experiencia alguna en ofrecer experiencias de descanso en familia. Eso puede ser bueno, si como equipos somos buenos en ofrecer alternativas de descanso en familia.
Roles de Scrum
El marco de trabajo es un «conjunto base». Y bajo esa filosofía, también lo son los roles dentro de Scrum. Es decir, existen unos roles dentro del marco, pero eso no significa que no pueda tener otros roles. ¿O sí?
Algunos radicales, Scrumaniacs, dirían que no hay más roles dentro de un equipo Scrum, pero digamos entonces que pueden ser especialidades. Digamos, especialista en UI/UX o especialista en pruebas, o especialista en base de datos – solo puse varios ejemplos para torturar a los scrumaniacs.
Estos roles base son:
Dueño del Producto – Product Owner
En mi experiencia, el dueño del producto (PO) es el rol más importante en el éxito de scrum en las organizaciones. De seguro te estás preguntando, ¿pero acaso no lo es el Scrum Master – ¿qué sentido tiene que tu rol diga «máster» si no eres el más importante? Y bueh, esas cosas pasan a veces.
En mi opinión, el PO tiene a su cargo el insumo clave de la agilidad, y es la estructura de desglose que permita la entrega incremental – o los famosos incrementos de producto.
Imagine tener a su cargo el mejor equipo de chefs del mundo y no saber qué pedirle más que «arroz con huevo»[1]Y quiero decir que es un plato que todos alguna vez hemos comido y hace parte del Ranking de Taste Atlas.. O pedirle recetas que no resuelven los gustos de sus potenciales comensales. ¿Qué desperdicio?
El Product Owner es el encargado de maximizar el beneficio que ofrecen los resultados del trabajo del equipo (de desarrollo). Es decir, el Product Owner es quien define, prioriza y valida los requerimientos – o es al menos quien gobierna esos procesos. Y en este ejercicio de definición, priorización y validación, busca maximizar el «flujo de valor». Es decir, los beneficios que se reciben de probar, usar o experimentar el resultado de cada iteración.
Scrum Master
El otro rol es el del Scrum Master, que es una suerte facilitador y cheerleader – algunos más lo segundo que lo primero XD – que busca potenciar al equipo (como equipo) y apoyar a sus miembros para su crecimiento.
Lejos de tomar responsabilidades directas dentro del equipo, el Scrum Master es quien «cuida» el ejercicio de la metodología – aunque, en teoría, Scrum no es un método. Y es quien protege al equipo de los potenciales abusos del PO, y ayuda a resolver los impedimentos que puedan presentarse a lo largo del ejercicio del trabajo – una suerte de patinador, diríamos acá en Colombia.
Muchos ven al SM como un salvador, o un ser iluminado. Admito que no es fácil ser quien lidera el cambio – y ayuda a transformar. Pero definitivamente es más un agente de cambio que un actor activo en el proceso productivo.
¿Acaso el Scrum Master es el nuevo gerente de proyecto?
En mi opinión, para nada en absoluto. Ambos roles son diferentes y complementarios. Puedes tener PM, SM o SM que son además PM, o PM que son además SM. Depende mucho de la organización y de las responsabilidades que se asocien al rol.
Lo que nunca debería pasar es que el SM y el PO sean la misma persona. Así que puede ser un PM/PO o un PM/SM pero nunca un solo PM – creo que ese fue el mayor error de lo que hoy llamamos gerencia tradicional, intentar que el PM haga ambas cosas. ¡Punto para los agilistas!
Hace no mucho escribí un artículo que te podría interesar sobre los roles de PM y SM: Si eres ágil, no necesitas directores de proyecto
Desarrolladores – Developers
Bueno, aunque Scrum no habla específicamente de desarrollo, no ha logrado encontrar otro término para el equipo de personas que, efectivamente, realiza el trabajo. Es decir, si el PO es quien solicita, y el SM quien facilita, los Desarrolladores son los que hacen.
Este equipo es multidisciplinario y, ojalá, autónomo. No debería tener muchas personas, pero tampoco muy pocas – digamos que antes decían algo como 3 a 9, o 5 a 7, o… bueno se entiende. Si son muchos no se pueden coordinar como un equipo, si son muy pocos no logran acometer ningún resultado en corto tiempo.
Consideraciones finales
Bueno, como ven, Scrum no es un marco complejo o difícil de entender. Es relativamente sencillo y se basa en un modelo muy simple de gestión de equipo y separación de roles. Me recuerda mucho al libro Death by Meeting. Sin embargo, y como bien lo expresan en la Scrum Guide – la guía canónica de Scrum:
Scrum es gratuito… El marco de Scrum es inmutable. Si bien es posible implementar solo partes de Scrum, el resultado no es Scrum. Scrum existe solo en su totalidad y funciona bien como un contenedor para otras técnicas, metodologías y prácticas.
Scrum Guide 2020
Comentarios y notas del autor
