La gente suele pensar que "scrum" y "metodología ágil" son lo mismo, porque el scrum se centra en la mejora continua, que es un principio fundamental de la agilidad. Sin embargo, el scrum es un marco para realizar el trabajo, mientras que la agilidad es una filosofía. La filosofía ágil se centra en la mejora continua e incremental mediante publicaciones pequeñas y frecuentes. Realmente no se puede "optar por la agilidad", ya que se necesita la dedicación de todo el equipo para cambiar su forma de pensar sobre la oferta de valor a los clientes. Pero sí se puede utilizar un marco como el de scrum para poder empezar a pensar de esa manera y a practicar la incorporación de principios ágiles 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 scrum y en el Manifiesto ágil. El Manifiesto ágil describe cuatro valores:

• Personas e interacciones por encima de los procesos y las herramientas

• Software de trabajo por encima de la documentación exhaustiva

• Colaboración con los clientes por encima de la negociación de contratos

• Responder al cambio en lugar de seguir un plan

La definición de scrum se basa en el empirismo y el pensamiento ágil. El empirismo sostiene que el conocimiento proviene de la experiencia y que las decisiones se toman en función de lo observado. El pensamiento lean reduce el despilfarro y se centra en lo esencial. El marco de scrum es heurístico: se basa en el aprendizaje continuo y en el ajuste a los factores fluctuantes. Reconoce que el equipo no lo sabe todo al principio de un proyecto y que evolucionará a lo largo de la experiencia. El scrum está estructurado para ayudar a los equipos a adaptarse de forma natural a las condiciones y los requisitos de los usuarios cambiantes, con el cambio de prioridades integrado en el proceso y ciclos de lanzamiento cortos 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.

El marco de scrum está formado por un conjunto de valores, principios y prácticas que los equipos de scrum siguen para desarrollar un producto o servicio. Detalla los miembros de un equipo de scrum y sus responsabilidades, los "artefactos" que definen el producto y el trabajo que hay que hacer para crear el producto, así como las ceremonias de scrum que guían al equipo de scrum en su trabajo.

Un equipo de scrum es un equipo pequeño y ágil que se dedica a ofrecer incrementos de productos de forma comprometida.El tamaño de un equipo de scrum suele ser reducido, de unas 10 personas, pero es lo suficientemente grande como para llevar a cabo una cantidad considerable de trabajo en un sprint. El equipo de scrum debe componerse de tres roles específicos: el propietario del producto, el experto en scrum y el equipo de desarrollo.Y, puesto que los equipos de scrum son interdisciplinares, el equipo de desarrollo está formado por evaluadores, diseñadores, especialistas en experiencia de usuario e ingenieros de operaciones, además de desarrolladores.

El propietario del producto de scrum

Los propietarios son los referentes de sus productos. Se centran en entender los requisitos empresariales, de los clientes y del mercado y, en consecuencia, en priorizar el trabajo que debe realizar el equipo de ingeniería. Propietarios efectivos de los productos

• : crean y gestionan el backlog del producto.

• Colabora estrechamente con la empresa y el equipo para garantizar que todo el mundo entiende los elementos de trabajo del backlog del producto.

• Orienta al equipo claramente sobre qué funciones ofrecer a continuación.

• Decide cuándo lanzar el producto con una predisposición a una entrega más frecuente.

El propietario del producto no siempre es el gestor del producto. Los propietarios de los productos se centran en garantizar que el equipo de desarrollo ofrece el máximo valor a la empresa. Además, es importante que el propietario del producto sea una sola persona. Ningún equipo de desarrollo quiere una orientación contradictoria por parte de varios propietarios de productos.

El experto en scrum

Los expertos en scrum son los referentes de esta metodología dentro de sus equipos. Entrenan a los equipos, a los propietarios de los productos y a la empresa en el proceso de scrum y buscan formas de ajustar su práctica.

Un experto en scrum eficiente entiende perfectamente el trabajo que realiza el equipo y puede ayudar al equipo a optimizar su transparencia y su flujo de entrega. Como facilitador jefe que eres, programa los recursos necesarios (tanto humanos como logísticos) para la planificación de sprints, la puesta en pie, la revisión de sprints y la retrospectiva de sprints.

El equipo de desarrollo de scrum

Los equipos de scrum se lo curran. Son los defensores de las prácticas de desarrollo sostenible. Los más eficaces son los que están muy unidos, están ubicados en el mismo lugar

y tienen, por lo general, de cinco a siete miembros. Una forma de calcular el tamaño del equipo es utilizar la famosa "regla de las dos pizzas" acuñada por Jeff Bezos, el director ejecutivo de Amazon (el equipo debe ser lo suficientemente pequeño como para compartir dos pizzas). Los miembros del equipo tienen diferentes habilidades y se entrenan de forma cruzada para que ninguna persona se convierta en un cuello de botella en la entrega del trabajo. Los equipos de scrum fuertes se organizan y abordan sus proyectos con una actitud clara de "nosotros". Todos los miembros del equipo se ayudan unos a otros para garantizar un sprint exitoso.

El equipo de scrum impulsa el plan de cada sprint. Predicen la cantidad de trabajo que creen que pueden completar a lo largo de la iteración utilizando su velocidad histórica como guía. Mantener la duración de las iteraciones fija proporciona al equipo de desarrollo información importante sobre su proceso de estimación y entrega, lo que a su vez hace que sus previsiones sean cada vez más precisas con el tiempo.

Los artefactos de scrum ofrecen información importante que el equipo de scrum utiliza para definir el producto y el trabajo que hay que hacer para crearlo. Existen tres artefactos en scrum: un backlog del producto, un backlog de sprint y un incremento en tu definición de "finalizado". Son las tres constantes sobre las que un equipo de scrum debe reflexionar durante los sprints y a lo largo del tiempo.

• El backlog del producto es la lista de trabajo principal que se tiene que realizar y que debe mantener el propietario del producto o el gestor del producto. Es una lista dinámica de funciones, requisitos, mejoras y correcciones que actúa como entrada para el backlog del sprint. Se trata, básicamente, de la lista de tareas del equipo. El propietario del producto revisa, vuelve a priorizar y realiza el mantenimiento del backlog del producto constantemente porque, conforme más aprendemos o cambia el mercado, los elementos pueden dejar de ser relevantes o los problemas se pueden resolver de forma distinta.

• El backlog del sprint es la lista de elementos, historias de usuario o resolución de errores seleccionados por el equipo de desarrollo para implementarlos en el ciclo de sprint actual. Antes de cada sprint, en la reunión de planificación del sprint (de la que hablaremos más adelante en este artículo), el equipo elige en qué elementos del backlog del producto va a trabajar durante el sprint. Un backlog de sprint puede ser flexible y puede evolucionar a lo largo del sprint. No obstante, no se puede poner en peligro el objetivo fundamental del sprint, es decir, lo que el equipo quiere lograr con el sprint actual.

• El incremento (u objetivo del sprint) es el producto final que se puede usar y que se obtiene de un sprint. En Atlassian, solemos mostrar el incremento en la demo del fin del sprint, en la que el equipo muestra lo que se ha completado durante el sprint. Puede que no escuches la palabra "incremento" muy a menudo, ya que se utilizan otros términos para referirse a él, como la definición del equipo de "terminado": un hito, objetivo del sprint o incluso versión completa o epic lanzado. Depende de la definición de "terminado" de tu equipo y de cómo estableces tus objetivos de sprint. Por ejemplo, algunos equipos eligen publicar cosas para los clientes al final de cada sprint. Su definición de "terminado" coincidiría con "lanzado". No obstante, esta definición puede no ser la adecuada para otros tipos de equipos. Imagina que trabajas en un producto basado en servidor que solo se puede lanzar a los clientes una vez por trimestre. Puedes elegir que la duración de tus sprints sea de dos semanas, pero tu definición de "terminado" se referirá a completar parte de una versión más amplia que lanzarás en conjunto. Por supuesto, cuanto más se tarde en publicar software, mayor es el riesgo de que no esté a la altura.

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.

El marco de scrum incluye las prácticas, las ceremonias y las reuniones de scrum que los equipos de scrum celebran de forma regular. En las ceremonias ágiles es donde observamos la mayoría de las variaciones para los equipos. Por ejemplo, algunos equipos consideran que realizar todas estas ceremonias es engorroso y repetitivo, mientras que otros las utilizan como una sesión de control necesaria. Nuestro consejo es empezar usando todas las ceremonias para dos sprints y ver cómo va. Después, puedes realizar una retrospectiva rápida y ver en qué puntos es necesario realizar ajustes.

Esta es una lista de todas las principales ceremonias en las que puede participar un equipo de scrum:

1. Organización del backlog: este evento, a veces conocido como "limpieza del backlog", es responsabilidad del propietario del producto. Las principales tareas del propietario del producto son llevar el producto hacia la imagen concebida de este y tomarle el pulso constantemente al mercado y al cliente. Por lo tanto, utiliza el feedback de los usuarios y del equipo de desarrollo para mantener esta lista de tareas y, de este modo, contribuir a la priorización y a mantenerla limpia y lista para trabajar en ella en cualquier momento dado. Puedes informarte mejor sobre cómo mantener un backlog saludable aquí.

2. Planificación de sprints: todo el equipo de desarrollo planifica durante esta reunión el trabajo que se llevará a cabo (el alcance) durante el sprint actual. El experto en scrum dirige esta reunión, en la que el equipo decide el objetivo del sprint. A continuación, se añaden al sprint historias de usuario específicas a partir del backlog del producto. El equipo de scrum siempre alinea con el objetivo estas historias, cuya factibilidad de implementación durante el sprint también acuerda.

   Al final de la reunión de planificación, cada miembro 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 intervalo de tiempo propiamente dicho durante el cual el equipo de scrum colabora para terminar un incremento. Es bastante habitual que un sprint dure dos semanas, aunque a algunos equipos les resulta más fácil delimitar el alcance a una semana o dedicar un mes a conseguir un incremento valioso. Dave West, de Scrum.org, aconseja que cuanto más complejo sea el trabajo y mayores las incógnitas, más corto deberá ser el sprint. Pero lo cierto es que depende de tu equipo, y no debes tener miedo a cambiar lo que no funcione. Durante este periodo, el propietario del producto y el equipo de desarrollo pueden renegociar el alcance si es 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 intervalo de tiempo determinado para un sprint, debe seguir siendo coherente durante todo el periodo de desarrollo. De este modo, se ayuda al equipo a aprender de las experiencias pasadas y a aplicar esos datos relevantes a los sprints futuros.

4. Scrum o reunión rápida a diario: se trata de una reunión diaria de muy corta duración que tiene lugar a la misma hora (normalmente por las mañanas) y en el mismo sitio para facilitar las cosas. Muchos equipos intentan que la reunión no dure más de 15 minutos, pero eso es solo una pauta. A esta reunión también se la llama "reunión rápida diaria" para recalcar que debe ser breve. El objetivo del scrum diario es que todos los miembros del equipo estén en sintonía, se adecúen al objetivo del sprint y dispongan de un plan para las próximas 24 horas.

   La reunión rápida es el momento de expresar cualquier inquietud que tengas con respecto al cumplimiento del objetivo del sprint o de comunicar cualquier impedimento.

   Una forma habitual de llevar a cabo la reunión rápida es que cada miembro del equipo responda a tres preguntas en el contexto de alcanzar el objetivo del sprint: • ¿Qué hice ayer? • ¿Qué tengo pensado hacer hoy? • ¿Hay algún obstáculo? Sin embargo, hemos observado que la reunión se puede convertir rápidamente en un momento en el personal lee 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 durante esta para que el equipo pueda centrarse en el trabajo el resto del día. Por lo tanto, si se convierte en una lectura en voz alta de la agenda diaria, no dudes en cambiarla y dar rienda suelta a tu creatividad.

5. Revisión del sprint: al final del sprint, el equipo se reúne en una sesión informal para ver una demo del incremento o inspeccionarlo. El equipo de desarrollo les muestra los elementos del backlog que ya están "finalizados" a las partes interesadas y a los compañeros de equipo para pedirles feedback. El propietario del producto puede decidir si publica o no el incremento, aunque en la mayoría de los casos se publica.

   Es también en esta reunión de revisión cuando el propietario del producto repasa el backlog del producto a partir del sprint actual, lo que se puede aprovechar para la siguiente sesión de planificación de sprints. Si el sprint dura un mes, plantéate la posibilidad de limitar la duración de la revisión del sprint a cuatro horas como máximo.

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

En 2016, se añadieron cinco valores de scrum a la guía de metodología scrum. Estos valores proporcionan orientación hacia el trabajo, las acciones y el comportamiento del equipo de scrum. Se consideran esenciales para el éxito de un equipo de scrum.

Compromiso

Como los equipos de scrum son pequeños y ágiles, cada miembro del equipo desempeña un papel importante en el éxito del equipo. Por lo tanto, cada miembro del equipo debe aceptar comprometerse a realizar tareas que pueda completar y no comprometerse de más. Debe haber una comunicación frecuente sobre el progreso del trabajo, a menudo en monólogos.

Coraje

Para un equipo de scrum, el coraje es simplemente la valentía de cuestionar el statu quo o cualquier cosa que impida su capacidad de éxito. Los miembros del equipo de scrum deben tener el coraje y sentirse lo suficientemente seguros como para probar cosas nuevas. Un equipo de scrum debe tener el coraje y la seguridad de ser transparente en cuanto a los obstáculos, el progreso del proyecto, los retrasos, etc.

Enfoque

En el centro del flujo de trabajo de los equipos de scrum está el sprint, un período específico y centrado en el que el equipo completa una cantidad determinada de trabajo. El sprint proporciona estructura, pero también se centra en completar la cantidad de trabajo prevista.

Transparencia

Las reuniones rápidas diarias fomentan una franqueza que permite a los equipos hablar abiertamente sobre el trabajo en curso y los obstáculos. En Atlassian solemos hacer que nuestros equipos de scrum respondan a estas preguntas:

• ¿En qué trabajé ayer?

• ¿En qué estoy trabajando hoy?

• ¿Qué problemas me suponen un impedimento?

Esto ayuda a destacar el progreso e identificar los impedimentos. Asimismo, ayuda a fortalecer el equipo cuando todos comparten el progreso.

Respeto

La fortaleza de un equipo ágil reside en la colaboración y en reconocer que cada miembro del equipo contribuye al trabajo en un sprint. Celebran los logros de los demás y se respetan unos a otros, al propietario del producto, a las partes interesadas y al experto de scrum

.

Scrum es un marco de trabajo de metodología ágil tan popular que a menudo se confunde "scrum" y "ágil", y se piensa que es lo mismo. También existen otros marcos de trabajo, como "kanban", que es una alternativa popular. Algunas empresas incluso optan por seguir un modelo híbrido de scrum y kanban, que ha adquirido el nombre de "scrumban" o "kanplan", que es kanban con un backlog.  

Tanto scrum como kanban utilizan métodos visuales como el tablero de scrum o el tablero de kanban para realizar un seguimiento del progreso del trabajo. Ambos enfatizan la eficiencia y dividen las tareas complejas en bloques más pequeños de trabajo manejable, aunque sus enfoques hacia la consecución del objetivo son diferentes.

Scrum se centra en iteraciones más pequeñas y de longitud fija. Una vez finalizado el periodo para un sprint, se determinan las historias o las entradas de backlog del producto que se pueden implementar durante este ciclo de sprint. Sin embargo, en kanban, la cantidad de tareas o el trabajo en progreso (límite de WIP) que se implementará en el ciclo actual se fija al principio. El tiempo necesario para implementar estas funciones se calcula al revés.

Kanban no cuenta con un marco de trabajo tan estructurado como scrum. Aparte del límite de trabajo en progreso, está bastante abierto a la interpretación. Scrum, sin embargo, tiene varios conceptos categóricos aplicados como parte de su implementación, como la revisión de sprint, retrospectiva, scrum diario, etc. También insiste en la interdisciplinariedad, que es la capacidad de un equipo de scrum de no depender de miembros externos para lograr sus objetivos. Reunir a un equipo interdisciplinar no es tarea fácil. En ese sentido, el método kanban es más fácil de adaptar, mientras que el scrum puede considerarse como un cambio fundamental en el proceso de pensamiento y el funcionamiento de un equipo de desarrollo.

El marco de trabajo de scrum es sencillo en sí mismo. Las reglas, artefactos, eventos y funciones son fáciles de entender. Su enfoque semiprescriptivo ayuda, en realidad, a eliminar las ambigüedades en el proceso de desarrollo, a la vez que ofrece suficiente espacio para que las empresas introduzcan su toque personal.

La organización de tareas complejas en historias de usuario manejables hace que sea ideal para proyectos difíciles. Además, la clara delimitación de funciones y los eventos planificados aseguran que haya transparencia y propiedad colectiva en todo el ciclo de desarrollo. Los lanzamientos rápidos mantienen al equipo motivado y contentos a los usuarios, ya que pueden percibir progreso en poco tiempo.

No obstante, conocer en profundidad scrum puede llevar su tiempo, especialmente si el equipo de desarrollo está acostumbrado a un modelo de cascada habitual. Los conceptos de iteraciones más pequeñas, reuniones diarias de scrum, revisiones de sprint e identificación de un experto en scrum podrían suponer un cambio cultural difícil para un equipo nuevo.

Aun así, los beneficios a largo plazo sobrepasan con creces la curva de aprendizaje inicial. El éxito del scrum en el desarrollo de productos complejos de hardware y software para varios sectores y ejes verticales lo convierte en un marco solvente para adoptarlo en una organización.

Para aprender scrum con Jira, consulta este tutorial.