Guía fundamental de Scrum

 

Scrum es el método ágil de desarrollo de Software más utilizado del mundo. Se presentó en 1995 y hoy en día, más del 70% de los equipos de desarrollo de Software en el mundo lo usan.

Scrum es simple pero no es fácil. Las compañías que consiguen implementarlo, consiguen mejoras de 4 a 10 veces en productividad, time-to-market y competitividad. Sólo es posible mediante la mejora de la transparencia, la reducción de los ciclos de desarrollo y la mejora de la innovación, según el reporte CHAOS de Standish Group.

Scrum ha evolucionado significativamente para adaptarse a nuevos retos e ideas durante los últimos 20 años. A pesar de todo, muy pocas compañías consiguen vencer sus propias resistencias para conseguir todos los beneficios de Scrum.

El movimiento ágil surge de la publicación del Agile Manifesto por líderes de la industria en el 2001. La realidad del mercado entonces era lamentable. Los proyectos de desarrollo de Software se planificaban durante años antes de escribir una sola línea de código, llevando a catástrofes como la del proyecto Sentinel del FBI, en el que después de invertir más de 60 millones de dólares, hubo que rehacer todo el Software de nuevo. En Andalucía, España, el gobierno regional invirtió unos 45 millones de euros en el desarrollo del Software para gestión del sistema sanitario Diraya, sólo para tener que rehacerlo antes de que estuviera verdaderamente en funcionamiento.

 

Hasta 17 críticos con el modelo de desarrollo tradicional se reunieron en Febrero de 2001 para crear un manifiesto que corrigiera esta situación, impulsados por el creador de eXtreme Programming, Kent Beck. De esta reunión surgieron cuatro valores y doce principios que rigen el desarrollo ágil de Software.

En algunos sitios de internet y libros se pueden encontrar referencias tales como “Metodología Scrum”, “Scrum Agile” o incluso “Agile SCRUM”. Estos conceptos son erróneos. Scrum es un marco de trabajo, no una metodología. Scrum es una implementación del manifiesto ágil, no parte del manifiesto ágil. Scrum no es un acrónimo, es un nombre propio.

Cuando en 2011, Ken Schwaber y Jeff Sutherland decidieron publicar la guía oficial de Scrum, lo hicieron atendiendo a un problema cada vez mayor: Cada profesional veía Scrum de una manera distinta y, lo que en su momento eran una serie de reglas, se convirtió en algo que quedaba a la más pura interpretación del profesional que lo implantaba.

Desde 2011 ha habido dos grandes cambios en la guía de Scrum, en 2013 y 2016. Primero, se eliminaron algunas cosas, como los diagramas de burndown. Se reforzó el énfasis en el Daily Scrum como elemento de planificación -y no solamente sincronización- y también se cambió el nombre de la reunión de grooming a refinenement. Todos estos conceptos los veremos más adelantes. En 2016 se añadieron los valores de Scrum, aquellos que hacen que el marco funcione en una organización, además de algunos cambios menores.

Una de las cuestiones importantes que trajo la guía de Scrum es que dejó de llamarse SCRUM. Hace muchos años, cuando se publicó el paper original sobre Scrum, se eligió en mayúsculas para darle más énfasis. Sin embargo, parece que muchos profesionales siguen tratándolo como si de un acrónimo se tratara.

Para entender los orígenes de Scrum, merece la pena leer el paper The New New Product Development Game, en el que se describen las reglas que dieron lugar al que hoy es el framework de desarrollo de Software ágil más usado en el mundo.

Uno de los énfasis que hacemos en Scrum.org es en el uso del lenguaje en lo que a Scrum se refiere. El Sprint Review es una reunión de negocio, no una demo. El Sprint Planning es para el equipo Scrum, no para los Stakeholders. Estas cosas marcan la diferencia en el entendimiento sobre las responsabilidades que cada una de las personas que están afectadas por Scrum, tienen. Mejoran la comunicación y reducen la fricción.

Scrum es un nombre propio, y por eso se escribe capitalizado, tanto en Castellano como en Inglés. Cuando veo un profesional con años de experiencia escribiendo SCRUM, me pregunto: ¿Qué otros conocimientos no habrá actualizado?

Un ejemplo práctico de cómo funciona Scrum

A través de un ejemplo práctico de una empresa real, durante los próximos párrafos entenderemos cual es la mecánica de Scrum en un entorno real.


 

Optiopay es una startup con sede en Berlín. Su producto es una plataforma de pagos entre particulares y empresas, que permite a los usuarios decidir si quieren recibir un pago con dinero en efectivo o quieren obtener vales regalo por un importe superior.

Optiopay tiene un equipo de 9 desarrolladores con diferentes perfiles que se encargan de diferentes partes del producto.

En Scrum, el Product Backlog es la única fuente de trabajo y del que se destilan el roadmap y los planes de producto

Todos los requerimientos del producto están recogidos y expresados en una lista, el Product Backlog. Esta lista contiene todo el trabajo que hay que hacer al producto y que lleva muchos meses. El Product Owner, que representa al negocio, se encarga de mantener la lista actualizada y en lo alto coloca las prioridades más urgentes. Este rol es el único que decide sobre las prioridades y es responsable de decidir hacia donde debe ir el producto.

Empezando en Scrum
Scrum es sencillo pero no es fácil. Es normal que organizaciones que empiezan noten un incremento de productividad y visibilidad al principio pero pronto caigan en problemas y disfunciones comunes.

El equipo de Optiopay hace una entrega de producto cada cuatro semanas. Al principio de la primera semana, el Development Team se reúne con el Product Owner en una reunión de planificación (Sprint Planning), donde éste le explica al equipo que su máxima prioridad es entregar la parte de la plataforma que se encarga del procesamiento de pagos. Esta es la meta para la iteración.

El Sprint Planning no es una reunión para tomar decisiones de negocio y prioridades.
Primero el equipo de desarrollo (Development Team) mira nuestra lista de requerimientos, que está actualizada y ordenada por prioridades y decide que porción creen que pueden completar en un cuatro semanas atendiendo a la meta para esa iteración. En la segunda parte, una vez decidido el trabajo a realizar, el Development Team se encarga de analizar y desmenuzar en tareas cada uno de los requerimientos que han escogido, lo suficiente para empezar a trabajar.

Todas estas tareas, junto con los requerimientos escogidos completan una lista en la que el equipo de desarrollo trabaja y será el plan de cuatro semanas que el equipo se encargará de mantener actualizado durante todo el Sprint.

Durante cada uno de los días de trabajo, el equipo de desarrollo se reúne todas las mañanas durante 15 minutos para analizar la lista de tareas y actualizar el trabajo que van completando y queda pendiente; los miembros del equipo informan a otros miembros de impedimentos y problemas. Juntos deciden como pueden resolverlos.

El final del Sprint no es una demo para enseñar al Product Owner lo que el equipo ha conseguido. Este proceso se produce de manera continua durante el Sprint, lo que ayuda a reducir el riesgo. El Sprint Review es una reunión de negocio
Una vez que el equipo va terminando el trabajo sobre los requerimientos, los va mostrando al Product Owner para que les de el visto bueno, y así poder continuar en el orden en que estaban inicialmente. La persona que ejerce este rol, trabaja con el equipo para informarles de la situación con respecto al producto. Todos los requerimientos terminados junto con la parte de producto hecha anteriormente se llama Incremento. El objetivo de la iteración es entregar un Incremento terminado que cumpla con la meta marcada.

Al final del Sprint, el Product Owner organiza una reunión llamada Sprint Review, donde invita a Stakeholders y al equipo de desarrollo para mostrar el Incremento terminado; los stakeholders dan feedback al Product Owner sobre el Incremento y preguntan cualquier duda que tengan al equipo de desarrollo. Después ponen en común cual es la situación de negocio actual. Al final, se actualiza el Product Backlog con nueva información que pudiera haber surgido.

Después del Sprint Review, el Scrum Master que es la persona encargada de gestionar todo el proceso Scrum, organiza una Retrospectiva para todo el equipo Scrum -Product Owner + Equipo de Desarrollo + Scrum Master-, donde analizan la forma de trabajar, posibles problemas en el equipo, areas de mejora y temas técnicos.

La retrospectiva marca el final del Sprint e inmediatamente otro Sprint comienza, siguiendo el mismo proceso descrito arriba.


¿De donde viene Scrum?

Scrum es el método ágil para gestión de proyectos más usado en el mundo, según todos los reportes de la industria.

Fue creado por Jeff Sutherland y Ken Schwaber y presentado por primera vez en la OOPSLA en 1995. Hay dos principales organizaciones que se encargan de promover Scrum y darlo a conocer a lo largo del mundo, Scrum.org y la Scrum Alliance.

Scrum no es una metodología, sino que es una implementación del Agile Manifesto, por tanto bebe de sus valores y principios.

Scrum se basa en una iteración continua donde se construye un producto o proyecto de forma incremental. Scrum es la más utilizada de las llamadas metodologías ágiles de desarrollo de software.

El nombre de Scrum proviene del Rugby (en francés melèe) y al igual que en Rugby todos los jugadores actual como una unidad para mover la pelota, en Scrum todos los componentes de un equipo actúan unitariamente para construir software de forma iterativa e incremental.

Desde 1995 hasta 2016 ha sufrido muchos cambios en sus mecánicas y formas de trabajo, aunque las organizaciones y profesionales que lo usan no siempre se han actualizado, y hay muchas dudas acerca de lo que es correcto o no cuando se usa Scrum, así como los elementos que forman parte de su núcleo y cuales son accesorios.


A pesar de lo que se cree, Scrum.org y Scrum Alliance no están enfrentadas. Trabajan para promover Scrum desde perspectivas distintas y colaboran habitualmente

El proceso Scrum

Descargar Póster de Scrum en formato A3

Roles en Scrum

Scrum prescribe tres roles: El Product Owner, el Scrum Master y el Equipo de desarrollo. Un equipo Scrum está compuesto de 3 a 9 miembros más el Scrum Master y el equipo de Desarrollo. Cada uno de estos roles en scrum tiene sus responsabilidades y tiene que rendir cuentas de distinta manera, entre ellos y para el resto de la organización. La suma de todos los roles de Scrum es el Equipo Scrum. Cada uno de estos roles tiene responsabilidades muy definidas y rinde cuentas por distintos motivos.

roles en scrum

Product Owner

La labor del Product Owner es optimizar el valor del producto dentro de los roles Scrum. El Product Owner gestiona el todo el flujo de valor del producto, a través del Product Backlog, así como todo lo relacionado con informes, presupuestos y relación con las partes interesadas en el producto (Stakeholders). En Scrum existe solamente un Product Owner por cada producto, así cómo un sólo Product Backlog.

El Product Owner es reponsable de maximizar el valor del producto o proyecto que este llevando a cabo. Esto, que se expresa facilmente, es una tarea complicada, tal y como veremos a continuacion.

Gestiona prioridades

El Product Owner se han entendido tradicionalmente como un gestor de requisitos, o un cliente que se encarga de gestionar el Product Backlog, pero es mucho mas que eso. El Product Owner tiene la responsabilidad de gestionar los presupuestos, de contratar al equipo de desarrollo y de explicar a los stakeholders cual es el valor que produce el producto en el que esta invirtiendo. Al fin y al cabo, cada Sprint que pasa, el Product Owner hace una inversion en desarrollo que tiene que producir valor.

Representante del negocio

Cuando el Product Owner es alguien de negocio, aportara valor a su trabajo al producto dependendiendo de al menos dos variables. La primera es la capacidad de decision que tiene. En ocasiones, es normal que el Product Owner no pueda realmente tomar decisiones sin consultar con otra persona. En ese caso, no es un Product Owner real y debe, o de ser sustituido por la persona que toma las decisiones, o ser investido para tomarlas el mismo. Hay que recordar que esto no es un capricho de los fanaticos de Scrum, sino una manera de maximizar la inversion realizada en el desarrollo de producto y reducir los riesgos inherentes.

Intraemprendedor

Es en esta faceta donde realmente el Product Owner puede aportar valor al negocio. Un Product Owner en esta faceta es un Product Manager agil, capaz de medir el valor generado y utilizar la flexibilidad de entregar cada Sprint para incrementar ese valor.

Scrum Master

El Scrum Master se encarga de gestionar y asegurar el proceso Scrum, que éste se lleva a cabo correctamente y de facilitar la ejecución del proceso y sus mecánicas, siempre atendiendo a los tres pilares del control empírico de procesos. Además, se encarga de eliminar impedimentos que puedan afectar a la entrega de producto. También se encarga de hacer coaching al resto del equipo Scrum cuando lo necesitan, además de facilitar reuniones y eventos si es necesario. El Scrum Master puede ser compartido entre varios equipos, aunque su disponibilidad afectara al resultado final del proceso Scrum.

El Scrum Master tiene dos funciones dentro del marco de trabajo. La primera es gestionar el proceso Scrum y la segunda es ayudar a eliminar impedimentos. Vamos a echarles un vistazo en profundidad:

Gestionar el Proceso Scrum

El Scrum Master es el encargado de mantener Scrum al dia, de proporcinar coaching, mentoring y formacion a la organizacion en caso de que lo necesita y de verlar porque Scrum favorezca la entrega de valor en lugar de ser una herramienta de microgestion.

Ayudar a eliminar impedimentos

Esta funcion del Scrum Master indica la necesidad de ayudar a eliminar progresiva y constantemente impedimentos que van surgiendo en la organizacion y que afectan tanto a la integridad de Scrum como impiden a la organizacion entregar valor.

Hay que remarcar que estos impedimentos no son del equipo, sino de la organizacion, y donde el Scrum Master aporta es a nivel organizativo, no reparando teclados para los miembros del Development Team. En ocasiones me encuentro Scrum Masters que se quejan de la imposibilidad de hacer Scrum debido a que la organizacion no facilita su introduccion adecuada a lo largo y ancho de la misma. Es precisamente al contrario, es el Scrum Master el responsable de velar porque Scrum se lleve adelante y se pueda facilitar la implementacion.

Los Scrum Masters y el tiempo libre

Un Scrum Master tiene mucho tiempo libre y esta fuera de la voragine del dia a dia, precisamente para que es le permita enfocarse en problemas de mayor calado que afectan a la organizacion a nivel global, en lugar de encargarse de actualizar el Scrum Board para el equipo de desarrollo, o hacer el trabajo del Product Owner. EL trabajo de eliminar impedimentos en una organizacion por parte del Scrum Master va desde influenciar a la capa ejecutiva o senior a favorecer el cambio de procesos internos para facilitar la agilidad organizacional

Development Team

El Equipo de desarrollo está formado por 3 a 9 profesionales que se encargan de desarrollar el producto, se autoorganizan y deciden cual es la mejor manera de conseguir entregar un incremento de software al final del ciclo de desarrollo. Nótese que en Scrum no importa el número de individuos sino el rol, y este solo hay uno, independientemente de cuantos miembros tenga el equipo de desarrollo y cuales sean sus roles internos. Cómo el equipo de desarrollo decida gestionarse internamente es su propia responsabilidad y tiene que rendir cuentas por ello; hay que evitar intervenir en sus dinámicas.

El equipo de desarrollo se encarga de crear un incremento terminado a partir de los Product Backlog items seleccionados durante el Sprint Planning. El Equipo de desarrollo tiene un tamano recomendado de 3 a 9 personas, que rinden cuentas como uno solo.

Habitualmente, tambien es un equipo cross-funcional, capaz de generar un incremento terminado de principio a fin, sin otras dependencias externas. El aspecto mas importante del equipo de desarrollo es que se auto-organiza y se auto-gestiona.

El equipo de desarrollo es responsable de contratar al Scrum Master

Artefactos en Scrum

En el marco de trabajo Scrum, existen tres artefactos. En este caso, artefacto se refiere a elementos físicos que se producen como resultado de la aplicación de Scrum. Los artefactos en Scrum son: El Product Backlog, el Sprint Backlog y el Incremento.

Product Backlog

El Product Backlog es un inventario. Contiene cualquier tipo de trabajo que haya que hacer en el producto. Requerimientos, casos de uso, tareas, dependencias. Todas ellas están representadas en el Product Backlog y este es la fuente principal de información sobre el producto en Scrum.

El Product Backlog es una lista en cualquier formato que contiene todos los requerimientos que necesitamos implementar en el producto. Esta lista es el resultado del trabajo del Product Owner con los distintos Stakeholders de la organización, y refleja el estado real del trabajo pendiente de implementar en un producto

El Product Backlog está gestionado por el Product Owner. Puede contener cualquier tipo de tarea en cualquier formato y su única condición es que esté priorizado con aquellos items que tienen más valor en ese momento.

Al comenzar a utilizar Scrum, no es necesario una lista completa y exhaustiva de todos los requerimientos. Es posible (¡Y recomendable!) empezar con los dos o tres requerimientos más urgentes arriba e ir añadiendo conforme vamos descubriendo más necesidades de nuestro producto.

Típicamente un Product Backlog contiene diversos tipos de elementos:

  1. Funcionalidades
  2. Bugs
  3. Historias de usuario
  4. Tareas técnicas
  5. Trabajo de investigación o Spikes

Historias de usuario

Las historias de usuario son una forma de expresar elementos de un Product Backlog, pero no la única. Un error común en organizaciones sin experiencia es tratar de expresar todos los elementos de un Product Backlog como historias de usuario.

El formato de una historia de usuario es:

As a… (Cómo tal o cual perfil)

I want to… (Especifica qué se quiere conseguir)

So I can… (Explica el por qué se quiere conseguir eso)

Para obtener el máximo valor de una historia de usuario, es necesario expresarlas desde el punto de vista del usuario. Intentar expresar una tarea técnica como una historia de usuario puede llevarnos a relaciones absurdas del tipo: Como desarrollador, quiero descargar el entorno de desarrollo para poder desarrollar.

Como se puede comprobar, el valor que se obtiene es mínimo. Otro punto a tener en cuenta en las historias de usuario es que tienen tres elementos importantes: La Tarjeta donde se expresa la historia de usuario, una Conversación acerca de que va la historia de usuario y la Confirmación de que todo el mundo ha entendido el valor.

Un ejemplo de Product Backlog

Este podría ser un ejemplo de Product Backlog para diferentes aplicaciones o industrias:

Red social

  • Como posible cliente, quiero poder suscribirme en la landing page para saber cuando va a ser el lanzamiento del producto
  • Como usuario, quiero poder escribir mis pensamientos para que queden guardados
  • Como usuario, quiero poder leer lo que escriben mis amigos
  • Como empresa, quiero poder segmentar usuarios para saber cuanto invertir en publicidad.

Banco

  • Como cliente particular, quiero poder consultar mi saldo para saber cual es la posición de mis cuentas
  • Como empresa, quiero recibir una notificación de cuando mis empleados usan la tarjeta para poder controlar mis gastos
  • Como cliente, quiero poder descargar la aplicación móvil para estar al tanto de mis cuentas en cualquier lugar
  • Como cliente particular, quiero saber cuanto puedo dinero puedo obtener en la aplicación móvil para evitar ir a una oficina

Sprint Backlog

Una vez que se hace el Sprint Backlog, todo el trabajo que el Development Team haya seleccionado para hacer durante el siguiente Sprint pasa al Sprint Backlog. Este artefacto es un elemento para visualizar el trabajo del Sprint y está gestionado por el Development Team. Su propósito es mantener la transparencia dentro del desarrollo

El Sprint Backlog nos proporciona una visión del trabajo a realizar durante el Sprint actual. Está gestionado por el equipo de desarrollo, que se encarga de mantenerlo actualizado y transparente durante toda la iteración, especialmente a través de los daily Scrums

Después del Sprint Planning, el equipo de desarrollo obtiene una lista de elementos en los que van a trabajar durante un Sprint. Estos elementos normalmente se deshacen en tareas técnicas más pequeñas. Facilitan la implementación de los mismos en un Incremento de software terminado.

El Sprint Backlog permite visualizar todo el trabajo pendiente durante un Sprint. Así, se pueden ver aquellos elementos que aún no han empezado a desarrollarse, aquellos que si y quienes están trabajando en los mismos y aquellos que están esperando a desplegarse o están completamente terminados.

Este artefacto permite entender cual es la evolución del trabajo durante el Sprint así como hacer una análisis de riesgos. Dado que cada Sprint tiene una meta específica (p.e. permitir que los usuarios se registren en la app móvil) y hay elementos seleccionados del Product Backlog que tienen más o menos valor, el Sprint Backlog permite analizar hasta donde se ha cumplido el objetivo y que se podría eliminar. Así maximizamos el retorno de la inversión en desarrollo.

Visualización del Sprint Backlog

Hay diferentes maneras de visualizar el Sprint Backlog. Desde el uso de herramientas electrónicas hasta una hoja de cálculo. Dado que el objetivo del Sprint Backlog es favorecer la adaptación y transparencia, el uso de una pizarra con columnas es uno de los más adecuados, al menos hasta que el equipo de desarrollo es suficientemente maduro como para poder lanzarse al uso de otra herramienta.

Incremento

Si Scrum tuviera que ser reducido a una sola cosa, sería a entregar una pieza de software terminado cada Sprint. El Incremento es la suma de todas las tareas, casos de uso, user stories y cualquier elemento que se haya desarrollado durante el Sprint y que será puesto a disposición del usuario final en forma de software al final del mismo

Un incremento es el resultado del Sprint. Es una pieza de Software, acorde con los elementos seleccionados durante el Sprint Planning del Sprint Backlog que aporta un valor de negocio al producto que se está desarrollando

Construir software de manera ágil se basa en hacerlo de manera iterativa e incremental. Mediante las iteraciones, nos aseguramos que todo el ciclo de vida del software: Planificación, diseño, desarrollo, testeo y entrega ocurre en 30 días o menos. Por supuesto, no podemos construir toda la funcionalidad que queremos en sólo 30 días y tenemos que buscar la manera de ir entregando los componentes necesarios justo a tiempo.

La imagen superior refleja esa manera de pensar. A través de un desarrollo incremental, primero nos centramos en las características o features principales y luego vamos añadiendo más, refactorizando y permitiendo tanto una arquitectura como un diseño emergentes.

Las ventajas del desarrollo incremental

El desarrollo incremental es uno de los pilares principales de cualquier iniciativa ágil, y tiene una ventaja principal. Nos permite una adaptación rápida a las condiciones cambiantes del mercado y del producto. Si descubrimos que lo que diseñamos no es lo que nuestro cliente busca en la segunda o tercera iteración, habremos reducido nuestro riesgo y aumentado nuestro retorno de la inversión.

Un desarrollo de este tipo choca con la mentalidad tradicional de desarrollo en fases, y es probablemente el hito que marca el cambio de una empresa de un modelo tradicional a un modelo ágil. No importan los roles, reuniones o artefactos en marcha puesto que, sin un incremento de Software terminado al final de cada Sprint no hay posibilidad de ser ágil.

Otros artefactos

Aunque existen otros artefactos que se pueden utilizar en Scrum, el marco de trabajo sólo necesita los tres expuestos anteriormente. Sin embargo, hay otro que, a pesar de no formar parte del core, es necesario para asegurar la calidad cuando se sigue Scrum

Definition of Done

La DoD es un documento, checklist o cualquier otra cosa que define qué se considera hecho en un equipo Scrum. La idea es establecer una serie de criterios comunes para especificar cuando un ítem está completamente terminado y que aplique a todos los ítems que forman parte del incremento.

Eventos y reuniones en Scrum

Scrum prescribe cinco eventos para cumplir con el control empírico de procesos. Todos tienen un sentido y sirven a distintas razones. Todos son necesarios para hacer Scrum y las adaptaciones suelen terminar en desastre. Algunas organizaciones piensan que tienen que adaptar Scrum a sus necesidades y terminan haciendo lo mismo que solían hacer con nuevos nombres.

La razón por la que Scrum tiene estos cinco eventos es porque son los mínimos necesarios para facilitar que el control empírico de procesos funcione. El gran problema de adaptar estos eventos o convertirlos en otra cosa es que el control empírico de procesos, el pilar de Scrum deja de funcionar. Analicemolos uno a uno:

Sprint

El sprint es un contenedor para el resto de los eventos de Scrum. El Sprint es continuo, es decir, su duración no cambia y se puede interpretar como una medida de ritmo que no cambia a lo largo del tiempo y nos permite reducir complejidad y comparar resultados a lo largo de diferentes Sprints. El Sprint sirve a la transparencia Y permite inspeccionar y adaptar todos los otros eventos de Scrum.

Scrum prescribe que un Sprint debe durar 30 días o menos. La duración de un Sprint está determinada por el periodo mínimo en que un equipo de desarrollo puede generar valor a través de un Incremento terminadoEl Sprint es una iteración definida (time boxed) que sirve al desarrollo iterativo e incremental. Todo el desarrollo se realiza durante el mismo Sprint y este contiene al resto de los eventos en Scrum, teniendo una duración de 1 mes o menos. La duración del Sprint se determina por un horizonte de planning aceptable. No hay fases en Scrum, sólo Sprints. No existen los Sprints de testing, hardening, release o análisis.

El Sprint es un evento que contiene a todos los demás eventos en Scrum, y su cometido principal es facilitar la transparencia del proceso Scrum. Un Sprint debe de durar 30 días o menos, y es bastante habitual que los equipos Scrum elijan tener Sprints de una duración de dos semanas. Sin embargo, cada caso es diferente, y es el equipo Scrum el que debe descubrir cual es su periodo mínimo necesario para generar valor a través de un Incremento terminado.

El Sprint también se puede definir como un metaevento que contiene todos los demás eventos. Un Sprint normal tendría:

  • El sprint Planning al comienzo del Sprint
  • Daily Scrums para actualizar el Sprint Backlog e identificar impedimentos
  • Un Sprint Review al final del Sprint para inspeccionar el Incremento
  • Justo después, la retrospectiva para hacer transparentes e inspeccionar posibles problemas en la forma de trabajar o de hacer Scrum.

Todo ocurre en un sólo Sprint

La mentalidad de un proyecto por Sprint es uno de los cambios más difíciles de asumir en la mentalidad de organizaciones que están haciendo una transición ágilScrum es una herramienta excelente para la gestión de proyectos. A diferencia de la gestión tradicional de proyectos, donde un proyecto puede durar meses o años, en Scrum un proyecto dura un sólo Sprint. Todas las tareas necesarias para llevar el proyecto a cabo se realizan durante el mismo Sprint. Así, el diseño, la planificación o el testing son actividades que se realizan dentro de un sólo Sprint, siempre orientado a generar el máximo valor. En Scrum, los proyectos se financian cada Sprint y es el Product Owner quien decide donde y a qué dedicar los recursos. Entender esto es crítico para asegurarse el éxito en la utilización de Scrum en una organización

proyectos_scrum

Monitorizando el progreso del Sprint

“A Scrum project is only one Sprint long. A release of software is the sum of multiple increments (and previously developed software, if any). A Scrum project cannot fail, only deliver unacceptable return on investment.”Ken SchwaberEl monitoreo del progreso del Sprint es una práctica bastante utilizada en equipos Scrum. Es una práctica del equipo de desarrollo que les permite ser transparentes acerca de la situación del trabajo reflejado en el Sprint Backlog y decidir si es necesario adaptar. En el caso de que así fuera, es el Development Team el responsable de hablar con el Product Owner para que sea él o ella quien decida cual es el trabajo de más valor del Sprint.

Una de las técnicas frecuentemente utilizadas es la del Sprint Burndown. En un diagrama se fijan los días del Sprint en el eje de abcisas, mientras que en el eje de ordenadas se refleja la suma del trabajo por hacer. Se hace un seguimiento diario del trabajo pendiente y el burndown va reflejando el trabajo restante a lo largo del tiempo.

Ejemplo de diagrama de burndown

Ejemplo de diagrama de burndown

Claves

  • La duración del Sprint se mantiene fija.
  • No hay espacios entre Sprints, cuando acaba uno, empieza el siguiente.
  • Permite mantener el ritmo.
  • Sirve a la transparencia

Sprint Planning

El Sprint Planning es una reunión que se realiza al comienzo de cada Sprint donde participa el equipo Scrum al completo; sirve para inspeccionar el producto backlog y que el equipo de desarrollo seleccione los Product Backlog Items en los que va a trabajar durante el siguiente sprint. Durante esta reunión el Product Owner presenta el Product Backlog actualizado, que el equipo de desarrollo se encarga de estimar, además de intentar clarificar aquellos ítems que crean necesarios.

En el Sprint Planning participa el equipo Scrum al completo, pero no Stakeholders. En el Sprint Planning se inspeccionan el Product Backlog, los acuerdos de la Retrospectiva, la capacidad y la Definition of Done y se adaptan el Sprint Backlog, el Forecast y el Sprint GoalEl Sprint Planning se divide en dos partes. En la primera parte de la reunión se trata el ¿Qué? se va a hacer el siguiente Sprint y en la segunda parte, se discute el ¿Cómo?. La primera parte está organizada y liderada por el Product Owner y la segunda parte por el Development Team. La única labor del Scrum Master es asegurarse de que la reunión existe como parte de Scrum.

El Sprint Planning es una reunión de planificación y puede durar hasta 8 horas para Sprints de 30 días. La razón del Sprint Planning es conseguir alineamiento entre negocio y desarrollo de producto en cuanto a cuales son las prioridades.

Flujo del Sprint Planning

Flujo del Sprint Planning

El Product Owner presenta un Product Backlog priorizado y actualizado, además de proponer un Sprint Goal que de coherencia a todos los ítems seleccionados durante la reunión. Durante la primera parte, el Equipo de Desarrollo pronostica cuantos elementos del Product Backlog cree que será capaz de terminar en el Sprint, teniendo en mente el Sprint Goal propuesto por el Product Owner. Una vez que existe un acuerdo entre el Product Owner y el Equipo de Desarrollo, entonces el equipo de desarrollo pasa a la segunda parte, donde se encargan de desmenuzar el trabajo que hayan seleccionado en tareas más pequeñas, siempre cumpliendo la regla de analizar solamente el mínimo para empezar a trabajar.

  • El Sprint Planning se compone de dos partes: Una donde se pronostica el trabajo a realizar y otra donde el Development Team se encarga de analizar y desmenuzar el trabajo en tareas, hasta donde crean necesario.
  • La primer parte del Sprint Planning está liderada por el Product Owner y la segunda parte por el Development Team.
  • Es responsabilidad del Scrum Master que el meeting ocurra, pero no tiene que facilitarlo ni organizarlo él mismo.
  • El Development Team tiene la última palabra sobre cuanto trabajo creen que pueden completar en un sólo Sprint.

¿Que necesitamos?

  • Definition of Done
  • Acuerdos de la retrospectiva
  • Product Backlog
  • Disponibilidad del Development Team

¿Que obtenemos?

  • Product Backlog actualizado
  • Sprint Backlog
  • Sprint Goal

Duración

8 horas para Sprints de 30 días. Menos para Sprints más cortos.

Quien es el responsable

Primera parte: Product Owner
Segunda parte: Development Team

Daily Scrum

El Daily Scrum es una reunión diaria de planificación de 15 minutos en la que participa el Development Team. Durante el Daily Scrum, se inspecciona el Sprint Backlog y se adaptan las tareas. Se hacen transparentes los impedimentos y el progreso hacia el Sprint Goal.

El Daily Scrum es una reunión de inspección y adaptación en Scrum de una duración de unos 15 minutos. Durante esta reunión, el equipo de desarrollo se reúne y analizan cuales son los elementos en los que están trabajando y que impedimentos encuentran. También comunican si existe riesgo de no alcanzar la meta marcada durante el Sprint -el Sprint goal-.

En Scrum existen varios feedback loops, pequeñas interacciones que nos dan la oportunidad de inspeccionar y adaptar nuestro trabajo. Eso nos permite planificar riesgos y tener transparencia y visibilidad sobre el proceso. El Daily Scrum es de frecuencia diaria y es exclusivo para el equipo de desarrollo. Durante el mismo, el equipo discute cual es la situación del incremento y como mitigar los riesgos asociados al mismo.

Mucha gente confunde el Daily Scrum con el Standup Meeting, pero no son lo mismo. El Standup Meeting es una práctica de eXtreme Programming (XP) orientada a controlar y gestionar el trabajo motivada por un manager, mientras que el Daily Scrum es una práctica que permite la inspección y adaptación a través de la auto-organización del equipo.

Facilitación de un Daily Scrum

Uno de los métodos de facilitación más conocidos, es el de las tres preguntas:

¿Que hice ayer para contribuir al Sprint Goal?
¿Que voy a hacer hoy para contribuir al Sprint Goal?
¿Tengo algún impedimento que me impida entregar?

Este método, aunque cómodo y claro para equipos que acaban de empezar con Scrum, se tienda a modificar con el tiempo una vez que los equipos maduran y son capaces de hacer un análisis de riesgo y adaptarse a demanda.

Otra de las temáticas durante el Daily Scrum es decidir quien va a trabajar con quien, por ejemplo a través de técnicas como el Pair Programming

Sprint Review

El Sprint Review es una reunión que ocurre al final del Sprint, donde el Product Owner presenta a los Stakeholders el Incremento terminado para su inspección y adaptación. Esta reunión, organizada por el Product Owner, es el momento de medir cual es la situación y actualizar el Product Backlog con nuevas condiciones que puedan afectar al negocio.

El Sprint Review marca la finalización de un Sprint. El equipo ha pasado hasta cuatro semanas desarrollando un incremento terminado de software que ahora mostrará a los Stakeholders. Para ello, el Product Owner se encarga de convocar una reunión donde se revisaran varias cosas.
No se trata de una demostración, sino de una reunión de trabajo. El software ya ha sido mostrado y validado junto con el Product Owner

Por un lado, se revisará el incremento terminado. Se mostrará el software funcionando en producción y los stakeholders tendrán la oportunidad de hacer cuantas preguntas estimen oportunas sobre el mismo. El Software funcionando ha sido validado previamente por el Product Owner, que se ha encargado de trabajar con el equipo durante el Sprint para asegurarse que cumple con la Definition of Done y efectivamente hace que el Sprint Goal sea válido. Si no existe software funcionando, no hay que hacer Sprint Review.

Posteriormente, el equipo de desarrollo comenta qué ha ocurrido durante el Sprint. Problemas que se han encontrado, así como soluciones tomadas, y actualizan a los stakeholders con la situación del equipo. Por último el Product Owner y los stakeholders actualizan, con las condiciones de negocio, el Product Backlog para el siguiente Sprint.

A pesar de lo que muchos creen, el Sprint Review no se trata de una demo para un cliente o para los stakeholders, o incluso para el Product Owner. No es tampoco una reunión para felicitar al Equipo de Desarrollo o congratularse. Es una reunión de trabajo, una de las más importantes ya que sirve para marcar la estrategia de negocio.

Ficha del Sprint Review

Asistentes: Equipo Scrum (Product Owner, Scrum Master y Equipo de Desarrollo) y Stakeholders
Facilitador: Product Owner
Duración: 4 horas para un Sprint de 4 semanas, menos para sprints más cortos

¿Que se inspecciona durante el Sprint Review?

  • El Incremento
  • El Sprint
  • El Product Backlog

¿Qué se adapta durante el Sprint Review?

  • El Product Backlog con las condiciones actualizadas de negocio

Retrospectiva del Sprint

La retrospectiva ocurre al final del Sprint, justo después del Sprint Review. En ella se hacen transparentes los problemas del equipo y se llegan a acuerdos para solucionarlos. También se inspecciona y adapta la definition of Done

Justo después del Sprint Review, ocurre la retrospectiva, que marca el fin del Sprint. El objetivo de la retrospectiva es hacer de reflexión sobre el último Sprint e identificar posibles mejoras para el próximo Sprint. Aunque lo habitual es que el Scrum Master sea el facilitador, es normal que distintos miembros del equipo Scrum vayan rotando el rol de facilitador durante la retrospectiva.

Un formato común es analizar Qué ha ido bien durante el Sprint, Qué ha fallado y Qué se puede mejorar. Este formato se puede facilitar pidiendo a los miembros del equipo Scrum que escriban post-its, para luego agruparlos y votar sobre aquellos ítems que sean más relevantes, dando a todo el mundo la oportunidad de hablar y expresar sus inquietudes.

También se utiliza el formato de retrospectiva basado en cinco fases:

  1. Preparar el ambiente: Un pequeño ejercicio para romper el hielo, junto con el recordatorio de la Prime Directive* hacen el comienzo perfecto.
  2. Recolectar información: Durante esta fase, se utilizan actividades para intentar construir una imagen de lo que ha sido el último Sprint. Una imagen conjunta de equipo.
  3. Generación de ideas: Ahora el equipo intenta generar ideas para identificar acciones que ayuden a mejorar el rendimiento del equipo durante el siguiente Sprint.
  4. Decidir que hacer: De las ideas generadas, se proponen acciones que puedan implementarse en el próximo Sprint. A implementar por todo el equipo.
  5. Cierre: Una pequeña actividad de cierre, normalmente unida a una evaluación de la propia retrospectiva, ayudan al equipo a decidir donde quieren ir en próximas ocasiones. Un recordatorio de la mejora continua.

Para encontrar actividades para realizar durante la retrospectiva, te recomiendo que le eches un vistazo al Retr-o-mat.

Ficha de la retrospectiva

Asistentes: El equipo Scrum (Product Owner, Scrum Master y Development Team)
Dueño de la reunión: Scrum Master
Duración: 2 horas

¿Qué se inspecciona durante la retrospectiva?

  • El último Sprint
  • Herramientas y procesos técnicos
  • Definition of Done
  • Relaciones entre los miembros del equipo
  • Procesos

¿Que se adapta durante la retrospectiva?

  • Una serie de acciones para mejorar la forma en la que el equipo trabaja

* Prime directive: Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Qué es Scrum

Definición de Agilidad

–nombre

  1. La agilidad es la capacidad de responder rápida y deliberadamente a las demandas de cambio mientras se controla el riesgo.
  2. Flexibilidad, la capacidad y cualidad de adaptar rápida y eficientemente
  3. La habilidad de innovar

La agilidad es una necesidad que surge del hecho de que desarrollar software es algo complejo y no se puede planificar de manera perfecta dada la velocidad y los distintos cambios. Aunque admitir esto requiere coraje, requiere de mas coraje admitirlo y vivir de acuerdo a sus consecuencias.

Definición de Scrum

–Marco de trabajo

  1. Ayuda a personas a gestionar problemas complejos
  2. Entrega productos del más alto valor de forma productiva y creativa

Scrum es un marco de trabajo, esto es, un grupo de reglas que ayuda a facilitar y hacer mas sencillo el desarrollo de software. Scrum es fácil de entender y muy difícil de dominar.

Entender Scrum requiere tanto de aprender una serie de mecánicas, necesarias para ponerlo en marcha, que son las que se describen en la guía, así como entender los valores y principios que soportan esas mecánicas. Cuando se implanta en una organización sin seguir los valores y principios, se consigue un resultado bastante problemático, que conocemos como amateur Scrum, en contraste con Scrum profesional

Iterativo e Incremental

Empirismo

Scrum emplea un enfoque iterativo e incremental para optimizar la previsibilidad y gestión del riesgo sobre tres pilares del control empírico de procesos.

  1. El primer pilar es la transparencia: todas las variables que afectan al resultado son visibles, además de asegurarse de que todo lo que se ve es realista.
  2. El segundo pilar es la inspección: Inspecciones frecuentes permiten la detección de problemas y variables inaceptables.
  3. El tercer pilar es la adaptación: Si existen elementos que están fuera de los límites aceptables, el proceso o lo que se está produciendo se adaptan tan rápido como se pueda para minimizar más desviaciones.

Scrum es agilidad

Scrum ayuda a limitar el riesgo cuando ejecutamos proyectos de desarrollo de software mediante iteraciones cortas y de alto valor, para entregar trozos de funcionalidad de altor valor y justo a tiempo, mediante el uso de equipos autoorganizados y crosfuncionales.

Por sì mismo, el framework no aporta mucho. Ese es el caso de las implantaciones amateur de las que hablaba anteriormente. El objetivo debe ser la agilidad, y el framework no es solo el camino para conseguirlo. A pesar de su comparación con proyectos industriales, Scrum no es sino un reflejo del empirismo y un marco de trabajo listo para funcionar en entornos complejos.

Ciclo de vida del desarrollo de Software en Scrum

Un proyecto Scrum es de un Sprint de duración, donde al final del mismo se entrega un incremento de software terminado. Una release de software es la suma de múltiples incrementos, además de cualquier software que se haya desarrollado anteriormente. Un proyecto Scrum no puede fallar, solamente entregar un retorno de la inversión inaceptable.

Dicho con otras palabras, por si mismo el marco de trabajo no produce nada, y seguirlo es independiente del resultado obtenido o deseado. Sin embargo, cuando se usa correctamente da mucha información e indicadores necesarios para poner en marcha acciones que se enfocan en la mejora del producto, del software que le subyace y de la organización en si mismo.

Es por ello que otros frameworks que se enfocan en la gestión del flujo de trabajo solamente o en el cambio organizacional no producen tan buenos resultados, y ese es el motivo de que casi el 70% de equipos en el mundo que utilizan metodologías ágiles utilizan Scrum.

La guía oficial de Scrum

La guía de Scrum es el documento que explica en detalle cuales son las mecánicas, sus eventos (Sprint, Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective), roles (Scrum Master, Product Owner y Development Team) y artefactos (Product Backlog, Sprint Backlog e Incremento). La guía se puede descargar aquí en Castellano. En las próximas páginas desgranaremos cuales son los detalles de cuales son cada una de las mecánicas que subyacen a Scrum.

La guía de Scrum ha tenido su última actualización en 2016, con la inclusión de los valores que subyacen a Scrum. Esta actualización, después de las de 2011 y 2013, indican la excelente relación de los creadores de Scrum y su compromiso hacia este marco de trabajo.

Algunos puntos clave

  • El desarrollo de software se emplaza en el dominio de la complejidad
  • El mejor enfoque para la complejidad es un proceso empírico
  • Los 3 pilares del empirismo son la transparencia, la inspección y la adaptación
  • La transparencia requiere confianza y coraje
  • Existen tres roles en Scrum: Product Owner, Scrum Master y Development Team
  • Hay tres artefactos en Scrum: Product Backlog, Sprint Backlog e Incremento
  • Cinco eventos: Sprint, Sprint Planning, Daily Scrum, Sprint Review y Sprint Retrospective.

Leer mas

Suscribete a nuestra lista de correo

Suscribete a nuestra lista de correo

Recibe actualizaciones en la comodidad de tu bandeja de entrada. Un email a la semana. Sin Spam. Sin Trucos.

Suscripción con éxito

Shares
Share This