Qué es y para qué sirve Scrum

Scrum es un método para solventar problemas complejos, entregando productos que aporten el mayor valor posible.

Es una metodología:

Ligera

Scrum tiene poca teoría, únicamente define algunas reuniones o ceremonias, los roles, y unos pocos principios básicos. El contenido teórico se lee en menos de 5 minutos.

Fácil de entender

Es una metodología abierta, que no propone reglas complicadas ni demasiado específicas en función del proyecto.

Difícil de dominar

La clave es adaptarla correctamente al entorno y al proyecto concreto. Por eso está definido el rol de Scrum Master, que es la figura que domina el método y ayuda a su aplicación y ajuste.

Está basada en procesos empíricos de control, es decir, el conocimiento viene de la experiencia, y se toman decisiones en función de la información que se tiene.

Su enfoque es iterativo e incremental.

Iterativo

En cada sprint, se genera una nueva versión del producto, que mejora la versión del sprint anterior. Se trata de ir refinando y mejorando las propiedades del producto conforme avanza el proyecto.

Incremental

En cada sprint, se añade alguna nueva característica al producto. Se trata de ir añadiendo nuevas capacidades o características al producto conforma avanza el proyecto.

 Elementos de Scrum 

Sprints

El producto se construye de forma incremental en base a períodos de tiempo cortos, denominados Sprints.

Los Sprints tienen una duración fija y determinada, entre 1 y 4 semanas; mejor cuanto más cortas, es decir mejor 1 semana que 4.  

Todos los Sprints tienen la misma duración a lo largo del proyecto.   

Definición de Hecho

El equipo de trabajo tiene que encontrar una definición para el concepto de "hecho" -Done-. Cada incremento del producto debe cumplir dicha definición de "hecho" para darlo por finalizado, y poder ser entregado. 

La definición de "hecho" puede aplicar a requisitos, sprints, releases, entornos... es decir, en cualquier elemento sobre el que se pueda plantear la cuestión de "¿está finalizado y puede continuar al paso siguiente del proyecto? 

"Hecho" para un requisito

 Ejemplo de "Hecho" para un requisito (habitualmente denominadas "historias de usuario"): 
  • Todo el código escrito sin errores.
  • Todas las pruebas unitarias pasadas correctamente.
  •  Pruebas funcionales pasadas con éxito.
  • Documentación del requisito generada.
  • Pruebas de aceptación pasadas con éxito.

"Hecho" para un sprint

 Ejemplo de "Hecho" para un Sprint: 
  • Pruebas de rendimiento pasadas con éxito.
  • Elementos resultantes del sprint integrados.
  • Todos los bugs resueltos.
  • Pruebas de integración pasadas con éxito.

"Hecho" para un despliegue

 Ejemplo de "Hecho" para Despliegue en Producción: 
  • Pruebas de stress pasadas con éxito.
  • Pruebas de seguridad validadas.
  • Plan de marcha atrás definido.
  • Entorno y servicio estable.

Ciclo de Scrum

El proyecto se ejecuta en base a sprints, de duración fija,  que se planifican al arrancar cada sprint, con las Daily cada 24 horas.
En cada sprint se resuelve o construye el Sprint backlog, que se integra al final del sprint con el resultado de sprints anteriores, conformando un producto entregable.

 

Productos

También denominados "artefactos":

  • Incremento de producto: un subconjunto del producto que puede ser entregado, con componentes integrados, que funciona.
  • Backlog de producto: la lista de requisitos del producto, ordenadas por su prioridad.
  • Backlog del Sprint: el plan detallado para el desarrollo durante el sprint siguiente.

Pilares básicos

  • Transparencia: los interesados comparten un entendimiento común del proyecto, de la visión, y de lo que significa "hecho"
  • Inspección: a través de los artefactos o entregables (incremento de producto, backlog de producto y backlog del sprint).
  • Adaptación: a través de las reuniones en Scrum.

Valores

  • Personas enfocadas en el resultado.
  • Motivación.
  • Transparencia.
  • Compromiso.
  • Respeto.

Reunión Daily Scrum

  • Reunión con un timebox de 15 minutos, donde el equipo de desarrollo sincroniza sus actividades y crea el plan para las siguientes 24 horas.
En esta reunión, cada miembro del equipo de trabajo debe responder a 3 preguntas:
     - ¿Qué hice ayer?
     - ¿Qué haré hoy?
     - ¿Hay algún impedimento que me evite conseguir mis objetivos hasta mañana?

Reunión Sprint Review (también llamada "demo")

  • Reunión que se mantiene al final de cada Sprint para inspeccionar el Incremento de Producto, y adaptar el Backlog del producto si es necesario.
  • Durante el Sprint Review, el equipo de trabajo muestra al resto de interesados qué se ha conseguido en el sprint.
Si los sprints son de un mes, el timebox de la reunión serán 4 horas. Para sprints más cortos, la duración se reduce proporcionalmente.

Reunión Retrospectiva del Sprint

  • Se inspecciona cómo ha ido el sprint, en lo referente a las personas, sus relaciones, el proceso, y las herramientas.
  • Se identifican y ordenan los asuntos más importantes, tanto los que fueron bien, como los que suponen una mejora potencial.
  • Se crea un plan para implementar las posibles mejores detectadas.
Si los sprints son de un mes, el timebox de la reunión serán 3 horas. Para sprints más cortos, la duración se reduce proporcionalmente. 

Roles en Scrum

En un proyecto ágil, típicamente bajo metodología Scrum, distinguimos 3 roles:

Product Owner 

  • Decide qué se incluye (y qué no) en el backlog del proyecto.
  • Ordena los ítems en el backlog en función de su prioridad de negocio.
  • Explica y hace entender al equipo de trabajo en qué consisten esos ítems (historias de usuario).
  • Decide cuándo se deben realizar las entregas.

ScrumMaster

  • Representa la figura de líder sirviente.
  • Es el experto en la metodología, guiando y enseñando al equipo a llevarla a cabo adecuadamente.
  • Soluciona problemas y elimina barreras, facilita el trabajo.

Equipo de desarrollo

  • Realiza el trabajo necesario para construir y entregar el producto final.
  • El equipo es un grupo de profesionales con todas las capacidades (en conjunto) para realizar el trabajo.

Una idea fundamental es que se fomenta la comunicación directa entre el equipo de trabajo y el Product Owner. No se debe pensar que el Scrum Master es el "traductor" del lenguaje de negocio a lenguaje técnico; al contrario, es el equipo de desarrollo el que trabaja directamente con la persona de negocio. El Scrum Master actúa como facilitador de esta relación.

Veamos cómo funciona un equipo Scrum:

Aportar más valor junto al enfoque ágil 

Muy resumidamente, podemos decir que el enfoque ágil de trabajo se compone de dos partes: 

Proceso y prácticas

El proceso de trabajo para proyectos, o en general la metodología ágil que se aplique (Scrum, Lean, cualquiera de sus derivadas, o cualquier metodología concreta de una empresa), que sea cual sea está compuesta por las prácticas ágiles.
Ejemplos de prácticas ágiles pueden ser: escribir requisitos como historias de usuario para facilitar su validación futura; ejecutar un planning poker para estimar requisitos a alto nivel; hacer un roadmap de un proyecto; construir un mapa de productos mínimos viables; diseñar y utilizar un tablero Kanban para la gestión del trabajo; lanzar y ejecutar sprints de corta duración; llevar a cabo ceremonias de "demo" o de retrospectiva, etc.

Cultura

El punto de vista, el enfoque o "la cultura", como se suele llamar: aplicar estas prácticas desde un punto de vista que valora la participación de las personas, tratando de generar la menor cantidad de desperdicio (por ejemplo tiempo o documentación innecesarios), con franjas de tiempo limitadas asignadas a las tareas, buscando la mejora contínua, etc...

Pues bien, aún podemos (y deberíamos) tener en cuenta una tercera parte: el bienestar de los profesionales.

"Bienestar" es la palabra más aceptada en español en lugar de su original en inglés, "wellbeing". 

Supongamos que en una empresa cualquiera, en mitad de un proyecto, se agenda una reunión de retrospectiva, en la cual las personas que componen el equipo dan su opinión sobre el proceso de trabajo: qué puntos o cuestiones se gestionan bien, cuáles dan más problemas, y se genera un plan de acción a corto plazo para mejorar estos puntos problemáticos, además de potenciar lo que ya se hace bien. Las prácticas en las retrospectivas consisten en hacer participar a las personas para obtener esta información, y por ejemplo generar un gráfico tipo "radar" para mostrarlo.  Es decir: en esta empresa, se está aplicando la práctica, y además se trata de aplicar la cultura ágil. 

Hasta aquí bien, pero pensemos en lo siguiente: ¿a todos los profesionales les gusta tanto participar (hablar, opinar) delante de otras personas? ¿Todos los profesionales están igual de motivados para concentrarse y buscar la mejora continua? Seguramente, no todos en la misma medida... 

Y lo más importante: cuando decimos "profesionales", estamos hablando de personas. Las personas tienen días buenos y menos buenos; días con más energía, y días en los que no se ha descansado bien; días con sensaciones más tranquilas, y días con alguna cuestión familiar que nos preocupa, nos entristece, nos estresa y hasta nos consume gran parte de nuestra energía. 

Una persona puede decidir no ser un profesional, no trabajar o no interesarse en absoluto por su trabajo. Pero los "profesionales" no pueden elegir dejar de ser personas. 

Es interesante que cada uno de nosotros nos paremos a pensar en esto un minuto, y todo lo que implica: un profesional no puede elegir dejar de ser una persona.

Pues bien: el estado anímico, físico o emocional de una persona impacta directamente en su trabajo, es decir en la forma en que pueda aplicar cualquier práctica profesional.

No es la intención aquí desarrollar todo un manual sobre la construcción progresiva del bienestar profesional, hasta qué punto podemos actuar sobre ello en las empresas, o hasta qué punto cada persona puede influir y trabajar en ello. Pero cada día parece más necesario que cada persona se plantee, de manera personas, algunas cuestiones relevantes: cómo me siento frente a situaciones (buenas, malas, estresantes), qué me hace sentir motivado y por qué, y al contrario; qué consigo si me enfrento a situaciones incómodas, o si las dejo pasar hasta que empeoran; hasta qué punto sigo mis valores y no la intención de aprobación por parte de otros; etc...

Y aún muchas más, sobre las cuales animo a reflexionar una vez finalizado este curso:
  • ¿Estoy actualmente en mi mejor versión, o en qué puedo mejorar?
  • ¿Pierdo demasiada energía preocupado o preocupada en detalles de poco valor, o centro mi atención en lo que en realidad importa?
  • Cuando algo me disgusta o me impide avanzar, ¿solamente me quejo o pienso en algún plan de acción al respecto para solucionar el problema?
  • ¿Puedo detectar acciones tóxicas, y en ese caso limitarlas o eliminarlas de mi día a día?
  • ¿A veces me obceco en querer saberlo todo... cuando en realidad hay mucha información que me inunda y me consume la atención, y que al mismo tiempo no necesito?