Scrum

A través de mi experiencia he podido comprobar que hay muchos equipos que no saben trabajar. Y no es por la falta de competencias, sino por una falta de organización, claridad y enfoque.

Temprano en mi carrera profesional aprendí que los equipos más eficientes son aquellos que están mejor organizados, emplean las mejores herramientas para el trabajo y tienen una comuncación más clara. Recuerdo que mi cambio de paradigma vino cuando un colega llamado K. me dijo “Tu forma de trabajar es una mierda”… y en holandés, que suena más fuerte todavía. Tal cual. Sin pelos en la lengua me lo soltó. Acto seguido me enseñó la forma en la cuál se estructura el trabajo en equipos altamente productivos.

Estas formas o filosofías de trabajo se han estudiado a detalle y han evolucionando con el tiempo, pero en su core predican lo mismo: equipos competitivos, que producen con más calidad, con más frecuencia y se adaptan a cambios en el camino.

De todos estos métodos de trabajo, quizas el más utilizada hoy en día sea Scrum.

¿Qué es Scrum?

Scrum es un marco de trabajo perteneciente a las Metodologías Ágiles que ayuda a los equipos a resolver problemas complejos. Funciona como un sistema cíclico e iterativo cuya idea principal es progresar hacia un objetivo de forma incremental; esto permite aprender durante el proceso y potenciar la capacidad de adaptación al cambio.

Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems.

¿Cómo saber cuándo utilizar Scrum?

Scrum es una buena estuctura de trabajo para proyectos con ciertas características:

• El problema a resolver no se entiende muy bien
• Hay demasiadas incognitas en el proceso
• Hay personas nuevas en el equipo

Waterfall vs Scrum

El proceso típico de desarrollo de proyectos de software es conocido como Waterfall Development Model. Bajo este modelo, el desarrollo de software toma varios años en completarse y se fundamenta en un plan rígido.

Scrum por otra parte es una “nueva” forma de trabajar que permite a los equipos avanzar de forma progresiva, probando, descubriendo y desarrollando el producto en ciclos iterativos y con enfoque en aportar valor al cliente.

Los fundamentos de Scrum están basados en el conceptos LEAN y del control empírico de procesos. El empirismo implica trabajar de forma basada en hechos, experiencia y evidencia. Scrum implementa un proceso empírico donde el progreso se basa en observaciones de la realidad, no en planes ficticios. Scrum también pone gran énfasis en el cambio de mentalidad y cultura para lograr agilidad empresarial y organizacional.

Son tres los pilares fundamentales del empirismo:

• Transparencia: Todos tienen acceso a la información que necesitan para hacer sus trabajos. También es tener una comunicación abierta y honesta entre los miembros del equipo.
• Inspección: Aprender sobre lo que hemos hecho. Tenemos que revisar y comprender nuestro trabajo de forma periódica. La pregunta clave es: ¿qué es lo que hemos aprendido de lo que hemos realizado?
• Adaptación: Basados en lo que hemos aprendido con la inspección de nuestro trabajo, cambiamos lo que hacemos y cómo lo hacemos.

Project Mindset vs Product Mindset

Scrum tiene la mentalidad de “Product Mindset”, en vez de “Project Mindset”:

Project Mindset

Es la forma tradicional de manejar un proyecto. Esta forma de gestión está delimitada por tres factores:

1. Alcance
2. Tiempo
3. Presupuesto

Product Mindset

Esta forma de gestionar el trabajo se centra en el cliente y el valor que pretendemos aportar. Este enfoque promueve que el equipo experimente para comprender las necesidades del cliente y que creen medidas que describan el valor que se está entregando. Esto genera innovación y soluciones creativas.

A product is a vehicle to deliver value. It has a clear boundary, known stakeholders, well-defined users or customers. A product could be a service, a physical product, or something more abstract.

La cultura y los valores de Scrum

La cultura para que Scrum sea efectivo debe de ser:

• Una cultura en la que sus miembros puedan expresar sus opiniones y comunicar con libertad.
• Una cultura en la que sus miembros pueden reconocer errores sin ser castigados o juzgados.
• Una cultura de respeto por nuestros colegas y el trabajo que estamos haciendo.

Y sus valores son:

• Valentía: Hacer lo correcto y ponerle cara a problemas y decisiones difíciles.
• Enfoque: El equipo no debe desviarse en tareas que no atañen al objetivo del proyecto.
• Compromiso: Cada miembro se compromete a lograr los objetivos del equipo, del proyecto y ayudar a sus colegas.
• Respeto: Los miembros deben respetar las diferencias en experiencia y perspectivas de cada uno.
• Apertura: Se comprometen a ser honestos con todo lo referente al trabajo y sus obstáculos.

Definiciones de palabras clave

• Product Goal: es el objetivo del trabajo o proyecto. El objetivo del producto se tiene que documentar.

• Artifact: son las herramientas que nos permiten ejecutar Scrum, por ejemplo el backlog de producto (product backlog). Normalmente estos artefactos los podemos encontrar y usar en herramientas digitales como Jira, Trello o Microsoft Teams, pero también pueden ser artefactos físicos como una pizarra o unos post-its.

• Product Backlog: Son todos los pasos que debemos seguir para llegar al objetivo de producto. Es todo lo que sabemos que tenemos que hacer para llegar ahí. Se expandirá y se contraerá en el tiempo conforme avancemos y a medida que vayamos aprendiendo y descubriendo. A los elementos dentro del Product Backlog se les conoce como Product Backlog Item (PBI).

• Sprint: es un periodo de trabajo enfocado. Es el contenedor de todos los eventos.

• Sprint Goal: - es el objetivo del Sprint.

• Sprint Backlog: - Es el Backlog del Sprint.

• Sprint Planning Event: Es un evento que da inicio a cada Sprint y en el que se acuerdan prioridades y el trabajo que el equipo debe de hacer en ese sprint. El resultado esperado de un Sprint Planning Event es tener claridad sobre el objetivo del Sprint (Sprint Objective) y el backlog del sprint (Sprint Backlog). Hay tres preguntas clave a responder en este evento:

  • ¿Por qué este Sprint tiene valor?
  • ¿Qué podemos hacer este Sprint?
  • ¿Cómo realizaremos el trabajo seleccionado?

• Daily Scrum: Son reuniones rápidas, de 15 minutos, que el equipo tiene todos los días. En ellas se revisa el avance hacia el objetivo del sprint, si hay algún impedimento y se planifica el trabajo para las próximas 24 horas. Deben asistir solo aquellas personas que están desarrollando el sprint. Los otros dos roles pueden asistir pero solo como oyentes. El Daily Scrum se debe hacer en el mismo lugar a la misma hora para crear una rutina en el equipo.

• Increments: Son los pasos progresivos que damos hacia el objetivo. Increment es una palabra clave de Scrum y es también un artefacto.

• Definition of done: Son los estándares que indican que el incremento se ha completado con éxito. Son estándares de calidad que nos indican que trabajo está terminado.

• Sprint Review: Es una reunión en la que se da retroalimentación sobre el trabajo que se hizo en ese Sprint. Solo se habla sobre el trabajo realizado, no sobre el proceso. Pueden asistir a ella tanto el Scrum Team como los Stakeholders.

• Sprint Retrospective: Es una reunión en la que los miembros del equipo hablan sobre como fue la colaboración y el proceso en el último sprint. En ella se da retroalimentación sobre cómo se puede mejorar la forma de trabajar en equipo. En este evento hay que hacer tres preguntas clave:

  • ¿Qué fue lo que funcionó?
  • ¿Qué no fue bien?
  • ¿Qué podemos mejorar?

Equipos de Scrum

El equipo en Scrum es la unidad fundamental de cualquier Scrum. Los equipos de Scrum no deben superar las 10 personas y es responsable de los incrementos del producto.

Los equipos tienen 6 características:

1. Cohesión
2. Enfoque
3. Multidisciplinares
4. Autonomía
5. Sin jerarquías
6. Responsabilidad

Sobre los roles

En Scrum, los roles de las personas se definen como responsabilidades o Accountabilities. Estos son los tres roles:

• Product Owner: es la persona que tiene la visión del producto. Su rol es maximizar el valor del producto, gestionar el Product Backlog y servir como puente entre los miembros del equipo. Sus responsabilidades son definir el alcance, mantener el backlog ordenado, tomar de decisiones y participar en los eventos. Los Sprints solo pueden ser cancelados por el Product Owner y solo si su objetivo se vuelve obsoleto.
• Developers: son las personas que hacen el trabajo. Sus responsabilidades son planificar el sprint (Sprint Planning Event), añadir items al backlog y hacer control de calidad de su trabajo.
• Scrum Master: es la persona que sabe mucho sobre Scrum y ayuda al equipo a adoptar sus prácticas. También asiste al equipo para avanzar hacia el objetivo. Sus responsabilidades son asegurar la efectividad del equipo y establecer el Scrum como indica la guía de Scrum.

Eventos en Scrum

Los eventos en Scrum son las reuniones que se realizan en Scrum. Ayudan al equipo a mantenerse alineados con el Sprint, los objetivos del producto, y también a eliminar obstáculos en el proceso.

Los 5 eventos de Scrum

• Sprint
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Tiempos

• Sprint: 2 semanas / 1 mes
• Sprint Planning: 8h
• Sprint Review: 4h
• Sprint Retrospective: 3h
• Daily Scrum: 15m

La anatomía de un buen Product Backlog Item (PBI)

Un PBI bien estructurado normalmente contiene varios componentes principales:

• Título: Un nombre corto y descriptivo del trabajo (por ejemplo, “Agregar función de restablecimiento de contraseña de usuario”).
• Descripción: A menudo escrita en formato de historia de usuario como “Como [usuario], quiero [objetivo], para que [beneficio]” para capturar la perspectiva y la intención del usuario.
• Criterios de aceptación: Condiciones específicas y comprobables, frecuentemente escritas en formatos como “Dado/Cuando/Entonces”, que definen cuándo el elemento está completo y funcionando.
• Orden/Prioridad: Clasificado por el propietario del producto para reflejar el valor comercial y la secuencia.
• Estimación: Dimensionado en función del esfuerzo requerido por el equipo de desarrollo.

Backlog Refinement

Backlog Refinement es la acción de tomar un PBI y convertirlo en unidades más pequeñas y más precisas. No todos los items tienen que ser refinados.

Recursos

• The Manifesto for Agile Software Development
• Scrum Guide
• Scrum en Wikipedia
• The Mythical Man-Month: Essays on Software Engineering - Fred Brooks
• Complexity Theory
• Product backlog: Tips for creation and prioritization
• Definition Of Done (DOD) Explanation and Example
• What is Kanban in project management?
• Story points and estimation
• Jira Templates
• Burndown chart