Scrum

Scrum: entiende de una vez por todas qué es, cómo aumenta drásticamente tus resultados y por qué usarlo

Por Roque Sales, CX & UX Manager en Zappts

Scrum es un framework para desarrollar y mantener productos complejos. La metodología fue definida en la guía escrita por sus creadores, Ken Schwaber y Jeff Sutherland, y titulada Guía de Scrum.

Dentro de este framework, las personas pueden tratar y resolver problemas igualmente complejos y adaptativos, mientras entregan productos de la mejor manera y con el mayor valor posible de forma productiva y creativa. El instrumento para ello es el desempeño de roles, eventos y artefactos unidos e integrados por reglas específicas.

Scrum se viene utilizando desde principios de la década de 1990 y sigue siendo relevante hasta el día de hoy. Esto se debe a que fue diseñado para ser inherentemente ligero y fácil de entender, pero extremadamente difícil de dominar, como un juego de póker.

Para explicar esto en profundidad, es necesario entender el paradigma inicial de la industria del desarrollo y cómo y por qué fue modificado. Comenzaremos conociendo un poco más sobre las metodologías de desarrollo.

Las Metodologías de Desarrollo

La Metodología Tradicional

En los inicios de la industria del desarrollo de software, la metodología utilizada para la gestión de proyectos se consolidó en fases bien definidas. Eran ellas:

• requisitos,
• análisis de requisitos para el diseño de la arquitectura,
• implementación mediante código/programación,
• pruebas,
• lanzamiento del producto,
• y soporte/mantenimiento.

Esta metodología fue posteriormente denominada Cascada (o Waterfall), porque cada fase se ejecuta jerárquicamente, una después de la otra. Una fase solo comienza cuando la anterior termina.

La Cascada se planifica en reunión con el cliente. La forma en que esto se hace no admite cambios, ya que todo se establece desde el inicio del proceso. Todos los requisitos, alcances de producto y de proyecto y, en consecuencia, la planificación de costos son fijos. No hay análisis de riesgos ni mayor participación del cliente hasta la entrega del producto finalizado.

Al ser un proceso tan basado en fases, resulta lento e inflexible. Esta demora impide que los clientes obtengan el desarrollo de entregables a la velocidad que necesitan.

A largo plazo, esto genera sistemas que ya se lanzaron con tecnologías obsoletas o con falta de funcionalidades específicas para la resolución del problema propuesto inicialmente, el cual puede haber cambiado durante el desarrollo del sistema.

Además, cada profesional del equipo es responsable por una parte del proyecto y no se comunica con frecuencia, sin mucha consideración por las “habilidades” de cada uno. Para contrarrestar estos problemas y reducir la burocracia involucrada, surgieron las metodologías ágiles.

Las Metodologias Ágiles

En las metodologías ágiles (muchas veces abreviadas como Ágil o Agile), el equipo discute y elabora en conjunto la entrega del producto final.

Existe una distribución de tareas conforme al conocimiento técnico y al desempeño de cada integrante. Esto garantiza la viabilidad del planeamiento al tomar en cuenta las peculiaridades de los individuos involucrados.

La implementación de proyectos se realiza de forma cíclica e iterativa. Un proyecto está compuesto por varios ciclos. Siempre se considera su efectividad en la resolución de los problemas y necesidades planteadas por el cliente. Muchas veces pasa por adaptaciones al final de cada ciclo de acuerdo con las demandas que van surgiendo.

Esto significa que los métodos ágiles son flexibles y proporcionan entregas constantes al cliente, siempre considerando su retroalimentación. Un contraste con el método tradicional de desarrollo de software.

La sinergia del equipo de desarrollo es indispensable para que la Agilidad funcione. Esta sinergia, en este caso, no se restringe solo al equipo. Debe extenderse a todos los individuos y áreas involucrados en el proyecto, para que el equipo de desarrollo pueda mantener su enfoque y alto rendimiento.

Al identificar fallas de gestión o de comunicación, el equipo debe utilizar todos los recursos disponibles en la organización para neutralizarlas. Siendo así autosuficiente en su gestión de riesgos, procesos y resultados.

Ejemplos y Características de Metodologías Ágiles

El concepto de metodología ágil se basó en el Lean Manufacturing. El Lean es un modelo de manufactura utilizado por la Toyota después de la Segunda Guerra Mundial. Pero solo fue formalizado en 2001, con el Manifiesto Ágil.

Similitudes comunes a todas las Metodologías Ágiles

Algunas de las metodologías ágiles más utilizadas en las empresas actualmente son Scrum y Kanban. Lo que tienen en común, además de la Agilidad, es un conjunto de prácticas basadas en ciertos valores, establecidos en el Manifiesto Ágil como:

• Priorizar a las personas y las interacciones por encima de los procesos y las herramientas. Todas las personas involucradas en el proceso deben trabajar juntas y diariamente, comunicándose de forma constante y abierta. Todos deben buscar siempre mantener un ambiente de trabajo sustentable que brinde apoyo, motivación y confianza.
• Valorar el buen funcionamiento del software por encima de la documentación exhaustiva. Software funcional hecho de forma rápida y con calidad es la medida primaria de progreso.
• Colaborar con el cliente por encima de negociar contratos.
• Responder a los cambios por encima de seguir un plan. Evaluar el progreso del proyecto en cada ciclo y aceptar cambios de requisitos incluso al final del desarrollo. Así el cliente puede obtener ventajas competitivas.
• Maximizar la cantidad de trabajo que no fue necesario al primar por la excelencia técnica de los miembros del equipo y por un diseño y usabilidad simples e intuitivos.
• Construir, mediante la convivencia diaria, equipos autoorganizables. Los miembros del equipo reflexionan sobre maneras de aumentar su productividad y efectividad con base en los resultados de cada ciclo. Así, ajustan su comportamiento con el fin de optimizar su sinergia y aumentar su frecuencia de entregas.

Diferencias entre Scrum y Kanban

Lo que los diferencia es:

• Scrum se trata de autogestión y de cómo los desarrolladores interactúan y qué hacen cuando no están escribiendo código.
• Kanban se trata de evitar el desperdicio de recursos y optimizar la producción. Esto se logra al limitar la carga de trabajo de cada desarrollador. Se crea una visualización del flujo de recursos en la línea de producción con post-its en un tablero.

Kanban es continuo y Scrum es iterativo. Scrum tiene ciclos cerrados con objetivos definidos que se repiten, mientras que Kanban es más adecuado para equipos que tienen trabajo no planificado por delante. Por ejemplo, problemas de soporte y funcionalidades solicitadas de forma emergente, ya que no tiene ciclos.

Ahora, después de este contenido introductorio, abordaremos Scrum. Definiremos qué es, mostraremos de dónde viene, y detallaremos todos sus roles, eventos, artefactos y reglas.

¿Y entonces, qué es Scrum?

Origen del término Scrum

El nombre proviene del rugby; en este deporte hay un movimiento llamado Scrum. Ocurre cuando los jugadores de ambos equipos forman un círculo alrededor de la pelota, apoyando sus cabezas y midiendo fuerzas para tomarla.

Scrum se considera una demostración de la fuerza y unión del equipo para alcanzar su objetivo.

Es por eso que la metodología ágil que aquí se aborda adoptó este mismo nombre.

Diferencia entre Scrum y Agile

Es común tener la impresión de que estos términos son iguales. Sin embargo, Agile es un conjunto de métodos y prácticas basados en los valores expresados en el Manifiesto Ágil.

Scrum, por su parte, no es un proceso ni una técnica para construir productos. Es una estructura metodológica (o framework) incremental que se utiliza para implementar el Desarrollo Ágil. Se pueden emplear varios procesos o técnicas para ello.

Scrum deja clara la eficacia de las prácticas de gestión y desarrollo de productos de las empresas en las que se implementa, de modo que estas puedan mejorar dichas prácticas.

El framework consiste en los equipos Scrum asociados a roles, desempeñados por miembros del equipo durante eventos, con la ayuda de artefactos.

Como se describe en la Guía de Scrum, cada componente dentro del framework sirve a un propósito específico y es esencial para el uso y el éxito de Scrum. Las reglas integran los eventos, roles y artefactos, administrando las relaciones e interacciones entre ellos.

¿De dónde surgió Scrum?

El creador de Scrum

Jeff Sutherland trabajó como militar en el ejército de los Estados Unidos durante 11 años. Después de ese período, decidió estudiar Medicina en la Universidad de Colorado. Terminó involucrándose en la recopilación de datos y el desarrollo de sistemas.

Durante los años 90, Sutherland vio un problema recurrente en su nueva área de interés. Empresas que demandaban proyectos de software con un cronograma apretado y un presupuesto inadecuado. Decidió encontrar una solución para este problema.

El gran diferencial de Scrum

Al investigar, Sutherland terminó llegando al Lean Manufacturing utilizado en la Toyota y en otras empresas japonesas. Con la ayuda de Ken Schwaber, creó la metodología Scrum basándose en este sistema de manufactura.

Después de que la eficacia de Scrum fue demostrada mediante una serie de éxitos, esta nueva metodología se popularizó rápidamente en la industria de desarrollo de productos.

Scrum representa el cambio de la visión algorítmica de proyectos a una visión heurística. Las personas y la autogestión son la clave para resolver problemas. Se priorizan en tareas individuales y se delegan a los miembros del equipo más preparados para cada una de ellas.

El Equipo Scrum

Los Equipos Scrum son autoorganizables y multifuncionales. Ser autoorganizable significa que los miembros son quienes eligen la mejor forma de realizar su trabajo, en lugar de ser dirigidos por personas ajenas al equipo. Ser multifuncional significa que un equipo tiene en sí todas las competencias necesarias para realizar el trabajo sin depender de agentes externos.

El modelo de equipo de Scrum fue pensado para optimizar la flexibilidad, la creatividad y la productividad. Generalmente un equipo tiene de tres a diez miembros. Cuando diez personas no alcanzan con el trabajo, el equipo se divide en dos. Nuevos miembros se agregan a cada nuevo equipo, junto con los miembros originales.

Dependiendo del tamaño del proyecto y de la cantidad de equipos, se recomienda aplicar el Scrum of Scrums, que abordaremos más adelante. Los miembros del equipo desempeñan roles específicos.

Product Owner: El Dueño del Producto

El rol de esta persona es representar los intereses del usuario final, siendo el puente entre el equipo técnico, representado por el Scrum Master, y los demás stakeholders. El PO estará siempre equilibrando las demandas de estas dos partes.

Este miembro tiene autoridad para decir qué será parte del producto final y qué no. Normalmente es un usuario clave del sistema, o un usuario con buena comprensión de los requisitos y de lo que él y otros usuarios necesitan.

¿El Product Owner necesita saber Programar?

Puede ser tanto alguien con formación técnica (alguien que fue desarrollador front end o diseñador UX, por ejemplo) como alguien sin ella (un analista de negocios, el CEO de la empresa o el propio cliente).

Aunque está listado como parte del equipo Scrum, el Product Owner no es un elemento integrante del mismo.

Su presencia y disponibilidad para el equipo son constantes, pero no forma parte del proceso de desarrollo. Lo que hace está más ligado a estrategias de negocio y entrega de valor. Su función es mucho más “política” que técnica.

El Product Owner es responsable del Product Backlog, que es una lista de tareas que describen las funcionalidades necesarias del producto final y ordenadas por prioridad. Quién determina el grado de prioridad de cada tarea es el Product Owner, basándose en el valor de negocio y el ROI previsto de las mismas.

Para ello, debe tener un entendimiento claro y profundo de la visión del producto, tener autonomía para la toma de decisiones, y ser lo suficientemente comunicativo para poder transmitirlas con claridad al resto del equipo.

Scrum Master: El Dueño del Proceso

El rol del Scrum Master es garantizar que los valores y reglas de Scrum sean seguidos cotidianamente por el resto del equipo. Es responsable de decidir el tamaño de los ciclos de desarrollo de software. En Scrum, estos ciclos se denominan Sprints. Cada Sprint puede durar de una a cuatro semanas.

Además, es el intermediario entre el equipo de desarrolladores y el Product Owner. El Scrum Master sirve de “alivio” para que el Product Owner pueda enfocarse en las estrategias de negocio y en la entrega de valor con los demás stakeholders. Mientras tanto, el Scrum Master lidia directamente con el equipo de desarrolladores y gestiona el Sprint Backlog.

¿Por qué Dueño del Proceso?

Al Scrum Master se le puede llamar informalmente Dueño del Proceso porque es el miembro que equilibra las relaciones internas y externas del equipo Scrum. Lidia directamente con el Product Owner y con el equipo de desarrolladores, pero puede transitar entre otros departamentos de la empresa o entre otros stakeholders, por ejemplo.

Esto se debe a que la otra responsabilidad del Scrum Master, además del Sprint Backlog, es proteger a los desarrolladores. Filtra qué información llega a los “devs” y evita interferencias en el Sprint, trabajando siempre para resolver cualquier impedimento al progreso del equipo.

Durante el Sprint, este miembro actúa como mentor y gestor de los desarrolladores, conversando con ellos constantemente para resolver posibles impedimentos. “Mi computadora tiene un problema y por eso no puedo programar”, “no tengo suficiente conocimiento en esta tecnología para ejecutar esta tarea”, “el compañero que se sienta a mi lado me está molestando”, “me interrumpen muchas veces durante el día”, entre otros obstáculos técnicos o personales, por ejemplo.

El SM siempre mantiene el Sprint Backlog actualizado para analizar el desempeño individual y colectivo. Además, ve qué tareas se completan y en cuánto tiempo, así previendo y ordenando qué tareas deberán ser pospuestas al siguiente Sprint.

La estimativa del trabajo que no puede ser pospuesto al próximo Sprint se calcula todos los días y se coloca en un gráfico llamado Sprint Burndown Chart (o solo Burndown Chart — Gráfico de Quemado, en traducción libre).

Mentor y Facilitador para los Desarrolladores

Al ser mentor de los desarrolladores, el SM necesita mantenerlos motivados y asegurarse de que las tareas del Sprint se estén ejecutando de la manera correcta. Lo hace tomando en cuenta las solicitudes del PO y de los demás stakeholders.

Sin embargo, la autoridad y autonomía del SM son menores que las del PO, ya que su alcance de acción está restringido al equipo de desarrolladores.

Las medidas de protección que puede tomar terminan dependiendo de la colaboración de agentes externos al equipo Scrum. Por ello, es importante que el SM sea un buen negociador y sepa conversar con los stakeholders de forma amigable.

¿El Scrum Master necesita saber Programar?

La formación técnica del Scrum Master en el área de software, al igual que la del Product Owner, es opcional. Sin embargo, es interesante que entienda al menos lo básico de los conceptos de desarrollo y de las tecnologías aplicadas al proyecto de su equipo. Esto le dará más confianza al garantizar la calidad de los entregables.

El Scrum Master no es responsable de la ejecución de las tareas del Sprint, pero debe asegurar que dicha ejecución se realice de la mejor manera posible dentro de las capacidades, limitaciones y acuerdos del equipo.

Desarrolladores

Cuando se habla de Equipo Scrum, los primeros miembros en mencionarse generalmente son los desarrolladores de software.

En el equipo de desarrolladores, es necesario que los miembros estén asignados de manera que cualquier problema en el software pueda ser resuelto por ellos en su totalidad, sin ayuda externa.

No existe necesariamente una división de los miembros por funciones desempeñadas individualmente. Como, por ejemplo, diseñador, front end, back end, arquitecto, analista de pruebas…

En Scrum, todos los miembros trabajan juntos para entregar al final de un Sprint aquello que fue prometido al inicio del mismo. Por eso, todos terminan siendo fullstack en mayor o menor grado.

Scrum se basa en reflexionar sobre el desempeño pasado con transparencia y compromiso. Todos los integrantes saben qué está haciendo cada uno y cómo progresa cada tarea. Todos se comprometen a cambiar lo que sea necesario para mejorar el desempeño del equipo.

Es importante que el equipo permanezca ágil, integrado y comunicativo. Formar parte de un equipo sinérgico termina ayudando naturalmente a todos los miembros a mantenerse motivados y comprometidos en crear un proceso más eficiente.

Artefactos Scrum

Los Artefactos Scrum son difusores de información que representan trabajo o valor. Proporcionan transparencia al brindar oportunidades de inspección y adaptación del proceso de desarrollo.

Fueron diseñados específicamente para maximizar la transparencia de información, de modo que todos los stakeholders tengan el mismo entendimiento del contenido de cada artefacto.

Los artefactos obligatorios de Scrum son solo el Product Backlog, el Sprint Backlog y el Incremento de Producto. Sin embargo, además de estos existen artefactos opcionales, cuyo uso es decidido por el equipo. Los artefactos, tanto obligatorios como opcionales, son:

Product Backlog: la lista de deseos

El Product Backlog —el Respaldo del Producto, en traducción libre— representa un listado de las funcionalidades deseadas por el cliente. De común acuerdo entre el Product Owner y el cliente, deben ser desarrolladas con mayor urgencia.

Los elementos discriminados en este backlog son priorizados, pospuestos o descartados por valor de negocio por el Product Owner, y pueden ser tareas técnicas o no.

El Product Backlog no necesita estar completo desde el inicio del proyecto. Al comienzo, los desarrolladores pueden trabajar solo con lo que sea más simple o evidente para el sistema diseñado. Después, a medida que los Sprints se concluyen y el software se incrementa, se pueden agregar más cosas al backlog.

Así, con negociación entre los stakeholders y análisis continuo de las funcionalidades entregadas, este backlog puede crecer y cambiar, siempre tomando en cuenta lo que se aprende sobre el producto y sobre la experiencia del usuario.

Sprint Backlog: las tareas de este ciclo

Durante el Sprint Planning, que abordaremos en el tema de Eventos Scrum, el PO prioriza los elementos del Product Backlog y los describe para el SM y el equipo.

El equipo entonces determina cuáles de los elementos descritos podrá completar durante el próximo Sprint. De ahí surge el Sprint Backlog, que no es más que una lista de tareas o pendientes.

Estos pendientes se distribuyen entre los integrantes del equipo por el Scrum Master, de acuerdo con la percepción del equipo sobre las habilidades de cada miembro y sobre el tiempo que se empleará para completarlos.

Los cambios de alcance en los elementos del Sprint Backlog después del inicio del Sprint deben evitarse al máximo. Obstaculizan el avance del Sprint y desenfocan al equipo en su trabajo. Si es necesario modificar algo, el Scrum Master debe negociar con los desarrolladores y con el Product Owner sobre cómo y qué cambiar y cuáles son los motivos para dicho cambio.

User Stories: Historias de Usuario

Hasta ahora, nos hemos referido a los elementos de los backlogs como tareas, pero no todos los equipos Scrum lo llaman así. Algunos prefieren hablar de User Stories, o Historias de Usuario.

“Tarea” es una palabra genérica para los elementos de los backlogs y puede usarse de forma aislada o conjuntamente con “Historias”.

El cerebro humano funciona mejor cuando escucha historias. Tenemos mayor comprensión y empatía cuando un interlocutor nos transmite los motivos de sus elecciones y describe su trayectoria. En este contexto, el interlocutor es el usuario del sistema.

Así, resumidamente, las User Stories son descripciones simples y breves de una funcionalidad a ser implementada en el software.

Se cuentan desde el punto de vista del usuario, señalando por qué motivo desea que el software sea capaz de realizar esa función. Generalmente, las Stories se escriben en este formato:

“Como USUARIO, quiero FUNCIONALIDAD para que RAZÓN”.

Por ejemplo: “Como gerente de inventario, quiero poder agregar o eliminar productos del registro de inventario, para que haya un mayor control del flujo de ventas”.

Las User Stories generalmente se escriben en tarjetas o en post-its. Pueden disponerse en paredes, pizarras o mesas para facilitar el planeamiento y la discusión. Esta disposición también puede realizarse en herramientas digitales, como Trello.

Esto ayuda en la visualización de las funcionalidades. El enfoque cambia de la escritura sobre recursos a la discusión activa y colectiva sobre los mismos. Así, el equipo está ejercitando los principios Scrum de comunicación y transparencia.

¿Cómo detallar las User Stories?

Si es necesario, se pueden agregar detalles a las Historias de dos maneras:

• desglosando una Historia más compleja en otras más pequeñas y simples,
• o agregando condiciones de aceptación a la tarjeta que la describe.

En el primer escenario, se presume que las nuevas Stories creadas contienen el detalle añadido.

En el segundo escenario, las condiciones de aceptación son solo un obstáculo colocado para garantizar mayor cuidado en el desarrollo de esa funcionalidad. Es natural que todas se cumplan como consecuencia de dicho cuidado.

Cualquiera en Scrum puede escribir User Stories. Corresponde al Product Owner aceptarlas en la fila de prioridades que es el Product Backlog. A lo largo del ciclo de vida del proyecto, se espera que todos los miembros del equipo terminen escribiendo una Historia en algún momento.

La identidad del autor de la User Story es irrelevante. Lo que realmente importa es quién va a discutir sobre ella y trabajar en ella durante el proyecto.

De la misma manera, no es obligatorio que todos los elementos de los backlogs se escriban en formato de Historia. A veces, es mucho más fácil, rápido e intuitivo simplemente escribir palabras clave, casos de uso o dibujar diagramas o diseños simples. Scrum describe qué se necesita hacer, pero no hay reglas sobre cómo hacerlo.

Story Points: la unidad de medida del progreso

Un Story Point es una medida abstracta del esfuerzo necesario para implementar una User Story. Al igual que las User Stories, el uso de Story Points y de Burndown Charts es opcional.

En resumen, es un número que informa al equipo sobre el nivel de dificultad de la Historia. Un nivel relacionado con particularidades, riesgos y esfuerzos involucrados en la ejecución de cada Historia específica.

En la mayoría de los casos, un Story Point usa una de las siguientes dimensiones:

• La Secuencia de Fibonacci: 1, 2, 3, 5, 8, 13, 21;
• Tamaños análogos a los tallas de camiseta: XS, S, M, L, XL;
• O la secuencia simple del 1 seguido de múltiplos de 2: 2, 4, 8, 16.

Los Story Points representan estimaciones de alto nivel y generalmente se realizan después del Sprint Planning. El PO, el SM y el equipo de desarrollo hacen una estimación aproximada en la que verifican si:

• el planeamiento se condujo de forma eficiente;
• hay información suficiente para cumplir todo lo que se designó para ese Sprint; y
• las User Stories se dividieron de forma razonable entre los miembros del equipo.

Las estimaciones basadas en medidas de tiempo como horas o días, por el contrario, son estimaciones de bajo nivel. Representan el esfuerzo tangible (relación hora/hombre de la mano de obra) necesario para completar esa User Story.

¿Los Story Points son Medidas de Tiempo?

En realidad, los Story Points y las medidas hora/hombre tienen propósitos diferentes para situaciones diferentes y no deben compararse ni utilizarse de forma exclusiva. Lo correcto es evitar relacionarlos para que el Sprint y el lanzamiento del producto se ejecuten mejor.

La hora/hombre no es igual para todos los desarrolladores, pero los Story Points sí. Esto permite que personas con diferentes velocidades y niveles de habilidad puedan llegar a un consenso.

Asignar determinada cantidad de Story Points a una User Story es más flexible que asignar una cantidad de horas o días. Así, la ventana de entrega de la Story termina siendo la misma para todos los miembros del equipo.

Cada Story Point representa una distribución normal de tiempo. Por ejemplo: un Story Point puede representar un intervalo de 4 a 12 horas, dos Story Points serían de 10 a 20 horas, y así sucesivamente.

Esta distribución de tiempo es desconocida durante la estimación, ya que al usar Story Points no es necesario saber cuánto tiempo se lleva, solo se necesita tener una indicación aproximada de cuánto tiempo tomará concluir aquello. El Planning Poker se utiliza para asignar los Story Points.

Burndown Charts: una visión general del proyecto

El monitoreo del progreso del proyecto, en Scrum, generalmente se realiza con un gráfico llamado Burndown Chart al final de cada Sprint.

Existen varias formas de Burndown Chart. La forma utilizada es determinada por el Scrum Master en conversación con los desarrolladores.

El trabajo que aún resta puede mostrarse en la unidad preferida del equipo, que usualmente son Story Points. Su finalidad es permitir que el proyecto esté en camino para entregar la solución esperada dentro del cronograma deseado.

El Burndown no es obligatorio en absoluto. Es solo una herramienta para visualizar el progreso en el proyecto y en el Sprint, y ese progreso es lo que debe medirse obligatoriamente. Lo ideal es que el SM lo mida diariamente.

El equipo puede elegir el método que quiera, incluyendo otros tipos de gráficos u otras métricas, siempre que haya una forma consistente de inspeccionar el progreso del producto.

Incremento de Producto: las funcionalidades o entregables

Al finalizar el primer Sprint de un proyecto, el equipo Scrum necesita, aunque sea de forma rudimentaria, resolver el problema del usuario final. De ahí viene el concepto de MVP (Minimum Viable Product — Mínimo Producto Viable, en traducción libre).

El MVP se utiliza mucho en el mundo del emprendimiento y las startups, ya que la mayoría de estas pequeñas empresas innovadoras surgen precisamente con un MVP.

La gran diferencia de Scrum con la Cascada está en este concepto, ya que las iteraciones se basan en entregar incrementos del producto a lo largo del tiempo. Esto es contrario al paradigma antiguo donde había una única gran entrega al final del proyecto.

Para que el Sprint termine con éxito, es necesario que su objetivo haya sido alcanzado. Este objetivo es definido por el equipo y generalmente implica la entrega de al menos un incremento de software que esté funcionando.

Por eso “incremento”, “entregable” y “funcionalidad” terminan siendo palabras intercambiables en este contexto. El incremento debe ser validado por los analistas de pruebas y por el PO para ser incorporado al producto final.

Eventos Scrum

Los Eventos se utilizan en Scrum para crear regularidad y minimizar la necesidad de reuniones imprevistas. Todos los eventos son timeboxed, lo que significa que tienen un tiempo mínimo y un tiempo máximo de duración.

Todos los Eventos están vinculados al Sprint, que es el principal de ellos, y todos se repiten cada vez que un Sprint termina y otro comienza. De ahí la naturaleza iterativa de Scrum.

Antes de que el Sprint comience, idealmente en la primera Sprint Planning del proyecto, su duración es fijada por el Scrum Master. No puede ser reducida ni aumentada.

Los eventos restantes también tienen timeboxes pero pueden terminar antes de lo previsto si el objetivo proposto para cada uno de ellos se alcanza más rápido. Así se garantiza que una cantidad apropiada de tiempo sea empleada sin permitir desperdicio en el proceso. Los Eventos Scrum son:

Sprint Planning: el planeamiento

Antes de iniciar un Sprint, el Product Owner presenta para el Scrum Master y los desarrolladores los elementos más prioritarios del Product Backlog. El equipo selecciona los elementos que formarán parte del Sprint Backlog.

Después de esto, el SM y el PO se retiran de la reunión para que el equipo “dev” defina técnicamente cómo se desarrollarán los elementos del Sprint Backlog. Esta definición es asistida por el Planning Poker, que veremos más adelante en el artículo. Estas son las dos etapas del Sprint Planning.

Durante la primera etapa, el Product Owner presenta los elementos del Product Backlog desde la óptica de negocios, mostrando el razonamiento utilizado por él para definir qué elementos tienen mayor prioridad. El equipo puede aclarar dudas con el PO y ya imaginar cuáles son las posibles soluciones técnicas para cada elemento, una vez que estos elementos formarán el Sprint Backlog.

Una vez formado el Sprint Backlog, el equipo Scrum completo definirá un objetivo para el Sprint, describiendo de forma sucinta qué debe ser el enfoque del equipo para esta iteración.

Ya durante la segunda etapa, los desarrolladores se reúnen para trazar el planeamiento técnico de cada elemento del Sprint Backlog. Cada elemento se desglosa en tareas menores o se convierte en User Stories si es necesario. Se estima el tiempo que se empleará en ellos. Esta estimación generalmente se realiza con el Planning Poker.

El análisis de la efectividad del Sprint Planning se realizará en el Sprint Review.

Es importante que los miembros del equipo recuerden cualquier disponibilidad, período de vacaciones, feriados, viajes u otro detalle de programación que ocurra durante el Sprint y que pueda afectar su avance. Así, podrán estimar con la mayor precisión posible cuál será la cantidad de trabajo realizada.

Planning Poker: el juego y sus reglas

Los equipos que utilizan Story Points también suelen usar un ejercicio similar a un juego de póker. Las cartas de baraja se utilizan para estimar el esfuerzo que se empleará en cada tarea.

El equipo de desarrolladores tomará un elemento del backlog y discutirá brevemente sobre él. Cada uno de los integrantes pensará en una cantidad de Story Points que considere adecuada para su ejecución. Todos toman y muestran a los demás una carta de baraja con el número equivalente a su estimación.

Si todos están de acuerdo, el ejercicio termina aquí. Si hay desacuerdo, cada desarrollador debe entender la lógica detrás de las diferentes estimaciones.

La estimación debe ser una actividad de alto nivel. Esto significa que las discrepancias no pueden ser muy notorias. Si algunos miembros estimaron 1 Story Point mientras otros estimaron 5, conversen un poco más hasta que esos números se acerquen.

El equipo debe tener un consenso sobre el número máximo de Story Points, horas de trabajo o cualquier que sea la medida elegida por los integrantes.

Las Sprint Retrospectives son el momento para que el equipo reflexione sobre la precisión y efectividad de iteraciones anteriores de ese proyecto. Esta reflexión incluye la precisión de sus estimaciones.

¿Qué tan Preciso se Necesita Ser?

En una sesión de Planning Poker, imaginen que la mitad del equipo estimó 3 Story Points y la otra mitad estimó 5 Story Points para una Historia.

Es fácil aceptar 4 Story Points como la estimación y pasar a la siguiente tarea, pero el equipo debe tener la sinergia y madurez suficientes para entender que no es productivo hacer eso. Solo genera una falsa sensación de precisión. No es necesario ser 100% preciso. Lo necesario es ser lo suficientemente preciso para garantizar el buen avance del Sprint y planificar todo con antelación.

Además, puede haber pérdida de transparencia en el proceso si se toma la decisión más fácil. Esta decisión genera una disminución en la comunicación del equipo. Quizás 5 Story Points sea una mejor estimación y nunca lo sabrán si no conversan al respecto.

Sprint y sus Estados (To Do, Doing, Done)

Un Sprint es un ciclo con principio y fin, con una duración de tiempo predeterminada por el Scrum Master. El Sprint es el centro de Scrum. Todos los demás eventos y artefactos giran en torno a él y a su ejecución.

Al final de cada Sprint, hay una nueva funcionalidad por validar o rechazar por el Product Owner. Después, implementada de forma definitiva o modificada hasta que quede dentro de las reglas y valores de negocio propuestos por él.

La Duración de los Sprints

El SM debe analizar la estabilidad de los alcances de producto y de proyecto antes de definir la duración de los Sprints. Si uno de ellos es muy mutable y esos cambios están relacionados con el tiempo de entrega, es más prudente que los Sprints tengan una o dos semanas de duración. Si los recursos disponibles para los alcances son más estables, Sprints de dos a cuatro semanas pueden funcionar mejor.

Como ya se mencionó en este artículo, no es común ni recomendable que los Sprints de un proyecto varíen de tamaño, ya que esto genera inestabilidad e imprevisibilidad en la velocidad de ejecución del mismo.

El Sprint termina cuando el tiempo de duración definido para él se agota o cuando el objetivo definido durante el Sprint Planning se alcanza. Para que el Sprint termine con éxito, es necesario que haya entrega de un incremento de software.

Durante el Sprint, cada tarea tiene un estado. Este estado sirve para indicar en qué etapa se encuentra su ejecución.

Estados del Sprint

Algo común, y similar a lo que se hace en Kanban, es dividir las tareas del Sprint por columnas en un tablero físico o virtual. Cada una equivale al estado de una tarjeta. Esta tarjeta transita por las columnas a medida que lo que está descrito en ella se implementa. Los Estados más comunes son:

• Backlog. Designa el Product Backlog.
• Blocked (Bloqueado). Contiene tareas que no podrán ser ingresadas en To Do por algún impedimento.
• To Do (Por Hacer). Designa el Sprint Backlog.
• Doing o Work in Progress (Haciendo). Lista las tareas que se están realizando, con indicación del desarrollador responsable en cada tarjeta.
• Verify (Verificar). Donde están las tareas ya desarrolladas que necesitan ser probadas.
• Done (Hecho o Listo). Son las tareas ya concluidas.

Los Estados obligatorios son solo To Do, Doing y Done.

Para que todos los stakeholders estén alineados sobre qué significa la conclusión de una tarea, existe un documento llamado Definition of Done (Definición de Listo). En él se encuentra la descripción genérica de cuáles son los pasos mínimos para la conclusión de entregables.

Este documento es como una garantía de la calidad de los incrementos. Puede ser modificado a lo largo de las iteraciones, a medida que se revisa en cada Sprint Review.

Es obligatorio que todos los stakeholders estén de acuerdo con la Definición de Listo para que haya transparencia y confianza entre ellos durante el proyecto.

Daily Scrum: las reuniones diarias

Todos los días, el equipo se reúne para conversar sobre el avance del Sprint actual. El objetivo aquí es promover el alineamiento continuo entre todos los miembros del equipo y ayudar al Scrum Master a prever qué podrá realmente entregarse al final del Sprint.

Esta reunión diaria se llama Daily Scrum o simplemente Daily. Suele durar alrededor de 15 minutos. Puede extenderse con miembros específicos del equipo dependiendo de lo que se converse y de posibles impedimentos que puedan surgir.

La participación del equipo completo es obligatoria. Para este evento, siempre incluye al Scrum Master pero no siempre al Product Owner. La participación de otros stakeholders, como los gerentes de otros departamentos o el cliente, es menos común pero puede ocurrir; sin embargo, serán solo oyentes.

La Daily no debe profundizar en discusiones técnicas. Cualquier cuestión que surja durante ella debe tratarse solo con los miembros directamente involucrados o afectados por dicha cuestión. Si es necesario, lo que se discutió en esta etapa se comunica de forma resumida a los miembros que no estaban involucrados.

Las preguntas que deben responder los desarrolladores en la Daily, reportando así su progreso al Scrum Master, son:

1. “Lo que hice ayer” o “lo que hice desde la última Daily”;
2. “Lo que planeo hacer hoy” o “lo que planeo hacer hasta la próxima Daily”; y
3. “Existen los siguientes impedimentos para que pueda concluir mis tareas” o “no existen impedimentos para mis tareas”.

Con base en lo que se respondió, el Scrum Master debe trabajar para eliminar los impedimentos. En caso de que no existan, debe trabajar para que lo que falta en este Sprint se concluya con calidad y dentro del plazo.

Sprint Review: revisando el ciclo

Después de que el Sprint finaliza, el equipo muestra cómo se realizó el desarrollo de los entregables. Normalmente asisten al Sprint Review el Product Owner, el Scrum Master y el cliente o los stakeholders que lo representan. El enfoque de la reunión es demostrar las nuevas funcionalidades con la menor cantidad posible de errores y funcionando de manera relativamente aceptable. Lo ideal es que la duración del Review no sea mayor a dos horas.

Los incrementos deben revisarse de acuerdo con el objetivo del Sprint que fue acordado en el Sprint Planning. El equipo debe siempre esforzarse por alcanzar este objetivo.

Sprint Retrospective: reflexionar para mejorar

El último Evento Scrum es la Retrospectiva. El equipo analiza el rendimiento del Sprint que acaba de finalizar y conversa sobre maneras de mejorar sus procesos de trabajo para el siguiente Sprint. Se discuten y exponen dificultades y cómo el equipo cree que puede evitarlas.

Esto está relacionado con algunos factores. Son ellos:

• el esfuerzo de cada desarrollador,
• la distribución de tareas hecha en el Sprint Planning,
• y los impedimentos señalados en la Daily, además de las decisiones del SM para resolverlos.

El equipo decide cómo actuar a partir de ahí para mejorar su eficiencia en el siguiente Sprint. Los integrantes deben apuntar al aumento de su productividad sin pérdida de calidad.

Al igual que la Daily, la Retrospectiva también tiene una duración ideal. En este caso es de una hora, pero los involucrados en algún asunto más complejo pueden continuar conversando después de la reunión.

Una de las técnicas de Retrospectiva es el start-stop-continue:

• “Debemos empezar a hacer…” (start)
• “Debemos dejar de hacer…” (stop)
• “Debemos continuar haciendo…” (continue)

Scrum of Scrums: la solución para proyectos grandes

Scrum of Scrums o Meta Scrum es un mecanismo de escalabilidad creado en IDX Systems (actual GE Healthcare).

Es definido por la Agile Alliance como “una técnica para escalar Scrum hasta grandes grupos (más de una docena de personas), consistente en dividir los grupos en equipos ágiles de 5 a 10 integrantes”.

Además, es definido por Jeff Sutherland como “responsable de adecuar el software de todos los equipos a la Definición de Listo al final del Sprint, o a lanzamientos durante el Sprint”. Cuando trabajaban en IDX, Jeff Sutherland y Ken Schwaber lo implementaron como una técnica para dimensionar equipos Scrum individuales al nivel corporativo.

La Gestión de un Scrum of Scrums

La coordinación de los varios equipos se realiza en una reunión del Scrum of Scrums. Esta reunión puede realizarse diariamente, dos veces por semana o, como mínimo, una vez por semana.

Cada equipo Scrum tiene su representante. Puede ser el Scrum Master u otro miembro del equipo elegido por los demás integrantes. Si el tema que uno de los equipos quiere discutir es muy técnico, tanto el miembro del equipo con formación técnica como el Scrum Master pueden querer participar.

La reunión del Scrum of Scrums se ejecuta de forma muy similar a la Daily Scrum. Aunque no tiene una duración de tiempo predeterminada, es común que dure 15 minutos, como la Daily de Scrums comunes. En la reunión del Scrum of Scrums, cada “embajador” de cada equipo Scrum debe responder:

1. Lo que su equipo logró desde la última reunión;
2. Qué problemas ocurrieron (si ocurrieron) y cómo afectaron negativamente a su equipo;
3. Lo que su equipo desea lograr antes de la próxima reunión;
4. Qué acciones de su equipo en futuros Sprints pueden interferir con los Sprints de los otros equipos;
5. Y si su equipo ve alguna interferencia proveniente de otros equipos.

El propósito de la reunión del Scrum of Scrums es asegurar la coordinación e integración de los resultados de los varios equipos, eliminando todos los impedimentos. Para ello, puede haber la participación de dos o más equipos trabajando juntos por un tiempo o renegociando responsabilidades.

Esto debe gestionarse con un Product Backlog propio del Scrum of Scrums y mantenido por el Scrum Master elegido como responsable de este proceso. O, también, por un Gerente de Proyectos que tenga el Product Backlog del Scrum of Scrums como su principal demanda.

Cómo Organizar el Scrum of Scrums

Un framework Scrum of Scrums puede ser eficaz incluso en organizaciones más grandes con múltiples equipos. O en proyectos con Scrums distribuidos en diferentes ubicaciones. Siempre que las reuniones correspondientes se conduzcan adecuadamente.

El énfasis debe estar en la coordinación de los varios equipos y en la resolución de impedimentos. El objetivo es garantizar que los equipos individuales cumplan sus metas. Así, el objetivo general del proyecto de todos los equipos se alcanzará.

El desperdicio de tiempo, trabajo y recursos se reduce al máximo por un equipo formado específicamente para ayudar al Scrum Master o Gerente de Proyectos encargado del Scrum of Scrums. Los miembros son seleccionados de cada Scrum o son integrantes exclusivos.

Esto garantiza el mantenimiento de la transparencia y buena comunicación entre todos los equipos Scrum. Ken Schwaber lo llamó Integration Scrum (Scrum de Integración) en su libro The Enterprise and Scrum (“Las Empresas y el Scrum”, en traducción libre). Tener al menos un lanzamiento cada tres meses es la meta.

Cómo implementar Scrum en su empresa

La implementación de Scrum tiene mucho que ver con la implementación de la Transformación Digital. Además de que Scrum es una herramienta de Transformación Digital, ambos procesos dependen directamente de cambios en la cultura organizacional.

Estos cambios solo pueden ocurrir de forma efectiva si se realizan gradualmente y con mucho compromiso de los líderes de la empresa y de los colaboradores. Los líderes siempre tendrán que sopesar los pros y contras con transparencia frente a sus equipos, buscando integrar todos los departamentos de la empresa.

Metodologías Ágiles para Organizaciones

Lo que sucede en implementaciones organizacionales de métodos ágiles no es el uso de Scrum propiamente dicho, sino de frameworks modificados.

También se basan en los principios del Manifiesto Ágil, pero con la integración de áreas ya considerada desde su concepción.

Un ejemplo de estos frameworks es SAFe, que aborda todas las capas de una organización. Dean Leffingwell, el creador de SAFe, lo define como “una estructura para implementar prácticas ágiles a escala corporativa”.

Transición hacia Scrum

La transición de tradicional a ágil debe ser cuidadosa y muy bien alineada internamente. Al igual que cualquier otro cambio de cultura organizacional, debido al impacto que traerá a los colaboradores.

Los equipos de cada área deben ser multidisciplinarios. Los silos organizacionales deben reducirse al máximo para que la sinergia entre áreas sea siempre priorizada.

Esta sinergia y multidisciplinariedad ayudarán a la Agilidad, ya que colaboradores competentes en varias frentes podrán auxiliarse mutuamente y aportar diversas perspectivas a la empresa.

Se espera que algunos de los colaboradores demuestren resistencia al proceso de transición. Ahí es donde encaja el rol principal de los líderes de las áreas. Deben alinear expectativas de forma siempre transparente y explicar cuáles serán las mejoras obtenidas para cada área con la implementación de Scrum — o de cualquier otra metodología ágil.

Casos de éxito de Scrum

Scrum es una de las herramientas que pueden formar parte de la Transformación Digital. Por este motivo, algunos de los casos de éxito de Scrum fueron mencionados en nuestro artículo de Transformación Digital.

Dos de los casos más emblemáticos son el de GE Healthcare (anteriormente IDX Systems) y el del FBI. El caso de GE fue mencionado en la sección de Scrum of Scrums de este artículo. Está disponible traducido íntegramente aquí en nuestro blog.

En Zappts, los equipos de desarrollo se gestionan con Scrum. Cada equipo está dedicado a cada proyecto, sin recibir demandas de proyectos paralelos. Esto garantiza la agilidad y el buen avance de los Sprints. La calidad de las soluciones que ofrecemos a los clientes está asegurada de esta forma.

---

Trackbacks/Pingbacks

• Gestión de Squads Remotas | Zappts Blog – […] mencioné, optar por un modelo de trabajo ágil como el Framework Scrum nos permite una serie de herramientas, como…
• Desentrañando el Serverless – Cloud Computing | Zappts Blog – […] acompañando los contenidos de nuestro blog. Tenemos artículos sobre UX, Scrum y muchos otros temas del área de […]
• Scrum x Kanban. ¿Y el ganador es…? | Zappts Blog – […] entender más sobre qué es Scrum, recomiendo la lectura de este artículo, disponible en nuestro […]
• Management 3.0 – Zappts Blog – […] el blog de Zappts para saber más sobre gestión de equipos y aproveche también nuestros contenidos sobre Scrum, Transformación…
• Planeamiento de Sprint: ¿Cómo minimizar los riesgos involucrados? – Zappts Blog – […] ¿Quiere aprender más? Consulte nuestra publicación Scrum: entienda de una vez por todas qué es, cómo funciona…