Qué es scrum y cómo empezar

Se suele pensar que scrum y la metodología ágil son lo mismo porque scrum se centra en la mejora continua, que es un principio básico de la metodología ágil. Sin embargo, scrum es un marco para realizar el trabajo, mientras que la metodología ágil es una mentalidad. La mentalidad ágil se centra en la mejora gradual continua mediante publicaciones pequeñas y frecuentes. En realidad, uno solo no puede "adoptar una metodología ágil", ya que requiere la dedicación de todo el equipo para cambiar la forma de pensar a la hora de ofrecer valor a los clientes. Lo que sí que se puede usar es un marco como scrum para ayudar al equipo a empezar a pensar de esa manera y poner en práctica la aplicación de principios de metodología ágil en la comunicación y el trabajo diarios.

La diferencia entre la metodología ágil y la definición de scrum se encuentra en la Guía de la metodología scrum y en el Manifiesto ágil. El Manifiesto ágil describe cuatro valores:

• Las personas y las interacciones por encima de los procesos y las herramientas
• Software funcionando sobre documentación extensiva
• Colaboración con el cliente por encima de negociación de contratos
• Dar respuesta a un cambio por encima del seguimiento de un plan

La definición de scrum se basa en el empirismo y el pensamiento lean. Según el empirismo, el conocimiento proviene de la experiencia y las decisiones se toman en función de lo que se observa. El pensamiento lean reduce el despilfarro y se centra en lo esencial. El marco de trabajo de scrum es heurístico. Se basa en el aprendizaje continuo y en la adaptación a los factores fluctuantes. Reconoce que el equipo no lo sabe todo al inicio de un proyecto y evolucionará a través de la experiencia. Scrum está estructurado para ayudar a los equipos a adaptarse de forma natural a las condiciones cambiantes y a los requisitos de los usuarios, con el cambio de prioridades integrado en el proceso y ciclos de publicación breves para que tu equipo pueda aprender y mejorar constantemente.

Aunque scrum está estructurado, no es del todo rígido. Su ejecución se puede adaptar a las necesidades de cualquier organización. Existen muchas teorías acerca de cómo deben trabajar los equipos de scrum exactamente para tener éxito. Sin embargo, después de más de una década ayudando a los equipos ágiles a realizar el trabajo en Atlassian, hemos aprendido que la comunicación clara, la transparencia y la dedicación a la mejora continua siempre deben ser el núcleo del marco de trabajo que elijas. Y el resto depende de ti.

• Backlog del producto: es la lista principal del trabajo que debe realizar el propietario o el responsable del producto. Se trata de una lista dinámica de funciones, requisitos, mejoras y correcciones que actúa como la base del backlog de sprint. Básicamente, se trata de la lista de "tareas que hay que hacer" del equipo. El propietario del producto está constantemente revisando, cambiando las prioridades y realizando el mantenimiento del backlog del producto, ya que, a medida que sabemos más o que cambia el mercado, es posible que haya elementos que ya no sean relevantes o que los problemas se solucionen de otras maneras.
• Backlog de sprint: se trata de la lista de elementos, historias de usuario o correcciones de errores, seleccionadas por el equipo de desarrollo, para su implementación en el ciclo actual de sprint. Antes de cada sprint, en la reunión de planificación de sprint (que analizaremos más adelante en el artículo), el equipo elige los elementos en los que trabajará para el sprint del backlog del producto. El backlog de sprint puede ser flexible y puede evolucionar durante un sprint. No obstante, no se puede poner en peligro el objetivo fundamental del sprint, lo que el equipo quiere lograr con el sprint actual.
• Incremento (u objetivo del sprint) es el producto final utilizable de un sprint. En Atlassian, solemos demostrar el "incremento" durante la demostración de fin de sprint, donde el equipo muestra lo que se ha completado en el sprint. Es posible que no escuche la palabra "incremento" en ningún sitio, ya que a menudo se la conoce como la definición del equipo de "Finalizado", un hito, el objetivo del sprint o incluso una versión completa o un epic lanzado. Solo depende de la definición de "Finalizado" de tus equipos y de cómo defines tus objetivos del sprint. Por ejemplo, algunos equipos eligen lanzar algo a sus clientes al final de cada sprint. Por tanto, su definición de "finalizado" se correspondería con "lanzado". Sin embargo, es posible que esto no sea realista en otros tipos de equipos. Supongamos que trabajas en un producto basado en servidor que solo se puede lanzar a los clientes cada trimestre. Podrías elegir trabajar en sprints de 2 semanas, pero tu definición de "finalizado" podría corresponderse con la finalización de parte de una versión más grande que planeas lanzar toda junta. Por supuesto, cuanto más se demore el lanzamiento del software, mayor será el riesgo de que el software no cumpla lo que se espera de él.

Como puedes ver, hay muchas variaciones, incluso dentro de los artefactos, que tu equipo puede elegir definir. Por eso es importante estar abierto a la evolución en la forma de mantenimiento, incluso de los artefactos. Tal vez tu definición de "finalizado" hace que tu equipo tenga que deshacer tareas, y necesitas revisarla y elegir una nueva definición.

A continuación, se muestra una lista de todas los protocolos clave en los que un equipo de scrum puede participar:

1. Organización del backlog: este evento, que a veces se conoce como limpieza del backlog, es responsabilidad del propietario del producto. Los principales trabajos del propietario del producto son dirigir el producto hacia su visión del producto y estar al tanto del mercado y los clientes. Por tanto, él o ella realiza el mantenimiento de esta lista utilizando los comentarios de los usuarios y del equipo de desarrollo para ayudar a priorizar y mantener la lista limpia y a punto para trabajar sobre ella en cualquier momento. Puedes obtener más información sobre cómo mantener un backlog de la forma más adecuada aquí.

2. Planificación de sprint: en esta reunión, todo el equipo de desarrollo planifica el trabajo que se va a realizar (alcance) durante el sprint actual. Esta reunión la dirige el experto o la experta en scrum y, en ella, el equipo decide el objetivo del sprint. Posteriormente, se añaden historias de usuario específicas al sprint desde el backlog del producto. Estas historias siempre se adecuan al objetivo y también son acordadas por el equipo de scrum para que sea factible implementarlas durante el sprint.
   
   Al final de la reunión de planificación, cada miembro del equipo de scrum debe tener claro qué se puede entregar en el sprint y cómo se puede entregar el incremento.

3. Sprint: un sprint es el periodo real en que el equipo de scrum trabaja de forma conjunta para finalizar un incremento. La duración de un sprint suele ser de dos semanas, aunque algunos equipos manifiestan que les resulta más fácil una semana para el alcance o un mes para entregar un incremento valioso. Dave West, de Scrum.org, advierte de que cuanto más complejo sea el trabajo y más incógnitas haya, más corto debería ser el sprint. Pero realmente esto depende de tu equipo, y no debes tener miedo de cambiarlo si no funciona. Durante este periodo, el propietario del producto y el equipo de desarrollo podrán renegociar el alcance, en caso de que sea necesario. Aquí está el quid de la naturaleza empírica del scrum.
   
   Todos los eventos (desde la planificación hasta la retrospectiva) tienen lugar durante el sprint. Una vez que se establece un determinado intervalo de tiempo para un sprint, debe seguir siendo coherente durante todo el periodo de desarrollo. Esto ayuda al equipo a aprender de las experiencias pasadas y a aplicar ese conocimiento a futuros sprints.

4. Scrum diario o reunión rápida: se trata de una reunión diaria de muy corta duración que tiene lugar siempre a la misma hora (normalmente, por las mañanas) y en el mismo sitio para simplificarla. Muchos equipos tratan de finalizar la reunión en 15 minutos, pero eso es solo una guía. Esta reunión también se denomina "reunión rápida diaria" y con ello se hace hincapié en que debe ser rápida. El objetivo del scrum diario es que todos los miembros del equipo estén en sintonía, se coordinen en torno al objetivo del sprint y cuenten con un plan para las próximas 24 horas.
   
   La reunión rápida es el momento de expresar cualquier inquietud que se tenga acerca del cumplimiento del objetivo del sprint o de notificar los impedimentos que se detecten.
   
   Una forma habitual de realizar la reunión rápida es que cada miembro del equipo responda tres preguntas en el contexto de alcanzar el objetivo del sprint:
   
   • ¿Qué hice ayer?
   • ¿Qué tengo planeado para hoy?
   • ¿Hay algún obstáculo?
   
   Sin embargo, hemos observado que esta reunión puede convertirse rápidamente en un momento donde los empleados leen sus agendas del día anterior y del día siguiente. La teoría detrás de la reunión diaria es que las conversaciones que pueden suponer una distracción tengan lugar en la reunión diaria, para que el equipo pueda concentrarse en el trabajo durante el resto del día. Entonces, si se convierte en una lectura en voz alta de la agenda diaria, no tengas miedo de cambiarla y dar rienda suelta a la creatividad.

5. Revisión de sprint: al final del sprint, el equipo se reúne en una sesión informal para ver una demostración o inspeccionar el incremento. El equipo de desarrollo muestra los elementos del backlog que ahora están "finalizados" a las partes interesadas y a los compañeros de equipo para recibir comentarios. El propietario del producto puede decidir si publica o no el incremento, aunque en la mayoría de los casos el incremento se publica.
   
   Esta reunión de revisión también se produce cuando el propietario del producto repasa el backlog del producto basado en el sprint actual, que se puede utilizar en la próxima sesión de planificación de sprint. Para un sprint de un mes, pon el límite de tu revisión de sprint en un máximo de cuatro horas.

6. Retrospectiva de sprint: la retrospectiva es donde el equipo se reúne para documentar y analizar qué ha funcionado y qué no ha funcionado en un sprint, un proyecto, en las personas o relaciones, herramientas o incluso para determinados protocolos. La idea es crear un lugar donde el equipo pueda centrarse primordialmente en lo que salió bien y en lo que debe mejorarse para la próxima vez, y menos en lo que salió mal.