«Scrum», la nueva no-metodología para propulsar equipos

Scrum es la palabra de moda en el mundo del emprendimiento. Pero, ¿qué es y por qué debería interesarte?

En este post, resolveremos estas y otras preguntas, a través de «Scrum: El arte de hacer el doble de trabajo en la mitad de tiempo», por Jeff Sutherland. Si formas parte de un equipo, esta información puede cambiar vuestra forma de trabajo. Si no tienes equipo, puedes quedarte igualmente.

¿Qué es «Scrum»?

Originalmente, el término scrum procede del rugby. Este término hace referencia a la forma en la que el equipo trabaja conjuntamente para hacer avanzar la pelota por el campo. Es decir, es el conjunto de «tácticas» (y empujones, mordiscos y placajes), mediante los que un equipo consigue anotar un tanto.

Jeff Sutherland, autor del libro que estamos analizando, decidió darle una vuelta de tuerca al concepto, con el fin de adaptarlo a la gestión de equipos. Nuestro amigo Jeff es expiloto estadounidense (participó en la guerra de Vietnam), por lo que, créeme, le gusta lo práctico y útil.

Tras abandonar el ejército, Jeff centró su atención en la mejora y gestión de equipos. De hecho, fue uno de los escritores del Agile Manifesto (el escrito en el que se basan las metodologías de trabajo ágiles). Este Manifiesto proclamaba distintos principios:

• Personas antes que procesos.⠀
  ⠀
• Productos que funcionen antes de documentar lo que se supone que deben hacer.⠀
  ⠀
• Colaborar con clientes antes que negociar con ellos.⠀
  ⠀
• Responder al cambio antes que seguir un plan.

Pues bien, en palabras de Jeff, «Scrum nace para poner en práctica esos valores, pero no es ninguna metodología.» Scrum es la nueva no-metodología del trabajo en equipo.

¿Cómo funciona Scrum?

Como expone el libro, las antiguas formas de organización y gestión de equipos han quedado obsoletas. La mayoría de equipos basan su desempeño en Gráficas de Gantt, siguiendo un método «en cascada«.

Las Gráficas de Gantt (en honor a su inventor, Henry Gantt) son las más utilizadas en el desarrollo de proyectos. Creadas en 1910, tienen un único fallo, como apunta Jeff: «simplemente, nunca aciertan».

Al tomar en cuenta aspectos como el tiempo destinado a realizar una tarea o la productividad de las distintas partes del equipo, ofrecen una visión sesgada de la realidad. En añadidura, obligan al equipo a trabajar «en cascada», es decir, impidiendo avanzar en un proyecto hasta que un determinado departamento acabe su parte.

Esta metodología retrasa al equipo. Jeff, como buen expiloto, no soporta los retrasos tontos y, de ahí, nace Scrum.

Scrum estudia cómo la gente trabaja en realidad, no cómo dice trabajar.

Jeff Sutherland

Scrum se basa en una idea simple: cada vez que se ejecuta un proyecto, ¿por qué no revisar con regularidad para ver si lo que se está haciendo sigue la dirección correcta y es lo que la gente quiere? ¿Por qué no revisar si se puede hacer mejor y más rápido y que lo impide?

Scrum, por tanto, abraza la incertidumbre y la creatividad. Como dice Jeff: «Dota de estructura al proceso de aprendizaje, lo que permite a los equipos evaluar qué crearon e, igualmente importante, cómo lo hicieron».

Equipos como sistemas adaptativos complejos

Según Jeff, las organizaciones, los equipos y las personas son sistemas adaptativos complejos, al igual que las células. Para que una célula cambie, primero debes inyectar energía en el sistema.

Cuando esta energía interacciona con la célula, se origina el caos, al igual que al inyectar nuevos procedimientos en una organización. Pero, pronto, tanto la célula como la organización se adaptan al nuevo estado. La pregunta clave es si ese nuevo estado es mejor o peor.

Scrum persigue convertir un equipo en un sistema adaptativo, capaz de evaluar su desempeño e introducir cambios para mejorarlo. Básicamente, un equipo que no para de mejorar.

Scrum, mejor en compañía

Scrum no toma en cuenta el desempeño individual, sino el del equipo. Esto es así porque, cuando aceleras un equipo, el incremento de productividad es muchísimo mayor que acelerar a cada individuo.

En un estudio de IBM se descubrió que, mientras el equipo más rápido podía terminar una tarea en una semana, el equipo más lento tardaría, de media, dos mil semanas. Suena un poco fantasioso y no he comprobado el estudio, aunque el autor lo adjunta en la sección de Notas.

Sea cierto o no, está claro que el antiguo sistema de mejora del individuo (a través de ascensos, remuneraciones, etc) es un proceso muy lento. En su lugar, reunir un equipo y brindarles un objetivo es una forma más intuitiva de motivar a sus miembros.

Según los profesores Nonaka y Takeuchi, los grandes equipos compartían estas características:

• Trascendentes: los grandes equipos tienen un propósito más allá de lo normal.⠀
  ⠀
• Autónomos: se organizan y gestionan solos.⠀
  ⠀
• Interfuncionales: cuentan con todas las habilidades (y personas) necesarias para llevar a cabo un proyecto.

El equipo de Scrum, al detalle

Un equipo de Scrum es algo, por así decirlo, peculiar. Para empezar, hablaremos de sus componentes.

El tamaño óptimo de un equipo de Scrum son 7 integrantes, permitiéndose dos de más o de menos. Cuantas más personas involucradas, más lento se vuelve el equipo. Esto se debe a que, al aumentar el número de personas, se incrementan los canales de comunicación, a esta razón:

Canales de comunicación (siendo n el número de personas) = n(n-1)/2

Siete personas equivalen a 21 canales de comunicación. Es muy difícil abarcar más canales, lo que provoca una desconexión dentro del quipo. Cada integrante debe saber cómo avanzan y qué hacen los demás.

La comunicación dentro del equipo es clave, pues de ello depende la rapidez del mismo. Esta comunicación debe ser constante y transparente. Para ello, nos valdremos de reuniones diarias y el tablón de Scrum (en nada lo explico).

Otra de las peculiaridades de Scrum es que no existen cargos. A la hora de formar tu equipo, únicamente deberás contemplar estas figuras:

• Scrum Master: integrante del equipo que facilita las reuniones, comprueba que haya transparencia y, sobre todo, ayuda al equipo a saber qué le estorba. Guía al equipo a la mejora continua. Tras cada sprint, es el encargado de preguntar al equipo:⠀
  ⠀
  • «¿Qué cambios podemos hacer en la forma como trabajamos»
  • «¿Cuál es nuestro principal escollo?»⠀
    ⠀
• Responsable del producto: el Scrum Master es el líder, el cómo, mientras que el responsable del producto es el qué, el encargado de poner en acción la visión del líder. Debe estar en constante comunicación con los clientes y el equipo, para transmitir el feedback de ambos. Este debe:
  
  • Conocer el terreno en el que trabaja.
  • Tener autoridad para tomar decisiones.
  • Estar a disposición del equipo para explicar qué se debe hacer y por qué.
  • Hacerse cargo del valor del trabajo en el sprint.

Diseña la bitácora

Una vez organizado el equipo, será momento de crear la bitácora del proyecto. La bitácora no es más que una lista con todo lo que debe hacerse para alcanzar la visión planeada. Esta bitácora será la hoja de ruta del proyecto, aunque puede (y debe) ser modificada.

Cuando hayáis identificado todas las tareas a realizar para alcanzar el objetivo, es recomendable convertir dichas tareas en historias. En lugar de «Necesitamos un carrito para que nuestra librería online funcione», podríamos relatar la tarea así: «Como cliente, me gustaría meter un libro en un carrito para comprarlo».

Haz historias con cada tarea, poniendo al cliente en el centro y abreviándolas lo máximo posible. Sigue el patrón INVEST para que tu historia funcione:

• Independiente: no debe depender de otra historia.⠀
• Negociable: debe ser posible reescribirla hasta que no esté terminada.
• Valiosa: aporta valor al cliente.
• Estimable: puede ser evaluada.
• Suficientemente corta: debe ser corta para calcularse y planearse fácilmente.
• Totalmente comprobable: debe poder pasar una prueba que confirme que ha sido completada.

¿Cómo medimos el trabajo?

A la hora de definir el tiempo que nos tomará terminar cierto proyecto, las estimaciones suelen fallar. Esta realidad puede observarse en la siguiente gráfica:

Esto no significa que no haya que planear, solo que hay que planear lo justo y realista. Afinad el plan a lo largo del proyecto, no lo dejéis terminado desde el principio. Planead en detalle lo suficiente para cumplir el próximo incremento de valor y dejad el resto apuntado en líneas generales.

¿Cómo medir y planear el trabajo? Según Jeff, la mejor forma es medir las tareas por cuánto trabajo tardarás en realizarlas, no por cuánto tiempo.

Para llevarlo a cabo, en la obra se sirven de un sencillo truco: clasificar la dificultad de una tarea según el tamaño de la raza perruna. Así, una tarea complicada puede ser un «Gran danés», mientras que una sencilla, un «caniche». Es solo un ejemplo, pero resulta descriptivo.

Perros y póker

Tras asignar la raza, puedes dar un valor numérico a cada tarea. Jeff recomienda usar números que sean la suma de los dos anteriores (siguiendo una serie de Fibonacci: 1, 3, 5, 8, 13…). Esto nos permite hacer estimaciones que no sean 100% exactas, además de ver una clara diferencia entre las distintas puntuaciones (es más fácil distinguir entre un 5 y un 8 de dificultad que entre un 5 y un 6).

Para asignar valores numéricos, utilizaremos el póker de planeación. Ojo a este truco.

Cada persona recibe un mazo de cartas con los números de la serie de Fibonacci (1, 3, 5, 8, 13, 21…). Cada tarea a calcular se expone sobre la mesa y, cada persona del equipo, tira una carta con el nivel de dificultad que asignan a dicha tarea.

Si la secuencia obtenida es próxima, se hace la media de los resultados (con un 5, dos 8 y un 13, la media sería de 6,6 de dificultad). Si la distancia entre dos números sacados es de más de tres cartas, las personas que han dado dicha valoración explican sus razones y se juega otra ronda de póker.

De esta forma, cada tarea recibirá un valor de dificultad. Dicho valor nos será muy útil a la hora de planear el sprint. Veamos qué quiere decir este término.

Sprint, la unidad básica de Scrum

Scrum se basa en repeticiones o sprints, periodos intensos de trabajo, al final de lo cuales se evalúa el desempeño y se introducen mejoras. Es decir, trabajar al más puro estilo Usain Bolt.

Para cada sprint, se divide una pizarra o tablón en varias columnas: Pendientes, En proceso y Terminado. Al principio del sprint, se colocan todas las actividades por hacer en la columna de Pendientes. A lo largo del sprint, un miembro del equipo asumirá una tarea concreta y la pasará a la columna «En proceso». Al acabarla, la pondrá en «Terminado» (importante: nada pasa a terminado si el cliente no lo puede usar).

Los sprints son lo que se conoce como «cajas de tiempo». Su duración es fija, por lo que no conviene variar los tiempos de sprint. Como dice Jeff:

«Debes establecer un ritmo de trabajo que permita saber a la gente cuánto puede hacer en un periodo determinado. Esta cantidad de trabajo suele causar asombro.

Un elemento crucial de cada sprint, sin embargo, es que una vez que el equipo se compromete con lo que hará, el número de tareas se congela. Nadie fuera del equipo puede añadir una más.«

Stop diario

Durante el sprint, el equipo debe cumplir una máxima: cada día, debe realizarse una parada o reunión. Todos los días, el equipo se reúne en torno a la pizarra o tablón de Scrum y el Scrum Master formula 3 preguntas (la reunión no debe durar más de 15 minutos):

• ¿Qué hiciste ayer para ayudar al equipo a terminar este sprint?
• ¿Qué harás hoy para ayudar al equipo a terminar este sprint?
• ¿Qué obstruye el avance del equipo?

La reunión se hace todos los días a la misma hora, con todos los integrantes del equipo. Solo 15 minutos y todos deben participar activamente. Jeff hace las reuniones de pie, para agilizar el stop. La idea es que el equipo hable brevemente sobre cómo finalizar el sprint.

Dejar algo a medias es perder

Quedarse a medias en algo fastidia, pero, en un sprint, es imperdonable. Esto es lo que opina Jeff al respecto:

Si al final del sprint algo queda a medias, estarás peor que si no hubieras hecho nada. Has gastado recursos, tiempo y esfuerzo sin llevar nada a un estado susceptible de entrega.

Sin embargo, no consiste en que alguien tome las riendas y no duerma hasta terminar la tarea, por el simple hecho de acabarla. Un equipo que depende de actos heroicos y del trabajo milagroso de alguno de sus miembros es un equipo que no trabaja bien.

Es normal que, durante los primeros sprints, el equipo asuma demasiado trabajo y queden cosas sin hacer. Pero, a medida que se acostumbra al nuevo proceso, un equipo debe ser capaz de conocer su desempeño y ajustar el sprint a su velocidad.

Final del sprint y desempeño

Al finalizar cada sprint, el Scrum Master hará 3 preguntas:

• ¿Hay algo que podemos hacer de otra manera para avanzar más rápido?
• ¿Podemos librarnos de algunos Pendientes? ¿Encargar algunas cosas a otros equipos?
• ¿Podemos dejar de hacer algunas cosas?¿Reducir el alcance del proyecto?

Estas preguntas permiten valorar el trabajo del equipo, con el fin de mejorarlo en el próximo sprint. Como las reuniones diarias, esta sesión de feedback debe ser corta y, si es posible, con la participación de todos los miembros.

Pero, ¿cómo medimos el desempeño del equipo?

Al principio de cada sprint, hay una sesión de planeación, para dictar un plan para el proceso. Cuando finaliza el sprint, se cuentan todas las historias terminadas, se suman los puntos de dificultad asignadas a cada una y, este número, será la muestra de la velocidad del equipo.

¿Recuerdas el póker de planeación? Cada tarea (o historia) llevará asignada la puntuación que, como equipo, hayáis decidido al jugar al póker. Cuando finalice el sprint, se sumará la puntuación de todas las tareas completadas. Pongamos que, por ejemplo, se obtienen 100 puntos.

Lo que quiere decir este número es que el equipo tiene una velocidad de 100 puntos de trabajo. De esta forma, cuando planeéis el próximo sprint, sabréis que, como mínimo, sois capaces de hacer tareas que sumen 100 puntos de trabajo.

Esto nos permite medir las tareas que podemos realizar y mejorar el desempeño. Además, tomando la puntuación de todas las tareas a realizar para acabar un proyecto, sabremos cuándo finalizaremos este (si el proyecto tiene una puntuación de 500, sabremos que, como máximo, necesitaremos 5 sprints para acabarlo, tomando en cuenta la velocidad de 100 puntos por sprint).

Valores de Scrum

Aunque no se trate de una metodología, Scrum cuenta con una serie de valores. Estos permiten el buen funcionamiento del equipo y su gran desempeño. Veamos que dice Jeff sobre esto.

Felicidad

Según Jeff: «La felicidad precede al éxito. La gente no es feliz por ser exitosa, sino que es exitosa por ser feliz.»

Dentro de Scrum, se fomenta la felicidad de sus integrantes, pero con ciertos matices. Cada miembro debe ser feliz «dentro del equipo y como parte de él», es decir, debe haber una gran sintonía a nivel laboral. El autor lo explica perfectamente en el libro:

«Es estupendo que vayas al bar con tu equipo a reforzar los vínculos entre vosotros, pero esto no le sirve de mucho a la compañía si tales vínculos no se traducen en mejor desempeño.

Yo me junto con muchas personas para divertirme. Con mi equipo me gusta que el aspecto social vaya directo al desempeño. Y así sucede.«

La felicidad en el espacio laboral es importante, de eso no hay duda. Por ello, y al finalizar un sprint, cada miembro del equipo puede responder estas preguntas, con el fin de medir la felicidad del equipo y resolver cualquier conflicto:

• En una escala de 1 a 5, ¿cómo te sientes con tu papel en la compañía?
• En esa misma escala, ¿cómo te sientes con la compañía en general?
• ¿Por qué te sientes así?
• ¿Qué te haría más feliz en el siguiente sprint?

Trasparencia

En añadidura a la felicidad, la transparencia es clave para que un equipo trabaja eficientemente. De hecho, me atrevería a decir que es más importante.

Para que el equipo de Scrum funcione, cada persona debe saber lo que están haciendo las demás. Para ello, nada mejor que «el tablón de Scrum», una imagen fiel de la realidad actual de tu equipo.

El tablón es el alma del equipo, el reflejo de su realidad y desempeño. Apostar por la trasparencia es complicado, pero, si se hace correctamente, rinde sus frutos.

Fuera la multitarea

En cuanto a la multitarea, Jeff lo tiene claro: no la quiere en su equipo. Haz una cosa a la vez, ya que, como muestra el siguiente esquema, en una compañía normal se desperdicia hasta un 85% del trabajo.

La estrategia de la mayoría de las empresas consiste en intercalar proyectos. Si durante un año hay que acabar el proyecto A, B y C, se dividirá el tiempo de forma que se avance en todos a la vez.

Scrum apuesta por algo distinto: priorizar un proyecto y no pasar al siguiente hasta finalizar el primero. Podemos verlo en la siguiente gráfica:

Prohibidas las burbujas de felicidad

Superman teme a la Kryptonita, Indiana Jones, a las serpientes, y Jeff, a las burbujas de felicidad. Pero, ¿qué es este ente maligno?

Una «burbuja de felicidad» es el estado de complacencia dentro del equipo, que surge cuando las cosas van bien. Cuando se alcanza un éxito moderado, los equipo se duermen en los laureles y dejan de mejorar.

Los buenos momentos deben celebrarse, pero, también, emplearse en preparar el terreno para épocas peores. ¿Cómo evitar estas burbujas? Para ello, es necesaria la figura del bufón, aquella persona que hace preguntas desagradables o dice verdades incómodas.

Viéndolo así, tengo algo de bufón. Pero, creo que es algo clave dentro del equipo, siempre que el mensaje sea constructivo.

Mínimo y viable

Finalmente, Scrum apuesta por lanzar tu producto lo más rápidamente posible. Es clave ofrecer un «producto mínimo viable» o MVP, para que el cliente pueda interaccionar con él y dar feedback.

Para guiarte a la hora de crear tu MVP, Jeff nos ofrece una gráfica muy ilustrativa:

Guía básica de Scrum: empieza hoy

Ya hemos visto la filosofía Scrum y el funcionamiento de esta. Sé que es algo confuso y, como me ocurrió a mí, tengas muchas dudas. Para que puedas implementarlo por ti mismo y aclarar tu mente, te dejo una guía paso a paso sobre el proceso:

• Selecciona un equipo: recuerda, debe ser pequeño, de 3 a 9 personas. El equipo debe reunir las habilidades necesarias para completar el proyecto.⠀
  ⠀
• Nombra un Scrum Master y un responsable del producto.⠀
  ⠀
• Crea una bitácora del producto: elabora una lista con todo lo que debe hacerse para alcanzar la visión planeada. Esta bitácora será la hoja de ruta del proyecto, aunque puede (y debe) ser modificada.⠀
  ⠀
• Afina y estima la bitácora del producto: estimad cuánto esfuerzo (u horas de trabajo) requerirá cada elemento de la bitácora. Cada elemento debe ser viable y medible, siendo el equipo capaz de determinar cuando se puede dar por Terminado.⠀
  ⠀
• Planea el sprint: el equipo deberá planear su primer sprint, cuya duración siempre es inferior a un mes. Se toman los elementos de la bitácora y se asignan al sprint aquellos que el equipo piensa que es capaz de terminar. Lo primero que hay que hacer es lo más valioso para el proyecto, siguiendo la ley de Pareto del 80/20.⠀
  ⠀
• Elabora una lista de Pendientes: fija un objetivo para el sprint y enumera todas las tareas derivadas de dicho objetivo. Prioriza aquellas que generarán ingresos inmediatos, librando de riesgos el proyecto (ofrece valor lo más pronto posible). El responsable del producto es la persona a cargo de que los pendientes se organicen y cumplan.⠀
  ⠀
• Vuelve visible el trabajo: crea un tablón de Scrum con 3 columnas: Pendiente, En proceso y Terminado. Coloca un post-it por cada tarea en la columna de Pendiente y ve moviéndolos a medida que cambie su estado.⠀
  ⠀
• Haz una parada o Scrum diario: cada día, el equipo se reúne durante 15 minutos para contestar a 3 preguntas:
  • ¿Qué hiciste ayer para ayudar al equipo a terminar el sprint?
  • ¿Qué harás hoy para ayudar al equipo a terminar el sprint?
  • ¿Algún obstáculo te impide o impide al equipo cumplir la meta del sprint?⠀
    ⠀
• Revisión o demostración del sprint: en esta reunión se expone lo trabajado durante el sprint. A dicha reunión puede asistir cualquier persona, no solo el equipo. El equipo mostrará aquello que considera Terminado, tras finalizar el sprint.⠀
  ⠀
• Retrospectiva del sprint: se valora lo que se hizo bien y lo que se puede mejorar y, al final de la reunión, el equipo acuerda mejoras en el proceso del próximo sprint.⠀
  ⠀
• Se inicia un siguiente sprint, tomando en cuenta los cambios acordados.

Conclusión

Si has llegado hasta aquí, te felicito. Este ha sido un post bastante denso, pero, en mi opinión, muy interesante. Si eres leinner y estas leyendo esto, estoy seguro de que has visto muchas similitudes con la metodología de la carrera.

Como siempre, te dejo el enlace al libro por aquí:

Durante estos últimos meses de carrera, tengo en mente aplicar Scrum a mi desempeño. Si las cosas van bien, compartiré por aquí la experiencia. Y, sino, también.

Te dejo 2 vídeos con dos posturas muy diferentes sobre Scrum. Me gusta ver las dos caras de un proceso, para contrastar opiniones y formar la mía propia:

Antes de despedirme, me gustaría dejaros una dinámica muy útil para introducir Scrum a vuestro equipo o entorno laboral. Se llama «dinámica de los aviones de papel» y, creedme, os va a gustar:

• Dinámica de los aviones de papel

Además, hace unos días subí un artículo sobre el libro «Sprint». Sigue una metodología algo distinta a Scrum, pero puede ser interesante para completar información.

No hay mucho más que decir. Si os ha gustado y lo implementáis, dejádmelo en los comentarios. 😉

Un abrazo y gracias por leer,

-Javier