¿Qué es Scrum?
Aunque su origen proviene del mundo del rugby, la palabra Scrum ha adquirido un nuevo significado y propósito en el mundo laboral profesional. En sus inicios, la metodología Scrum se aplicó para el desarrollo de software, pero su uso se ha vuelto más común en la gestión de proyectos Scrum y otros sectores, incluidos el marketing, el desarrollo de productos y los servicios financieros.
La metodología Scrum es un proceso empírico simple que permite a los equipos crear productos de manera incremental en iteraciones, para mantenerse al tanto de las necesidades cambiantes del mercado y alinearse con los objetivos comerciales de la organización.
Cuando pensamos en la aplicación de este tipo de metodologías, pensamos en equipos autoorganizados que trabajan por un objetivo común a través de la inspección y adaptación continuas. Un producto mínimo viable al final de cada iteración brinda una opción para que los equipos obtengan rápidamente comentarios de los usuarios finales y respondan mucho más rápido.
¿Por qué se llama Scrum?
La metodología Scrum complementa lo que se conoce como enfoque ágil para la gestión de proyectos, un medio para «descomponer grandes proyectos en tareas más manejables, que se completan en iteraciones cortas a lo largo del ciclo de vida del proyecto». La metodología Scrum se basa en la colaboración constante, por lo que los equipos pueden completar fácilmente una tarea dentro de un tiempo asignado antes de pasar a la siguiente fase del proyecto.
La mentalidad grupal y el trabajo en equipo involucrados cuando los jugadores de una Scrum de rugby inspiraron el uso de la palabra en mundo laboral moderno. Como metodología, Scrum tiene sus raíces en el artículo de Harvard Business Review de 1986 «The New New Product Development Game» de Hirotaka Takeuchi e Ikujiro Nonaka, que avanzó la idea de que las empresas pueden lograr más al adoptar «un método holístico, como en el rugby. Donde el balón se pasa dentro del equipo a medida que avanza como una unidad por el campo”.
Esta metodología se popularizado aún más a principios de la década de 1990 por Jeff Sutherland y Ken Schwaber, quienes buscaron expandir y aplicar el concepto al desarrollo de software.
Para emplear la metodología Scrum con éxito los involucrados deben aplicar los seis principios: control sobre el proceso empírico, autoorganización, colaboración, priorización basada en valores, sprints y desarrollo iterativo.
Los seis principios de Scrum
La metodología Scrum se basa en seis principios básicos, pautas que deben seguirse en todo proyecto. Los seguidores de la metodología Scrum insisten en que cada principio permanezca intacto y se cumpla, para que el equipo no pierda el enfoque o el proyecto sufra algún contratiempo.
Los seis principios son:
1. Control sobre el proceso empírico.
El proceso empírico dentro de la metodología Scrum se basa en la observación de pruebas sólidas y la experimentación en lugar de la teoría. Hay tres ideas principales para el control empírico de procesos: transparencia, inspección y adaptación.
2. Autoorganización.
Dado que el proceso Scrum depende de muchas personas, la autoorganización es esencial. Todos los involucrados deben trabajar de forma independiente, y el principio de autoorganización permite una mayor aceptación entre todas las partes, al tiempo que facilitamos la evaluación de las contribuciones individuales.
3. Colaboración.
Scrum es un proceso colaborativo, como lo demuestran los muchos roles involucrados (más sobre eso a continuación). Este principio también se enfoca en tres dimensiones de la colaboración: conciencia, articulación y apropiación.
4. Priorización basada en valores.
Este principio implica organizar y priorizar tareas en función de su valor y cómo deben completarse.
5. Sprints.
Las tareas se completan durante los «sprints», que son períodos de tiempo específicos asignados para cada uno. Otros elementos, incluida la «planificación de sprints» y las reuniones diarias, también tienen horas específicas de inicio y finalización. Este time-boxing asegura que todos los involucrados sepan cuánto tiempo se asigna a cada paso, con el objetivo de eliminar el tiempo perdido y los retrasos.
6. Desarrollo iterativo.
Este último principio habla de la comprensión de que un proyecto pueda necesitar ser refinado varias veces durante el proceso de desarrollo. El desarrollo iterativo permite que el equipo realice ajustes y administre el cambio más fácilmente.
El papel de la metodología Scrum en la gestión del cambio
Aunque la metodología Scrum se diseñó principalmente para facilitar el desarrollo de productos y sistemas complejos, también ha encontrado un hueco en la gestión del cambio. Aunque hay muchas industrias diferentes, la mayoría se da cuenta de que ciertas especificaciones y requisitos para un proyecto tienden a cambiar con el tiempo y en el transcurso de un proyecto. Por lo tanto, se requiere la necesidad de un cambio en el diseño o en los procesos.
Cuando implementamos un cambio, el equipo debe estudiar el cambio y llegar a un consenso sobre cuántas tareas pueden lograr dentro de un sprint. Recuerda que no se espera que un sprint supere las 4 semanas como máximo. El concepto de gestión del cambio se aplica al proceso involucrado en la priorización de tareas en el Product Backlog.
A medida que se realizan las solicitudes de cambio, es responsabilidad del propietario del producto decidir si estas solicitudes de cambio pueden afectar significativamente al Sprint actual o si tiene sentido dejarlas para el próximo Sprint. Por supuesto, la decisión no se toma hasta después de consultar con el Scrum Master, el equipo de desarrollo de productos y otras partes interesadas involucradas.
También es importante tener en cuenta que, de acuerdo con el marco Scrum, no se pueden realizar cambios en el alcance de un Sprint una vez que el Sprint está en progreso, a menos que no integrar este cambio pueda afectar negativamente el resultado del Sprint actual. Aquellos acostumbrados a la gestión de proyectos tradicional notarán que este es un enfoque radicalmente diferente de la gestión de proyectos tradicional, pero la ventaja es que ayuda al equipo a gestionar su trabajo de manera eficaz. Además, también vemos una adecuada gestión y manejo de las frecuentes interrupciones de cambio que pueden afectar la duración del proyecto.
¿Qué son los roles en un equipo Scrum?
El equipo Scrum está compuesto por tres roles: un propietario del producto, un Scrum Master y el equipo de desarrollo. Profundicemos un poco más en cada uno de los roles, sus responsabilidades y sus tareas:
1. El rol del propietario del producto
El propietario del producto es el responsable del proyecto a nivel comercial: la persona responsable cuando los procesos no siguen el orden establecido. Al ser una parte interesada principal en el proyecto, es responsabilidad del propietario del producto tener una visión clara de lo que se espera. La capacidad de comunicar esa visión a todo el equipo también recae directamente sobre sus hombros. Este es un paso importante en el comienzo de los proyectos de desarrollo de software Agile y generalmente se realiza a través de la acumulación de productos. La cartera de productos es una lista, generalmente organizada en orden de prioridad, de las cosas que deben hacerse durante la vida útil del proyecto.
El rol del propietario del producto es importante y solo debe ser asumido por alguien que comprenda completamente lo que los usuarios finales esperan ver. Podría ser alguien del departamento de marketing o de producto, pero sin importar quién sea, debe poder comunicar claramente lo que los usuarios esperan ver del equipo del proyecto. También es importante que el propietario del producto tenga una idea de las tendencias futuras en el nicho y qué medidas o características están implementando los competidores como un medio para ganar más terreno en la industria. Sin embargo, eso también depende del tipo de producto que se esté desarrollando (por ejemplo, hardware o software).
Si bien el propietario del producto es el principal responsable de impulsar los objetivos de iteración para generar el máximo valor comercial, no debe trabajar de forma autoritaria teniendo la capacidad de delegar responsabilidades entre los miembros del equipo y trabajar conjuntamente. Su función principal es la de clarificar, comunicar y motivar al equipo.
Para funcionar efectivamente en este rol, es primordial que el propietario del producto tenga grandes habilidades comerciales, ya que esto es pertinente para la toma de decisiones y acciones de rentabilidad.
Responsabilidades clave del propietario del producto:
- Crear la visión
- Representar a los negocios siendo el responsable del ROI
- Transmitir la visión a los equipos
- Priorizar las características que necesita el producto por valor de mercado
- Tomar decisiones
- Negociar con el equipo y el negocio la entrega del producto correcto en el momento correcto
2. El rol de Scrum Master
El Scrum Master es responsable de garantizar que cada miembro del equipo comprenda la metodología Scrum y sus roles. Para ello, debe verificar que los miembros del equipo comprenden la teoría y la práctica de la metofología.
Predica con el ejemplo, poniendo en práctica la paciencia mientras presta atención a todos los aspectos del proyecto. Al trabajar con el propietario del producto, el Scrum Master ayuda con la gestión del Product Backlog y el desarrollo de técnicas para optimizarlo.
Como facilitador, ayuda al equipo a llegar a un consenso sobre lo que se espera lograr durante un período de tiempo específico. El equipo ve al Scrum Master como un líder servicial porque se espera que tome cualquier acción con el fin de ayudar al equipo a alcanzar los objetivos. El Scrum Master es responsable de eliminar cualquier obstáculo que impida el progreso del equipo.
Otra forma en la que ayuda al equipo a brillar es asegurándose de que no se comprometan demasiado con los sprints: el objetivo principal detrás de tener sprints regulares es poder presentar iteraciones mejoradas, teniendo en cuenta que no se espera que los sprints superen las 4 semanas. El propósito del sprint es entregar resultados de calidad en poco tiempo. Sin embargo, si por alguna razón, los miembros del equipo están demasiado comprometidos durante un ciclo en particular, puede causar estrés y ansiedad, lo que dificulta el crecimiento del proyecto en lugar de acelerar los resultados de calidad.
El Scrum Master busca desafíos para que el equipo pueda desarrollar nuevos conocimientos y estimula el pensamiento innovador para ayudar a los miembros del equipo a encontrar soluciones a los problemas persistentes. Dicho esto, el papel del Scrum Master no es resolver problemas para el equipo, sino brindar orientación para que puedan descubrir las soluciones por sí mismos. Esto se logra haciendo las preguntas correctas para guiarlos hacia las respuestas correctas.
En resumen, cuando las personas miran a un Scrum Master, deben ver:
- Un líder servidor: asesora y entrena a los equipos sobre la teoría y las prácticas de scrum, los guía sobre cómo deben adaptarse a ellas y, por lo tanto, se dan cuenta de los beneficios de scrum tanto a nivel de equipo como a nivel de organización.
- Ayuda a eliminar obstáculos/impedimentos: ayuda a los equipos de desarrollo a eliminar los impedimentos contactando a las personas adecuadas, lo que garantiza un progreso de desarrollo fluido sin interrumpir al equipo.
- Facilita la colaboración: permite las interacciones dentro del equipo, así como entre el equipo y el propietario del producto.
- Enseña la Metodología Scrum al equipo.
- Protege a los equipos de interrupciones externas, como cambios en las historias en el sprint actual.
- Es un agente de cambio, en el crecimiento de la organización para entregar temprano y con frecuencia eliminando esfuerzos innecesarios.
3. El equipo
El trabajo principal dentro de la metodología Scrum lo lleva a cabo un equipo dedicado; este grupo de personas trabaja en conjunto para desarrollar y entregar el producto. Idealmente, es un pequeño equipo interdisciplinar, que consta de unas 6 personas, incluidos analistas comerciales, probadores de producto y desarrolladores, solo por nombrar algunos de ellos.
Para trabajar juntos de manera efectiva, los miembros del equipo deben tener un objetivo común. Además, deben adherirse a las reglas y principios de la metodología Scrum para lograr los objetivos esperados de un sprint específico. Como equipo, deben aceptar la culpa por los fracasos del proyecto, y todos comparten la gloria de un proyecto exitoso.
Se espera que los miembros del equipo informen sobre su progreso diario, de los éxitos y desafíos a los que se enfrentan. Cuando se forma un nuevo equipo, este necesita de un periodo de adaptación de unas dos o tres semanas para que los miembros se acostumbren a trabajar juntos.
Según el Dr. Bruce Tuckman, el desarrollo de los grupos pequeños pasa por 4 etapas reconocibles: Formación, Tormenta, Normalización y Ejecución.
En la primera etapa, la formación, los miembros del equipo dependen en gran medida de la dirección y orientación del líder; durante este tiempo, se espera que el líder responda muchas preguntas, ya que los roles individuales aún no están claros.
Durante la fase de tormenta, los miembros del equipo se esfuerzan por establecerse dentro del grupo; aquí es donde se prueban las competencias de un Scrum Master.
La siguiente etapa es la etapa de normalización. En la fase de normalización, se han establecido roles y se han desarrollado procedimientos para hacer las cosas. Esta etapa abre la puerta para que el Scrum Master tenga más espacio para actuar como facilitador en lugar de líder de un grupo.
Finalmente, tenemos la fase de ejecución, donde los miembros del equipo se comprometen al 100% con la ejecución del proyecto. Durante esta fase, cualquier desacuerdo que surja se resuelve con bastante rapidez y las decisiones se toman en función de criterios acordados.
En esta etapa final, el equipo es totalmente autónomo, está autoorganizado y es capaz de producir grandes resultados. Todos sus miembros entienden las tareas que se esperan, cómo desglosar las tareas, quién es responsable de realizar qué tarea y en qué orden deben realizarse. En este punto, podemos comenzar a observar cómo algunos miembros del equipo comienzan a apreciar el trabajo de los demás incluso llegando a aprender sus destrezas.
A continuación, encontramos las características de un equipo dentro de la metodología Scrum:
- Autoorganizado: el equipo de desarrollo será un grupo autogestionado, que decidirá las tareas en las que trabajará de forma incremental. No hay un ‘Gerente’ que controle su trabajo.
- Empoderado: el equipo debe comprometerse a trabajar, determinar «CÓMO» entregar y decidir «CUÁNTO» entregar en una iteración.
- Multifuncional: el equipo no separa a los miembros como desarrolladores, probadores o analistas ágiles y cada miembro tiene las habilidades necesarias para entregar el incremento del producto.
- Pequeño: el equipo de desarrollo idealmente debería tener de 5 a 9 miembros con las habilidades suficientes para entregar el trabajo comprometido. Los equipos más pequeños no tendrán el ancho de banda para completar un trabajo considerable y los equipos más grandes aumentarán la complejidad.
- Ubicación conjunta: el equipo ágil generalmente comparte ubicación para garantizar una colaboración eficaz.
- Comprometidos: dado que el equipo está facultado para tomar decisiones sobre el alcance del trabajo en un sprint, están comprometidos con la entrega, deben ser transparentes sobre el progreso y resaltar los impedimentos desde el principio.
- Dedicado: este equipo está enfocado y 100 % dedicado a la entrega de productos.
¿Qué son los eventos típicos de la metodología Scrum?
Todas las actividades dentro de la metodología Scrum tienen un límite de tiempo y permiten a los equipos inspeccionar su trabajo actual e implementar esos aprendizajes en futuros límites de tiempo.
El Sprint
El sprint es una iteración limitada en el tiempo, que suele oscilar entre 1 y 4 semanas, al final del cual, el equipo entrega un incremento del producto.
El sprint tiene las siguientes características:
- No excede un máximo de un mes calendario, ya que esto aumentará el riesgo debido a cambios en los requisitos y, por lo tanto, es posible que no proporcione el valor comercial percibido al final del sprint.
- Tiene un objetivo asociado con cada sprint que realmente mide el éxito del sprint.
- Puede ser cancelado por el propietario del producto, si el objetivo o la necesidad del sprint se vuelven obsoletos debido a las necesidades cambiantes del mercado.
La metodología Scrum aboga por tipos específicos de actividades o reuniones dentro de un sprint para evitar las reuniones tradicionales. Estos eventos o reuniones se llevan a cabo en intervalos regulares y específicos dentro del sprint. Los eventos típicos son:
- Planificación del Sprint
- Dailys
- Revisión del Sprint
- Retrospectiva del Sprint
1. Planificación del Sprint
La reunión de planificación de Sprint ocurre al comienzo de cada Sprint. Esto ayuda al propietario del producto y a los equipos a planificar los incrementos que se llevarán a cabo durante el sprint. El equipo deberá realizar las siguientes actividades durante esta reunión:
- Considerar y analizar los posibles incrementos con el propietario del producto.
- Asegurar una comprensión compartida sobre esos incrementos.
- Seleccionar una cantidad de incrementos que estiman completar.
- Crea un plan suficientemente detallado para completar los incrementos seleccionados.
¿Cómo hacer la planificación de los Sprints?
Debes elegir los incrementos en función del sprint utilizando tablas intuitivas. Para ello, hay dos actividades que se deben realizar:
Parte I: Definir ‘QUÉ’ trabajo se realizará
- El propietario del producto entrega al equipo los incrementos a realizar
- Todo el equipo colabora para entender el trabajo
- El equipo está facultado y decide únicamente cuánto trabajo se debe realizar en función de la capacidad del sprint.
- El equipo elabora un objetivo llamado objetivo del sprint para mantener el foco en el mismo.
Parte II: Explicar ‘CÓMO’ se realizará el trabajo
- El equipo debe decidir cómo producir el siguiente incremento que cumpla con el objetivo.
- Se lleva a cabo la planificación y el diseño necesario para completar el trabajo de forma satisfactoria.
- El trabajo a realizar en los días iniciales se divide en pequeñas unidades de un día o incluso menos.
- El trabajo que se hará más tarde se divide cuando sea necesario.
2. Dailys
Los dailys son un evento de tiempo limitado de 15 minutos en el que el equipo gestiona sus actividades diarias. El equipo se reúne todos los días, preferiblemente a la misma hora y en el mismo lugar, para que se convierta en un hábito. Durante la reunión, cada miembro responde tres preguntas críticas:
- ¿Qué hice ayer?
- ¿Qué haré hoy?
- ¿Hay algún impedimento que me bloquee?
Es fundamental que todos los miembros del equipo estén disponibles para el daily. El daily sirve para que el equipo realice un seguimiento del progreso hacia el objetivo del sprint, todos los miembros deben participar y colaborar entre sí.
El daily también asegura que los impedimentos que bloquean el progreso del sprint se identifiquen y resuelvan sin demora. La resolución detallada de los problemas no se produce durante esta reunión. Es importante transmitir actualizaciones individuales a todos los miembros del equipo para evitar reuniones innecesarias.
Este evento mejora la comunicación y la transparencia del equipo, permitiendo que los equipos se organicen por sí mismos y tomen decisiones más rápidas.
3. Revisión del Sprint
La revisión del sprint es un evento que ocurre al final de cada sprint, donde el equipo muestra el trabajo realizado en el sprint a las partes interesadas. Durante esta reunión sucede lo siguiente:
- Una demostración del incremento que muestra las funciones y la tecnología subyacente
- Los comentarios de la revisión brindan información al equipo para analizar más a fondo el perfeccionamiento de los trabajos pendientes existentes y el plan para futuros sprints.
- El Scrum Master facilita esta reunión de revisión a la que normalmente asisten todas las partes interesadas invitadas por el propietario del producto.
- La revisión de Sprint es esencialmente una forma en la que el equipo inspecciona y se adapta al próximo Sprint.
4. Retrospectiva del Sprint
Durante la reunión retrospectiva del Sprint, el equipo inspecciona el sprint completado anteriormente e identifica las áreas de mejora que se deberán implementarán para los próximos sprints. Esto sucede después de cada sprint y justo después de la revisión del sprint en la que participa todo el equipo.
Durante esta reunión:
- El equipo hace una introspección sobre lo que salió bien en términos de colaboración, planificación, procesos y herramientas.
- Intentan identificar mejoras potenciales que se pueden implementar en el próximo sprint para hacer que los procesos sean más eficientes aprendiendo de las deficiencias anteriores.
- Deciden qué se podría hacer en el próximo sprint teniendo en cuenta las principales mejoras.
- Scrum Master asegura que los equipos mejoren sus habilidades y conocimientos durante el proceso para que sean más eficientes en el próximo sprint
- El equipo se enfoca en mejorar todo su ciclo de entrega.
- Las tres preguntas típicas que responde el equipo son:
- ¿Qué empezaremos a hacer?
- ¿Qué dejaremos de hacer?
- ¿Qué seguiremos haciendo?
Todos los eventos anteriores dentro de la metodología Scrum permiten a los equipos entregar el trabajo en pequeños periodos de tiempo. Esto también permite a los equipos recibir comentarios, inspeccionar y adaptarse para la próxima iteración.
Beneficios de la metodología Scrum:
Uno de los principales inconvenientes de la gestión de proyectos es la incertidumbre de los resultados, por lo que es impensable asegurar el éxito de un proyecto antes de su finalización. La metodología Scrum garantiza ser lo suficientemente iterativa, rápida y adaptable para entregar resultados lo antes posible para disminuir la brecha entre el inicio y el final. A continuación, presentamos los principales beneficios de esta metodología:
- Entregables rápidos: los proyectos realizados en base a la metodología Scrum consiguen sus resultados antes de manera más productiva.
- Fácil de preparar: gracias a la flexibilidad de esta metodología permite a sus usuarios la redefinición de los objetivos en caso de que se identifiquen errores a mitad de camino y que puedan ser corregidos.
- Uso económico: el tiempo y el dinero se utilizan de manera efectiva, siempre que sea necesario, produciendo así proyectos económicos en un período corto de tiempo.
- Fácil de manejar: gracias a que los sprints son periodos cortos de tiempo, las posibilidades de cambio ayudan a conseguir los objetivos.
- Proceso agile: gracias a la posibilidad recibir actualizaciones periódicas del progreso realizado a lo largo del sprint a través de los dailys.
- Unidades manejables: por grande que sea un proyecto, siempre se puede dividir en incrementos factibles que se pueden realizar en sprints alcanzables.
- Versátil: otorga acceso a cualquier etapa de desarrollo y permite el máximo de acciones modificables dentro del alcance de la metodología Scrum.
- Directo y claro: cada miembro del equipo es consciente del avance que cada uno a realizado gracias a los dailys.
Resumen de la metodología Scrum
La metodología Scrum es una metodología multidisciplinaria que permite la superposición de los roles; esta característica fomenta la mejor comprensión y apreciación de los roles individuales que desempeñan todos los miembros del equipo. Se basa en un marco de retroalimentación continua que fomenta la comunicación efectiva entre los miembros del equipo. Mientras que la metodología Waterfall tradicional tiene la desventaja de las interrupciones en la comunicación que pueden volverse visibles de inmediato o pueden no volverse visibles hasta que se haya finalizado todo el proceso.
Con el enfoque tradicional de gestión de proyectos, existe un esfuerzo deliberado para estimar el proyecto, al comienzo del proyecto. Por este motivo, se necesita mucho tiempo y no necesariamente se hace con el aporte del equipo que realmente está realizando el trabajo. Entonces, a menudo se cree falsamente que el proyecto tendrá éxito si los miembros del equipo del proyecto se ciñen al plan.
Con la metodología Scrum, la falacia de planificación se tiene en cuenta desde el primer momento; esta es la razón por la que dicha metodología aboga por realizar un trabajo detallado en pequeñas porciones. De esa manera, la retroalimentación es inmediata y hay una mejora continua a lo largo del ciclo de vida del proyecto.
